Sovereign Compute

Agentic AI RAG architecture should begin with data topology, not model selection, because operational risk is created by where evidence moves and who controls the runtime. A public institution that centralizes sensitive data before proving locality, observability, and egress economics has not simplified the decision. It has turned a decision-support program into a data-movement commitment.

In operational settings, retrieval-augmented generation increasingly extends beyond document search into managed retrieval, tool use, citations, permissions, traces, and agentic workflows, as shown by cloud RAG documentation such as Amazon Bedrock's guidance on knowledge bases for proprietary-data retrieval. A ministry, agency, or defense program is therefore not choosing only a model. It is choosing an operating model for data access, authority, and decision support.

A common pattern is to copy data into a lake, impose a common representation, build indexes, attach agents, and let the orchestration layer reason over the integrated data environment. That pattern can simplify procurement slides and early demonstrations. It can also hide the questions that decide whether the system can survive production scrutiny: which records were copied, which evidence was transformed, which runtime observed the prompt, and which authority now controls the derived data.

The disciplined starting point is topology. Before selecting an agent framework, the program should map where mission data lives, who owns it, what can legally move, what must remain local, how retrieval will be audited, and where repeated calls will create operating cost. Only then can orchestration be judged against the real shape of the mission infrastructure.

‍

Inherited assumptions fail when agents cross boundaries

Many architecture reviews still begin from batch-analytics assumptions. The inherited model is familiar: collect data, normalize it, place it in a central store, and make it available for downstream analysis. That model can work when the analytic workflow is bounded and the institution has already accepted consolidation as the control model.

Agentic RAG changes the failure model. A single answer may require a policy memo, a logistics signal, a case-management record, a geospatial service, and a model call that reconciles the evidence. Each step can cross a runtime boundary. Each boundary introduces a control question.

For public-sector leaders, the control question is concrete. Consider a ministry agent asked whether a regional supply disruption affects an emergency-response plan. The answer may depend on a civil registry, a contractor-operated inventory system, a coalition evidence repository, and local incident reports. The agent may not be allowed to move all of that evidence into one store. It may be allowed to retrieve summaries from one source, identifiers from another, and raw records from a third.

The UK National Cyber Security Centre's Guidelines for secure AI system development frame AI security across design, development, deployment, operation, logging, monitoring, risk ownership, and protection against unauthorized sensitive-data exposure. That framing matters because agentic RAG is not a laboratory capability once it touches operational data. It is a governed system that must function as intended while preserving the authority boundaries around the evidence it uses.

In Scalytics architecture reviews, the harder question is often not which model to use. It is whether copied data, embeddings, traces, prompts, retrieval results, and derived memory can be inspected, deleted, localized, or explained under the same authority as the source record. The inherited assumption is that integration creates control. In agentic RAG, integration can also create a new control surface.

‍

The topology map comes before orchestration

Data topology is the map of where evidence lives, which authority controls it, which runtime may process it, and which movement paths are permitted before an AI system produces an answer.

That map should answer a small set of questions before any framework decision is made:

1. Which source systems are authoritative for each class of evidence?
2. Which data can move, which data can be transformed, and which data must remain in place?
3. Which compute environments may query, embed, summarize, or store derived material?
4. Which identities and credentials will the agent use when crossing systems?
5. Which prompts, retrieval results, traces, and tool calls must be retained for audit?
6. Which network paths cross regions, security zones, suppliers, or foreign jurisdiction?

This is not bureaucracy around the edges of innovation. It is the architecture. An agent that retrieves from a classified repository, a civil registry, and a contractor data store is not a single workflow. It is a chain of delegated authority. If that chain is not explicit, the program cannot reason honestly about security, latency, cost, or accountability.

Managed RAG services have a legitimate role inside well-understood boundaries. Google describes RAG workflows in terms of data ingestion, transformation, embedding, indexing, retrieval, and generation. Those stages are useful implementation references. They do not decide whether the data should have been copied into that boundary in the first place.

The distinction is strategic. Model selection can be revised. An orchestration library can be replaced. A data-export operating model becomes embedded in contracts, access reviews, retention policies, security accreditation, and user behavior. Once the institution treats the centralized store as operational truth, undoing the decision becomes a governance problem rather than a technical migration.

Topology-first design asks a more disciplined question: what is the least movement required to produce a trusted decision?

‍

Can AI agents run without centralizing data?

Yes, AI agents can run without centralizing data, but only if retrieval and processing are designed as federated execution rather than delayed export into a central lake.

In-situ execution means that processing, retrieval, and evidence preparation occur as close as practicable to the authoritative data source, with policy and audit controls preserved at that boundary. This does not mean every query runs locally. It means the default burden of proof changes. The program must justify movement instead of assuming movement.

That  matters because centralized-ontology platforms often appear to solve governance by imposing a common operating layer over integrated assets. They can be valuable where an institution has already accepted the data movement, ownership model, and jurisdictional dependencies. They are less convincing where the mission landscape is federated by design: multiple agencies, coalition partners, contractor systems, national-security enclaves, and legacy repositories with distinct legal duties.

A Sovereign Decision Fabric is Scalytics' term for an architecture pattern that keeps decision evidence, retrieval authority, audit trails, and model execution under accountable mission control rather than relocating them into a detached platform.

‍

‍

They are less convincing where the mission landscape is federated by design: multiple agencies, coalition partners, contractor systems, national-security enclaves, and legacy repositories with distinct legal duties.

A Sovereign Decision Fabric is an architecture pattern that keeps decision evidence, retrieval authority, audit trails, and model execution under accountable mission control rather than relocating them into a detached platform.

Scalytics Lascaris is the platform that delivers this fabric. It provides the governed runtime to ensure agents interact with evidence under strict, localized authority. For a defense, intelligence, or public-administration program, that difference is material. It determines whether sovereignty is an operational property of the system or a claim in the procurement language.

When an institution is ready to extend this capability to query disparate source systems without exporting data into a lake, federated processing can be introduced. This is where cross-platform engines such as Apache Wayang act as an eventual add-on to the architecture, helping governed agents reach governed evidence directly at the source.

Federation is not a slogan for keeping everything where it already sits. Some data should be copied. Some indexes should be centralized. Some derived products should become shared reference material. The question is whether those decisions are made after a topology review or hidden inside a default ingestion pattern.

‍

Federation changes the failure model

Federation is not a simpler architecture. It is a different architecture with different points of discipline.

Apache Wayang is a useful reference point because its documentation describes cross-platform optimization and in-situ processing across multiple execution engines. The project separates the logical data-processing plan from any single runtime, which lets the system reason about whether work should happen in a database, stream processor, local execution environment, or distributed engine.

Academic work on Wayang makes the same point in more formal terms. A SIGMOD Record paper on cross-platform data processing with Apache Wayang describes unified processing across multiple platforms and optimizer cost functions that can consider execution time and monetary cost. That is the kind of reasoning that early agent diagrams often omit.

The policy implication is straightforward. If a query can be answered inside an existing PostgreSQL deployment without moving records, the architecture should make that path visible. If a stream processor can prepare evidence before it becomes a model prompt, the program should know which authority permitted that transformation. If a graph operation belongs closer to a graph engine, the system should not pretend that a central lake is the only rational home for the data.

A federated RAG architecture therefore shifts the design conversation from "which platform owns the data?" to "which execution path is lawful, observable, timely, and proportionate?" That is a better question for sovereign institutions because it exposes the trade-offs that centralized designs often compress.

Those trade-offs are real. Federation increases the importance of source-system availability, schema stewardship, policy consistency, and distributed debugging. A local repository that cannot meet operational availability requirements may still need a replicated index. A coalition data source may permit retrieval but not embedding. A mission system may allow summaries but not raw document movement.

The value of federation is not that it removes complexity. It puts complexity where leaders can see it before they commit the program to a data movement model.

‍

Observability must follow the agent

An agentic RAG system is only governable if the institution can reconstruct how an answer was produced. That requires observability across prompts, retrieval, tool calls, data sources, model responses, and downstream actions.

Traditional application monitoring is not enough. The program needs to know which agent acted, which task it belonged to, which documents or records were retrieved, which tools were called, which model generated the answer, and which evidence was unavailable because a policy boundary blocked access. NCSC guidance on secure operation and maintenance supports this operational view by emphasizing deployed-system behavior, logging, monitoring, update management, and feedback loops.

The leadership implication is direct: if the system cannot produce an evidence trail, it should not be trusted for consequential decisions. That does not mean logging every sensitive prompt in plain text. It means designing traceability with classification, retention, redaction, and inspection rights from the start.

The observability model should cover these layers:

• The user request, role, and authority used to initiate the agent task.
• The retrieval path, including indexes, source systems, document identifiers, and query text where lawful.
• The tool-call path, including external services, credentials, parameters, and outcomes.
• The model path, including model identity, prompt version, safety controls, and response metadata.
• The evidence path, including citations, rejected evidence, and derived memory.

Streaming infrastructure can help when it is treated as an audit and coordination fabric rather than passive transport. Kafka-compatible event streams can record retrieval events, tool calls, policy decisions, and agent outputs as independently inspectable facts. The exact platform is less important than the principle: the trace must outlive the agent invocation and remain accessible to the authority responsible for the decision.

Observability is also a limit on centralization. A closed single-vendor stack may offer polished internal dashboards while still giving the institution limited ability to inspect the full chain on its own terms. For sovereign programs, that difference matters. Control is not only whether the system works. Control is whether the authority can explain how it worked when challenged.

‍

Egress belongs in the architecture model

Network movement is not a footnote in agentic RAG. It is part of the architecture model.

Retrieval can create repeated cross-boundary traffic. Index refreshes can move documents more than once. Embedding pipelines can transfer derived representations. Tool calls can leave one region, enter another runtime, and return summaries that become part of downstream memory. Each movement may be acceptable on its own. The architecture risk appears when those movements are multiplied across agents, workflows, security zones, and suppliers.

The cost issue should be treated as an architectural property, not as a late procurement detail. A topology map does not need exact annual spend to be useful. It needs to show which choices create recurring movement, which choices create derived data stores, and which choices depend on supplier-controlled routes. The same map should show whether a widely used agent becomes more local as it scales or more dependent on cross-boundary retrieval.

There is also a sovereignty dimension. A cross-region retrieval path may satisfy a demonstration but fail later residency or inspection requirements. A model endpoint may support the desired capability but sit outside the intended control boundary. A vector index may be technically effective while creating a second representation of sensitive evidence under a different operational regime.

This is why egress belongs in the first architecture review. Export-into-the-lake designs often make movement feel like an implementation detail because the data has already been centralized before the agent arrives. A topology-first review reverses that assumption. It asks whether the movement is necessary, who approved it, who can observe it, and whether the same decision could be produced closer to the source.

For leadership, the egress question can be reduced to a procurement test: if the agent becomes widely used, does the architecture strengthen institutional control, or does it make control depend on more cross-boundary movement?

‍

Control requires explicit trade-offs

No credible architecture minimizes locality, latency, consistency, sovereignty, and operating burden at the same time. A serious program chooses which constraints are primary and documents what it accepts in return.

The table below is not a scoring model. It is a decision aid for forcing the trade-offs into the open.

‍

This table should be read as a challenge to premature certainty. A centralized architecture may be the right choice for a well-bounded administrative dataset. A federated architecture may be the right choice for contested, multi-agency, coalition, or classified environments. A hybrid may be the only practical route when mission needs outpace legacy-system modernization.

The point is that the choice should be defended explicitly. If a program chooses centralization, it should say why the authority benefits exceed the movement, jurisdiction, and derived-data risks. If it chooses federation, it should fund the operational disciplines that federation requires: schema stewardship, trace correlation, source availability, policy enforcement, and incident response across multiple runtimes.

What should not pass review is an architecture that hides the trade-off by drawing a clean agent box on top of an unexamined data landscape.

‍

Governance follows the path of data

AI governance becomes concrete when it follows the path of data. Policies written at the model layer cannot compensate for an architecture that loses track of evidence, movement, and authority.

This is where public-sector AI strategy should be careful with imported language from commercial platforms. Terms such as ontology, decision layer, copilot, and knowledge base may be useful. They can also obscure who controls the records, who controls the derived representations, and who can audit the route from evidence to recommendation.

The NIST AI Risk Management Framework is useful because it treats AI risk management as a process of governing, mapping, measuring, and managing risk. NIST's Generative AI Profile gives further support to review of sources, provenance, grounding data, and monitoring after deployment. Those sources do not prescribe a single agentic RAG architecture. They do make one thing clear: accountable institutions need evidence about how the system is designed, operated, and controlled.

For a ministry CIO, agency director, or program manager, the practical test is whether the architecture can answer questions that arrive after the demonstration:

• Which source was authoritative for this answer?
• Which data was copied, embedded, summarized, or retained?
• Which supplier runtime saw the prompt, retrieval result, or tool output?
• Which evidence was unavailable because policy blocked it?
• Which trace can an inspector review without exposing unrelated mission data?
• Which part of the system can be replaced without moving the authority boundary?

These questions are not hostile to AI adoption. They are what adoption requires when decisions matter.

The position to defend is therefore simple: do not centralize mission data until the program can explain why locality, observability, egress, and jurisdiction are secondary concerns. If that position cannot be defended in front of the authority that owns the mission, the architecture is not yet ready for the mission.