Agentic AI architecture for data: who decides each step

The usual layer cake won’t help

Search for an agentic AI architecture diagram and you will find stacks of four, seven or nine layers: interface, orchestration, reasoning, tools, knowledge, governance. They aren’t wrong, and they describe nearly any software with a model in it. A stack tells you what components to buy. It leaves out what decides whether the system can be trusted, namely who makes each decision while answering, and what happens when they get it wrong.

Data work makes this sharper than most agent domains. A coding agent’s mistake often produces a failing build. A data agent’s mistake often produces a clean number in a confident sentence, read by someone who will act on it. So I draw this architecture around authority. Governance appearing as a side bar in a diagram tends to mean nobody assigned it.

Three columns of authority

Sort every decision in your system into one of these columns. A decision in the wrong column is a design defect, whatever the framework or model. For the middle column, ask whether the rule must hold when the model has been manipulated or is plain wrong. If so, it’s code.

The source system is a separate authority. Snowflake’s row access policies or Salesforce sharing rules apply because the query runs under that person’s identity, and the agent’s code does not reimplement them. An agent design that needs its own copy of those rules has already made the expensive mistake.

Choose the least agency that works

Anthropic’s widely cited distinction separates workflows, where models and tools follow predefined code paths, from agents, where the model directs its own process. Its advice is to find the simplest solution and add complexity only when it demonstrably improves outcomes. Data gives a further reason to take that advice: each extra autonomous step is another place for an error to enter unnoticed before the number appears.

Many data questions need no loop at all. A question that maps to one approved metric takes a single tool call, and it should be answered the same way each time. A bounded loop earns its cost when the model must explore: find the table, check a value, fix a failed query. Full multi-agent systems are for a narrower case still.

A trace, step by step

Take a synthetic trace for a fictional company asking why gross margin fell in EMEA last quarter. It’s the most useful artifact you can design, because it forces you to say who decided each step and what a reader could check afterward. I’d write one out before choosing a framework. A step with nothing to put in the third column has no control.

When several agents are worth it

Anthropic reports that agents use about 4 times the tokens of chat, and multi-agent systems about 15 times, in its research system. It concludes that the approach suits high-value tasks that parallelize well. Those are its own figures for its own workload, so treat them as an order of magnitude, and they map to data work only partly. Warehouse compute comes on top of tokens, and four workers exploring a warehouse can each trigger expensive scans.

The use case I’d defend in analytics is breadth: separate workers checking independent hypotheses or different source systems, each returning a condensed finding. The early failures in that report apply directly: too many workers for simple queries, endless searching for things that do not exist, duplicated effort from vague instructions.

Data adds two requirements of its own. Identity has to travel, so that every worker runs as the person asking, with no shared worker credential. Definitions have to travel as well. If one worker reads revenue as bookings and another as invoiced, the orchestrator will happily subtract them. Pass the resolved definitions and filters as structured input to each worker, and have the orchestrator refuse to combine results built on different ones.

Stopping, and saying what was missing

An agent needs limits that sit outside its own judgment. Give each run a step budget, a token budget and a warehouse cost budget, and return a stated partial result when one is reached. Also decide what happens when a tool is unavailable, because the default may tell nobody. A managed agent platform may let a run continue with whichever tools the caller’s role can reach. That’s a reasonable default for a platform. Your application then has to make it visible, because an answer drawn from three of four sources reads the same as one drawn from all four.

An agent’s answer should carry its own coverage. Record which sources were consulted, which were skipped and why, so a reader can tell a real zero from a system that never looked.

Reads and writes are different systems

An agent that reads data and an agent that changes it have different risk profiles, and letting a conversation slide from one to the other is a common design error. OWASP’s guidance on prompt injection recommends least privilege and human approval for high-risk actions, and says plainly that no mitigation is foolproof. The combination to fear is an agent that can read private data, also reads text an outsider wrote, and also has a way to send something out. Each ability looks harmless alone. Your design should make sure no single run holds all three without a person in between.

For write actions, keep a preview step that changes nothing, require scopes that are never granted by default, and make execution safe to retry. The MCP specification’s July 28, 2026 revision has clients reissue a request as new when a response stream breaks, so a write that is not idempotent can run twice. Tool annotations such as a destructive hint help clients ask for confirmation, and they enforce nothing, so the authority check must sit in the service.

Observability that answers the second question

Teams usually instrument latency and cost first. The question you will be asked after an incident is different: why did this person see this number? The trace you want links the person, the client, the context used, each proposed query with its check outcome, the executed query, and the answer. The current MCP specification documents conventions for carrying OpenTelemetry trace context in request metadata, so a trace can follow a call across client and server.

Be realistic about what is being built. Gartner predicted in June 2025 that over 40 percent of agentic AI projects would be canceled by the end of 2027, citing cost, unclear value and weak risk controls. It’s a forecast, and it points at things this architecture can address. Bound the cost in code, choose a question someone owns, and put controls in the column where they hold.

Evaluate the run as well as the answer

Anthropic reports starting its multi-agent evaluation with about 20 real queries, because early changes had effects large enough for a small set to detect. Good news for a data team that thinks it needs thousands of cases first. Begin with 20 questions people ask, with known answers, and grade the returned results. Include questions the system should decline, since an agent that answers everything will otherwise look strong on coverage alone.

An agent adds measurements a single query does not have. Track steps per answer, tokens, warehouse cost, how many proposed queries the checks rejected, and how often a run hit a limit. A rising rejection count after a model change is an early warning that appears before accuracy moves. Read full traces regularly as well, because Anthropic’s team also relied on human testing to catch edge cases its automated evaluations missed.

Be wary of adopting a framework before you have this harness. Anthropic’s guidance is to start with model APIs directly, since many patterns take only a few lines, and to understand the code underneath any framework you do choose. In data work the reason is concrete: the query check, the identity handoff and the stopping rule are the parts you will have to explain to a security reviewer, and they should not be hidden in an abstraction you cannot read.

How we split it

We follow this allocation in Nexatron. The model explores with tools and proposes a query, and deterministic checks for read-only access, join fan-out, organizational defaults and scope decide whether it runs. Every question runs under the asker’s own sign-in, and nobody, administrators included, can ask as someone else. Owners approve definitions, and a flagged wrong answer produces one proposed fix that changes nothing until the owner approves. We grant no action scope by default. You can examine the resulting record on an answer, under Answered as and the trust panel.