The model did its job. What failed was everything around the model. The context. And that’s the shift worth getting your head around: the intelligence is largely a solved problem now, and the bottleneck has moved to context.

Prukalpa Sankar, Founder and Co-CEO of Atlan, puts it bluntly: with AI, context might be everything, because “the intelligence is already here.” The model is the easy part. The hard, durable, defensible part is whether your agents understand how your business actually works. That understanding is what people are starting to call context intelligence.

What context intelligence actually is

It isn’t a bigger prompt or a better retrieval setup. It’s the infrastructure that gives an agent shared, governed, current knowledge of your organisation, plus a memory of the decisions it and its predecessors have made. Two ingredients: a map of how things relate, and a record of why things happened.

That map and that record are the context graph. A context graph is a living model of your business as a set of entities and the relationships between them, this customer, that contract, this SLA, that exception, joined to the decisions taken against them. Foundation Capital, in their Context Graphs essay by Jaya Gupta and Ashu Garg, made the sharpest version of the argument: the durable asset isn’t the data an agent reads, it’s the decision trace it leaves behind. What was gathered, what rule applied, why an action was allowed. Capture that, and precedent becomes something an agent can look up instead of guess at. The agent stops having data with no judgement and starts having judgement.

Why this is the accuracy story

Most enterprise agents fail on a trust gap, not a model gap. The SLA agent didn’t need a cleverer model. It needed to know which contract was current, that it was allowed to act on it, and what had been decided in similar cases before. None of that lives in the model. All of it lives in the context.

Without it, you get what Prukalpa calls context sprawl: every agent building its own private, partial view of the world, none of them agreeing on what “active customer” even means. Fifty agents, fifty versions of the truth, no shared map. Accuracy in that environment isn’t a model property. It’s an infrastructure property.

This is where the runtime and the infrastructure get confused. Anthropic’s work on context engineering covers the runtime half: context is finite, and the discipline is fitting in the fewest high-value tokens at the moment of inference, not the most. That’s real, but it assumes the right context already exists to be selected. Context intelligence is the layer below it, the one that decides what context exists, whether it can be trusted, and whether the agent may use it. One is what you put in the window. The other is what’s available to put there at all.

How to think about building it

You can read most failures here as three debts coming due.

• Data Debt: no single governed source of what’s true, so your agents disagree.

• Decision Debt: nobody captured why past actions were taken, so the context graph has no memory.

• Evaluation Debt: no framework to check whether the context an agent actually used was the right context. Work out which one is biting and you know where to start.

The build order matters more than the architecture diagram. The instinct is to spend two years plumbing every system into a perfect context layer before anything ships. Prukalpa’s advice is the opposite, and it’s right: bootstrap from the systems you already have, the CRM, the ERP, the BI definitions, get the context layer roughly 80% of the way there, and let the flywheel start turning. Every decision an agent makes then becomes institutional memory the next agent inherits. You don’t design the context graph up front. You grow it.

Which is why this isn’t really an AI problem at heart. It’s the next turn of data engineering: context as a governed product, with owners, versions, and tests, sitting between your data and your agents. The teams who treated data as a product a decade ago have a head start. The ones still treating context as something you cram into a prompt are about to learn the difference in production.

The open question, the one nobody at the table has a clean answer to yet, is who inside the enterprise actually owns this layer.

I got into exactly that with Prukalpa Sankar on the podcast. She’s been arguing for the context layer longer than almost anyone, and it’s the clearest thinking I’ve heard on where this is heading.

Also, read Prukalpa’s article - What an Enterprise Context Layer Actually Is

Enjoy your weekend.

Talk soon,
Sandi

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Part 1 covered Schema and Ownership: the description and accountability layer of an Agent Registry. Unity Catalog as the agent registry. AWS IAM for per-agent identity. CloudTrail for audit trails. A stack that answers the questions an audit demands: what exists, who owns it, what it can do.

That is necessary, but it is not sufficient.

Schema and Ownership describe an agent. They do not constrain it. An agent with a well-documented schema and a clear owner can still make a consequential decision without human approval, access data it should not touch, or operate at an autonomy level the business never signed off on. That is where Risk Class and Autonomy Level come in and where the registry becomes a governance control rather than a filing system.

Component 3: Risk Class - Not All Agents Carry Equal Risk

Risk classification is the decision that determines what governance an agent receives. If you get it wrong and you either over-govern low-risk agents until teams route around the process, or under-govern high-risk agents until something goes wrong in production.

The four risk categories worth working with in a regulated environment:

1. Low Risk: bounded output, read-only, no consequential action. An agent that summarises documents or answers questions from a knowledge base.

2. Medium Risk: supervised action. The agent can write or update records, but a human reviews before execution.

3. High Risk: consequential action inside a tightly constrained boundary. The agent can execute without per-action approval, but only against approved tools, approved data paths, and fully audited systems.

4. Critical Risk: autonomous consequential action across multiple systems, with downstream effects that are difficult or impossible to reverse.

In Databricks, risk class is best treated as governed metadata attached to the agent assets you register. For example, on Unity Catalog models, model versions, and functions, all of which support tagging. That makes risk class visible, queryable, and reviewable across the lifecycle. If an agent gains new tools, new data access, or a broader execution boundary, the classification should be reassessed before the next promotion.

So, if you ar eon Databricks, use Unity Catalog to register the agent, its model versions, its functions, and its metadata. Use tags to record risk class. Use Unity Catalog privileges, managed authentication, and deployment-time permission checks to enforce which tools and data paths are actually reachable at runtime. If you need an explicit risk-policy engine that says, for example, a High Risk agent may call Tool A but never Tool B, that policy layer still sits outside Databricks - in an API gateway, middleware layer, or external authoriser.

That is the line between registry and policy engine. Databricks gives you the governed assets, the permissions model, and the audit surface. If you need deterministic policy decisions over agent behaviour itself, you compose that on top.

On the AWS-native path: Amazon Bedrock AgentCore Gateway with Cedar policies provides a similar enforcement pattern - deterministic allow/deny decisions on every tool call, with Lambda interceptors for dynamic validation. Cedar policies are authored in a declarative language and evaluated against principal, action, and resource with optional conditions over request context. Worth monitoring as it moves towards general availability.

Component 4: Autonomy Level - How Independently an Agent Operates

Risk class tells you what an agent is allowed to do. Autonomy level tells you how much independent judgement it is permitted to exercise in doing it. These are related but distinct. A High Risk agent can still operate at L1 with human approval, or at L3 with bounded multi-step execution. The risk class constrains the action space. The autonomy level constrains the operating model.

The five levels from the registry:

• L0 - Assistive only. Generates output for human review. No execution.

• L1 - Human-approved actions. The agent proposes; a human confirms before execution.

• L2 - Semi-autonomous workflows. Executes within defined boundaries without per-action approval.

• L3 - Goal-driven execution. Plans and executes multi-step tasks. Human oversight at checkpoints, not per action.

• L4 - Multi-agent autonomy. Coordinates with other agents, spawns sub-agents, orchestrates complex workflows with minimal human intervention.

In Databricks, autonomy level should be treated as an explicit registry attribute you manage in your own governance model, not as a built-in Unity Catalog field with native enforcement semantics. The platform gives you the places to record it, such as model and model-version metadata, but the meaning of L0 through L4 remains an operating policy you define and then enforce through workflow design, approvals, deployment controls, and runtime boundaries.

MLflow Tracing captures the full execution path - every tool call, every decision point, every input and output - linked to the agent version and autonomy level at the time of execution. In a regulatory investigation, that trace is the evidence.

So, autonomy level is declared in the registry, promotion is gated through MLflow deployment workflows, runtime execution is bounded by Databricks permissions and isolated tool execution, and trace evidence is captured through MLflow. The registry records the autonomy decision; the surrounding control plane makes it real.

Open source alternative: Microsoft released the Agent Governance Toolkit in April 2026 under MIT licence, an open source project that addresses runtime security governance for autonomous agents. It includes execution rings inspired by CPU privilege levels, kill switches for emergency agent termination, and circuit breakers. It maps directly to the OWASP Top 10 for Agentic Applications (2026) and is the most purpose-built open source option currently available for autonomy-level enforcement.

What the Registry Now Does

Across both parts, the four components work as a single control system.

Schema tells the registry what the agent is. Ownership tells it who is accountable. Risk Class tells it what level of control the agent requires, and that classification is carried as governed metadata across the agent’s registered assets. Autonomy Level tells it how much independent judgement the agent is permitted to exercise, and that decision is enforced through release workflows, runtime permissions, and execution boundaries rather than left implicit in code.

The audit request scenario from Part 1 - fourteen agents, nobody can answer, is no longer possible. Every agent has a schema record, an owner, a declared risk class, an explicit autonomy level, governed access to tools and data, and an execution trail that can be reconstructed through MLflow and platform audit logs. The registry is not a reporting artefact. It is the control plane that makes autonomous operation in a regulated environment defensible.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Talk soon,
Sandi.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

An organisation deploys 50 agents across 6 teams over the course of a year. Without any central register, wihtout any ownership mapping, wihtout any shared schema.

Then the audit request arrives.

They ask the following questions:

• Which agents are live?

• Who approved the one touching customer financial data?

• What has it been told in its system prompt?
  

Nobody could answer.

This is not a technology failure. The agents worked fine but the governance infrastructure was never built.

A Note on the choice of technology

Before we process, I want to make a note on my technology choices here. The architecture in this issue is Databricks-on-AWS. That is not a neutral choice, but it reflects where I spend most of my time. I work with Tier 1 UK financial institutions, and the patterns I see repeatedly across those engagements have shaped this stack.

Databricks gives me Unity Catalog for governance, lineage, and access control across the full data and AI estate. AWS gives me IAM for identity and CloudTrail for audit trails. These tools are production-stable, work in hybrid deployments, and hold up under compliance scrutiny. Where open source alternatives exist and are worth knowing about, I have noted them inline.

Where open source alternatives exist and are worth knowing about, I have noted them inline. But the primary recommendation here is the stack I have seen hold up under real compliance scrutiny.

What an Agent Registry Actually Is

An Agent Registry is the control layer that makes an agent estate governable. It is not a dashboard. It is not a catalog you update manually. It is infrastructure, the layer that sits beneath your agents and answers the questions an audit demands: what exists, who owns it, what it can do, and how much autonomy it operates with.

It has four components. This issue covers the first two: Schema and Ownership. Part 2, out on Wednesday, covers Risk Class and Autonomy Level - the enforcement layer.

I am splitting this deliberately.

• Schema and Ownership are about description and accountability - what an agent is and who controls it.

• Risk Class and Autonomy Level are about enforcement - what an agent is allowed to do and what stops it.

These are different engineering problems. Collapsing them into one piece does neither justice.

Component 1: Schema — How an Agent Describes Itself

Schema is the agent’s self-declaration. Without it, agents are opaque. Orchestration breaks. Integration fails silently. You cannot route work to an agent you cannot describe.

A schema record needs to capture: capabilities and skills, the APIs and tools the agent can call, input and output formats, memory and context handling behaviour, access permissions, and communication protocols.

Unity Catalog (UC) is the agent registry in this stack. It governs agent tools as registered, versioned functions - each one a securable object with access control, lineage tracking, and metadata surfaced through Catalog Explorer or the REST API. It supports attribute-based access control on tags, which means you can attach metadata directly to agent capability records and build access policies around them. If you think about it, UC becomes the same governance layer that already covers your data assets, your ML models, and your pipelines, just extended to agents without adding a separate system.

Unity Catalog also works across Databricks workspaces on AWS, Azure, and GCP. If your agent estate spans cloud environments, governance travels with it through the same control plane. That’s powerful.

AWS AgentCore Agent Registry is worth knowing about as a complementary discovery layer. It stores agent records across frameworks and clouds and supports semantic search and approval workflows - and is useful if your estate includes agents running entirely outside Databricks and you need a single cross-platform catalogue. It is a discoverability tool, not a governance layer. For most Databricks-on-AWS deployments, Unity Catalog covers the registry function without it.

Open source alternative: purpose-built open source agent registry tooling is immature right now. The practical path is a lightweight service catalogue like Backstage for discoverability combined with OPA for policy enforcement - neither of which was designed for agents, but both of which work today without significant custom engineering. I have found this GitHub Repo, I never tried it or even explored it - might you might want to have a look.

If you find one or know one - let me know in comments.

Component 2: Ownership — Who Controls the Agent

Ownership is where shadow AI comes from. An agent without an owner is an agent nobody is responsible for. In regulated environments, that is not an abstract risk.

An ownership record needs to capture: the team or business owner, accountability mapping, the access governance model, the escalation path, approval authority, and lifecycle responsibility - including who decommissions the agent and when.

On the identity side, AWS IAM is the enforcement mechanism. Each agent should operate under a dedicated IAM role with least-privilege permissions - no shared credentials, no roles that accumulate access over time. IAM Policy Autopilot, allows AI coding tools to generate baseline IAM policies directly from application code, reducing the gap between what an agent was built to do and the permissions it actually holds.

Accountability trails run through AWS CloudTrail. Every registry access and administrative action is logged. In AgentCore Agent Registry, CloudTrail integration is built in, meaning you have an auditable record of who approved an agent, when it was registered, and when its record was last modified.

Unity Catalog extends this further. Audit logs capture every agent action. Unity AI Gateway release introduced MCP server governance - controlling which agents can access which external systems and tracking how that data is used. Ownership in the registry is not just a field in a database. It maps directly to the IAM role, the Unity Catalog access policy, and the audit trail.

Open source alternative: Open Policy Agent (OPA) provides policy enforcement for ownership and access governance in environments not running on the Databricks or AWS managed stack. It is cloud-agnostic and widely used in regulated industries.

If you find good open-source stack please comment here. I am looking for them as well.

Coming Wednesday: Risk Class and Autonomy Level

Schema and Ownership tell you what an agent is and who is responsible for it.

That is necessary but not sufficient.

The harder question is what an agent is allowed to do and what stops it when it operates outside its boundaries.

Part 2 covers Risk Class: how risk classification moves from a metadata tag in Unity Catalog to a live runtime control via Unity AI Gateway and AgentCore Policy. I will also cover Autonomy Level, the scale from assistive-only (L0) to multi-agent autonomy (L4), and the kill switch infrastructure that makes higher autonomy levels safe enough to deploy in a regulated environment.

This is the part of the registry most organisations skip entirely. It is also the part that determines whether your governance is real or decorative.

Talk soon,
Sandi.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

Mnay organisations I talk to gathers 50-100 AI use cases. They hold a big “priority workshop.” They vote on business value, strategic fit, and stakeholder excitement. They pick the top three, hand them to the engineering team, and wait for the magic to happen.

Six months later, the project is quietly shelved.

The reason? “The data infrastructure doesn’t support it.”

In my latest video, I talk about why this happens and more importantly, how to stop it using a framework I’ve been developing for production AI.

The “Human-to-Agent” Gap

The core problem is something I call the “Human vs. Agent” data standard.

As technical people, we often forget that data built for a human analyst is completely different from data built for an AI agent.

• Humans can reconcile messy schemas and ask a colleague for help.

• AI Agents cannot. They either fail, or worse, they fail silently.

If your infrastructure is built for BI dashboards, it simply won’t sustain a fully autonomous AI agent.

The 8-Dimension Assessment

To fix this, I’ve broken down AI readiness into 8 key dimensions across two groups:

1. Data Infrastructure: Consumers, Access Latency, Schema Rigor, and Metadata.

2. AI Operations: Error Handling, Memory/State, Evaluation, and Observability.

The goal isn’t to be “perfect” at all of them. The goal is to be honest. When you score your current setup (1 to 4) against what a use case actually requires, the “readiness” of your project stops being a debate and starts being a number.

Finding Your “Beachhead”

The most actionable part of this framework is finding your Beachhead Use Case.

A beachhead isn’t your most ambitious goal (like a fully autonomous loan negotiator). It’s the use case where:

1. The infrastructure gap is small (you can ship in weeks, not months).

2. The business value is standalone (it pays for itself immediately).

By starting here, you aren’t just “doing a pilot” - you’re building the foundation that makes the ambitious stuff possible later.

Want to run this assessment yourself?

I’ve put together a full walkthrough of these 8 dimensions and how to build your own “Gap Map.” If you’re tired of the “AI priority workshops” that lead nowhere, this might be the most useful 15 minutes of your week.

Check out the full breakdown here.

I’d love to hear your thoughts—drop a comment on the video and let me know which of the 8 dimensions is currently the biggest blocker in your org.

Have a great weekend,

Sandi.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

• MCP is the right abstraction for standardising tool access across multiple agents, but most teams are deploying it without the governance it needs

• Five failure modes keep appearing in regulated environments: hardcoded credentials, no authorisation layer between model and tool, invisible tool calls, server sprawl, and untracked data residency

• MCP is not always the right choice. Direct function calling, existing APIs, and async queues are better fits for several common patterns

• The fix isn’t complicated: treat MCP servers as infrastructure, instrument every tool call at the boundary, and never let the model be your policy engine

MCP is at that USB moment

Something shifted in 2024. Developers started asking, “can we connect an LLM to our tools?” and then wondering, “how do we do it without building a different integration for every model, every framework, every team?”

These are the questions MCP answers. The Model Context Protocol, originally developed by Anthropic and released in November 2024, and now gaining ground as a de facto standard.

By mid-2025, MCP had moved from research-adjacent to actively deployed. GitHub Copilot, Cursor, Claude, and a growing list of enterprise agent frameworks had either adopted or announced support. The server ecosystem - registries, SDKs in Python and TypeScript, community-contributed connectors for everything from PostgreSQL to Salesforce had expanded fast. Almost every other product has its MCP.

That speed should give you pause.

This is a pattern we’ve seen before. When USB was introduced in 1996, it solved a real problem: a dozen incompatible port types on the back of every PC. It was the right abstraction. And within a few years, “plug and play” had become a running joke because the driver ecosystem moved faster than the discipline around it. Devices connected. Systems crashed. Enterprise IT spent years cleaning up what consumer enthusiasm had shipped. While the protocol was fine, the deployment culture was not.

MCP is at that USB moment. The abstraction is right. The ecosystem is moving faster than the engineering rigour around it. Teams are shipping MCP servers in sprints, demoing them to CTOs, and having them in production eight weeks later. Six months after that, nobody can tell you what tools the agent is calling, the credentials haven’t been rotated since go-live, and there is no audit trail that would survive a compliance review.

The protocol didn’t fail them. The deployment pattern did.

This article is about the difference.

Tool Definition: A Contract with Non-Determinism

The fundamental difference between an MCP tool and a standard API is that it is a contract between a traditional, deterministic backend system and a non-deterministic LLM agent. Standard API engineering assumes a consumer will call a function exactly as documented. Agent tooling requires developers to accept that the model will interpret the description and choose the arguments. This non-deterministic usage is why building for agents requires a higher degree of protective rigor around entitlement, validation, and audit than standard integration patterns.

What MCP gets right?

MCP is solving a real problem, and the core of it is genuinely well-designed.

The integration tax is real, and MCP eliminates it

Before MCP, connecting an agent to a tool meant writing bespoke integration code. Every model had its own function-calling format. Every framework had its own abstraction layer. If you wanted to switch from one agent framework to another, you rebuilt your integrations. If you wanted the same capability accessible across multiple agents, you duplicated the logic and prayed for consistency.

Without a shared protocol, every team builds its own integration in the shape of its own constraints - its available libraries, its preferred auth pattern, its interpretation of what the downstream system needs. The result is integration sprawl that compounds with every new team that touches the same system. MCP breaks that coupling. A single MCP server exposes a set of tools, resources, and prompts under a standardised interface. Any MCP-compatible client regardless of which model or framework it uses, can discover and invoke those tools through the same protocol. Write once, expose everywhere.

This is what happened when REST became the default for web APIs in the early 2000s, displacing the chaos of SOAP, WSDL, and proprietary RPC formats. REST won because it was simple enough that teams could independently build to the same standard and have things actually work. MCP is attempting the same move at the agent-tool layer.

Runtime capability discovery changes the architecture

One of the underappreciated features of MCP is the tools/list endpoint. Think of it like DNS for tools - you don’t hardcode IP addresses into your application, you resolve them at runtime. An agent queries the server on startup, gets a schema-described list of available tools, and decides which to invoke based on the task. Your agent architecture can evolve without redeployment every time a tool is added or changed.

Where it genuinely shines

MCP is strongest when the problem is standardised access to well-defined internal systems. Four use cases stand out:

• Internal tool registries. A platform team builds and owns MCP servers for canonical internal capabilities - search, data retrieval, workflow triggers. Agent teams consume them without needing to understand the underlying integration. The boundary is clean, the ownership is clear, and the interface is versioned. This is the internal developer platform model applied to agent tooling.

• Governed data catalogue access. An agent needs to query dataset metadata, lineage, or schema. Exposing a data catalog (Unity Catalog, Alation, Collibra, DataHub) via MCP gives the agent a structured, permissioned interface without direct database access. The server enforces what the agent can see. This matters enormously in financial services, where an agent browsing raw schema can inadvertently surface data it has no business touching.

• Regulated workflow triggers. An agent initiates a downstream process - raises a ticket, submits a form, triggers a notification. MCP provides a typed, auditable interface for those triggers. The tool schema documents exactly what inputs are required; the server enforces them. The schema is the contract.

• Multi-agent orchestration. A supervisor agent delegates to specialist subagents, each with its own MCP server exposing its capabilities. The supervisor discovers what each subagent can do and orchestrates accordingly. This is where capability discovery really earns its keep; it makes composition between agents tractable without tight coupling.

• Tool Design for LLM Token Efficiency. The effectiveness of a tool is measured by its use within the LLM's context window. Prioritize tool interfaces that minimize the total volume of tokens consumed. For instance, prefer a search_datasets(query: str) tool to a generic list_all_datasets() tool. Furthermore, design tools with parameters for pagination and truncation to ensure the tool output - the data returned to the LLM is as concise and high-signal as possible. Refer to Anthropic’s blog: Writing effective tools for agents — with agents

A minimal MCP server for a governed data catalog wraps your catalog API behind a typed search_datasets tool enforcing domain filters, capping result limits, and keeping the agent away from raw schema access entirely. The tool definition is the contract; the server enforces it.

This is MCP doing what it’s designed for.

What risks MCP brings?

MCP moves fast to production. The failure modes tend to follow shortly after because the protocol makes it easy to ship something that works in a POC before the operational questions have been answered.

These are the five patterns you should understand.

Developers often forget “credential best practices”

Hardcoded credentials are not a new problem. What MCP changes is the rate at which new service boundaries get created. Spinning up an MCP server takes minutes - a few lines of Python, a decorator, done. That speed means teams are creating new integration points faster than their credential management habits have been built to handle. The result is more hardcoded credentials, in more places, with less visibility than traditional integration patterns would produce.

In a UK financial institution, this creates obligations that a missing credential policy would directly fail to meet under the Digital Operational Resilience Act (DORA). A credential with no owner and no rotation policy fails that bar.

DO NOT DO THIS: hardcoded credential in MCP server

DATABASE_URL = “postgresql://svc_agent:SuperSecret123@prod-db:5432/customers”

The credential is now wherever this server runs. If the server is containerised, the credential is in the image or the environment. If the image is pushed to a registry, it may be in the layer history. The blast radius of a compromise is the entire downstream system, not just the agent. This is the digital equivalent of writing your vault combination on a Post-it and sticking it to the outside of the vault.

Models usually have access to every tool in an MCP server - this is not least priviledge

MCP puts tool invocation decisions in the hands of the model. The model reads the tool schemas, decides which tool to call, and constructs the arguments. Nothing in the base protocol validates whether that decision was appropriate, whether the arguments are safe, or whether the calling agent had the entitlement to invoke that tool for that user in that context.

This is Saltzer and Schroeder’s principle of least privilege - articulated in their 1975 paper “The Protection of Information in Computer Systems” and still the foundation of access control design.

The principle states that every component should operate with only the permissions it actually needs. A model that has access to every tool in an MCP server, for every user, at all times, is a maximal privilege configuration. It is the opposite of least privilege.

In regulated industries, this matters concretely. An agent that can invoke a transfer_funds or update_credit_limit tool should not be making that invocation based solely on what the model infers from a user message. The trust chain is broken.

python

# Dangerous: model output routes directly to tool execution

async def run_agent(user_message: str, user_id: str):

    response = anthropic_client.messages.create(

        model=”claude-sonnet-4-20250514”,

        tools=mcp_tools,  # All tools. No entitlement check. No context.

        messages=[{”role”: “user”, “content”: user_message}]

    )

    for block in response.content:

        if block.type == “tool_use”:

            # The model decided. The server executes. Nothing in between.

            result = await mcp_session.call_tool(block.name, block.input)

This code grants the model access to all tools (tools=mcp_tools), establishing a maximal privilege configuration. The model’s tool\_use block is immediately trusted as the final decision, bypassing any policy or validation check. Execution proceeds directly to mcp\_session.call\_tool without confirming the user’s entitlement or context.

The model is a reasoning engine. It is not a policy engine. These are different things, and conflating them is how you end up with agents doing things nobody authorised them to do.

MCP invocations still require explicit instrumentation to be traced end‑to‑end

Any RPC to a separate process requires explicit instrumentation to appear in your trace - that is not unique to MCP. What makes MCP different is that the protocol is new enough that most observability platforms have no native integration for it yet. With a mature HTTP or gRPC stack, there is a reasonable chance your tracing library auto-instruments at the transport layer. With MCP, there is not. Teams adopting it now are on their own.

An MCP tool call is an RPC to a separate process. Without explicit instrumentation, that call disappears from your trace. You can see the model’s input and output. You cannot see which tool was called, with what arguments, what the server returned, how long it took, or whether it failed. This is the observability equivalent of a black box flight recorder that stops recording five minutes before the crash. You have most of the data. You’re missing exactly the part that matters.

For regulated deployments, this is an audit problem. The FCA’s Senior Managers and Certification Regime (SM&CR) creates personal accountability for outcomes. If an agent made a decision that affected a customer - a credit flag, a document retrieval, a workflow trigger - and that decision was influenced by a tool call, you need to reconstruct exactly what the tool returned. If the tool call isn’t in your trace, you cannot reconstruct it. “The model did it” is not an explanation that satisfies a regulator.

The fix lies in instrumentation at the MCP boundary, not inside the server. This is shown in the MCPGateway pattern below.

Every team builds one, no one owns them - there is no established governance for MCP servers

In a large organisation, the absence of a shared standard is a vacuum that teams fill independently - each making a locally rational decision that creates a globally irrational system.

The MCP equivalent: without governance, every team designs its own simple system. The risk team builds an MCP server for their data warehouse. The finance team builds a different MCP server for the same data warehouse with different auth. The platform team builds a third server that partially overlaps with both. The agent now sees twelve tools that do variations of the same thing. The people who built them have moved on. No deprecation path exists. This is not a hypothetical - it is the same pattern that played out with internal REST APIs at most large organisations that adopted microservices without a service catalogue, and it is already starting to repeat with MCP.

The structural cause is Hyrum’s Law: observed by Google engineer Hyrum Wright and now widely referenced in software engineering: “With a sufficient number of users of an API, it does not matter what you promise in the contract — all observable behaviours of your system will be depended on by somebody.”

Once a team starts using your MCP server, they will depend on its undocumented behaviours. Deprecating it without governance becomes painful very quickly.

Treating MCP servers as infrastructure from the first deployment - with an owner, a version, a changelog, and a deprecation policy is not bureaucracy. It is the thing that lets you move fast in two years without digging out from under your own sprawl.

MCP doesn’t answer the data residency question

MCP doesn't answer the data residency question, and neither should it, but because MCP makes it trivially easy to spin up a new server anywhere, teams are creating new data residency exposure points faster than they're tracking them.

This is the failure mode that almost never appears in ecosystem documentation and is the one most likely to cause a material incident in regulated industries.

When an agent calls an MCP tool, data flows in both directions: the arguments sent to the tool, and the response returned. In a regulated context, both can contain customer data, personally identifiable information, or material non-public information. The question of where that data flows - which process handles it, which logs capture it, which jurisdiction it transits through - is not answered by the protocol. That is not a criticism of MCP. It is simply a boundary you need to understand.

The MCP server is a process. That process can run anywhere. If it runs in a container in a region that is not approved for the data it is handling, you have a data residency violation before the tool even returns a result. If the tool call arguments are logged by intermediary infrastructure before reaching your server, you have a data handling question that needs a documented answer.

For UK firms post-Brexit, this intersects with UK GDPR, FCA data governance expectations, and potentially the location requirements of your outsourcing arrangements. The compliance question is not “does MCP support data residency?” - it does not operate at that layer - but “can you trace every byte of this tool call, confirm where it went, and show it never left an approved boundary?”

That answer requires mapping the full data flow before deploying any MCP server that touches regulated data. Not after the first incident.

Do you actually need MCP?

I see it commonly - every team jumps to the conclusion of using MCP very fast. MCP is infrastructure and infrastructure has a cost - operational overhead, governance burden, complexity. The Unix philosophy, articulated by Doug McIlroy in the early 1970s, puts it plainly: “Write programs that do one thing and do it well.” Before you introduce a protocol for interoperability, ask whether you actually need interoperability.

Here is a decision tree I like to use to help teams make that decision:

Let’s make each branch concrete.

• When direct function calling is the right answer

  If you have a single agent, a small number of tools, and no requirement for reuse across teams or frameworks, native function calling in the Anthropic SDK is simpler, cheaper, and easier to observe. No additional process boundary. No MCP server to maintain. No capability discovery overhead. Adding an MCP server here is the software equivalent of installing industrial plumbing to fill a kettle.
  

• When a well-governed existing API beats MCP

  If the downstream system already has a REST or gRPC API with proper authentication, rate limiting, observability, and documentation - a Salesforce API, an internal risk platform, a data catalogue with its own REST interface, wrapping it in an MCP server often adds a layer without adding value.
  

  The test is simple: does the MCP layer provide something the existing API does not? If the answer is capability discovery for agent consumption, standardised schema, or unified access across multiple systems, MCP earns its keep. If the answer is “it’s just a wrapper,” you’ve added a process boundary, a deployment artefact, and an operational dependency for no functional gain.
  

• When an async pattern is the right architecture

  MCP is synchronous request-response. The agent calls a tool, blocks, and waits. That is fine for fast, bounded operations. It is the wrong shape for long-running jobs (submit and poll, not block), audit-required fire-and-forget (a message queue with dead-letter handling gives you durability and replay that MCP cannot), and event-driven workflows where the agent should be consuming from a stream, not polling in a loop.

MCP solves a specific problem well. The mistake is treating it as the default integration pattern for anything agent-related, rather than the right answer to a specific architectural question.

One pattern that works

Let me show you an architecture pattern to address these failure modes above. First, let’s understand the few best practice that matter here. It a bit of recap, but worth a refresh.

1. MCP servers are infrastructure, not glue code. You need an owner, you need versioning, changelog, deprecation policy. It should be registered in your internal catalogue and deployed through the same pipeline as your other services.
   
   “Who owns this MCP server?” should have a human name attached to it.

2. Every tool call must be observable. Instrument at the boundary - in the layer between the orchestrator and the MCP session - not inside the server. The instrumentation wrapper is shared infrastructure, not something each team spends time re-implementing.

3. The model never touches credentials or entitlements directly. There is always an authorisation layer between the model’s invocation decision and the tool’s execution. This is not optional in a regulated environment. It is least privilege applied at the agent layer.

4. Credentials are runtime injection, not baked-in secrets. Retrieve credentials at server startup via your secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) - never at image build time, never from environment variables baked into a container. The credential is never in your code, never in your image layer history, and has a documented owner and rotation policy. Rotation is handled by the secrets manager; the server picks up new credentials on the next startup cycle.

5. Define quality before deployment using Evals. The observability focus in production must be preceded by rigorous quality assurance during development. And these ar enot unit tests - you need systematic measurement of the LLM's ability to use the tool correctly. Advocate for comprehensive evaluation tasks grounded in complex, real-world scenarios to measure tool efficacy. For debugging, run these evaluations programmatically, instructing agents to output their reasoning steps alongside the tool invocation. This practice helps developers probe exactly why an LLM selects or struggles with specific tools, ensuring the quality of the non-deterministic contract before it is exposed to regulated production environments.

Every tool call passes through the Guardrail Layer before it gets anywhere near the MCP server. That layer validates tokens, masks PII, fetches credentials from the Secrets Manager at runtime, and writes an immutable audit entry before execution starts. The MCP server receives a clean, credentialled, traced call. The response comes back, gets sanitised, and the trace span closes. The user gets a safe payload. Nothing touches the downstream system without a paper trail.

Conclusion

MCP is the right abstraction at the right layer. The standardisation problem it solves is real, and the use cases where it works well are genuinely valuable enterprise problems. The protocol is not the issue.

What history tells us from USB to REST to microservices is that good protocols get adopted faster than the discipline to deploy them safely.

That gap is where incidents come from. This is commonly described as the difference between a sharp knife and a blunt one: the sharp knife is more dangerous in the wrong hands, but it’s the right tool for someone who knows what they’re doing.

The teams that get this right usually ask the boring questions first - who owns this, where does the data go, what happens when this call fails at 2am - and build systems accordingly.

That’s not caution. That’s just engineering.

Using or building with MCP?

Don't let speed compromise security. Apply the governance and architectural rigor outlined here to your MCP servers now. Build your Authorization and Observability Layer first to ensure your tool calls are secure, auditable, and compliant from day one.

Tell me in comments whether this resonates, what other challenges are you facing, and where did MCP do the magic for you. I am eager to learn from your experience - so please comment, leave a feedback.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

But as teams push these systems into production, they are hitting a wall. Having five smart agents does not automatically equal one smart system.

The industry is quickly learning a hard lesson: orchestration is an understood problem, and communication reliability is the actual bottleneck . You can easily instantiate ten agents using frameworks like LangGraph, AutoGen, or CrewAI. But getting them to talk to each other reliably without hallucinating payloads, dropping context, or getting stuck in infinite loops is where the real engineering happens.

Let’s break down the first principles of agent communication, look at how they fail in production, and explore how modern production systems are solving these exact problems.

The First Principles of Agent Communication

At its core, getting agents to collaborate requires the same fundamentals as distributed computing, but with a chaotic twist: the “nodes” in this network are non-deterministic text engines.

1. Message Passing

Principle: Message passing is the transfer of information from one node to another. When Agent A finishes its job, it must hand off a payload to Agent B to trigger the next step.

• Failure Mode: The Hallucinated Payload.

• Example: A Data Extraction Agent is told to pull a user’s ID and pass it to a Database Agent. Instead of passing 12345, the agent passes, “Here is the user ID you requested: 12345.” The Database Agent expects an integer, receives a conversational string, and crashes.

  

• Why it happens: LLMs are fine-tuned to be helpful conversationalists, not strict state machines. Without hard constraints, they inject pleasantries and markdown formatting into their outputs, corrupting the message payload.

2. Protocols and Interfaces - H2A, A2C, A2A

Principle: Protocols dictate the rules of engagement. In modern agentic systems, we categorize these interfaces into three distinct buckets:

• H2A (Human-to-Agent): Conversational, unstructured, and forgiving (e.g., ChatGPT).

• A2C (Agent-to-Computer): Rigid and deterministic. The industry standard here is the Model Context Protocol (MCP). Introduced by Anthropic in late 2024 and now hosted under the Linux Foundation, MCP standardizes how agents securely connect to external tools, IDEs, and databases.

• A2A (Agent-to-Agent): Peer-to-peer communication between two non-deterministic models. This is historically the most fragmented layer, but the industry recently coalesced around the Agent-to-Agent (A2A) Protocol. Originally released by Google in April 2025 and unified with IBM’s Agent Communication Protocol (ACP), A2A is now a Linux Foundation open standard for cross-framework agent discovery and task delegation over HTTP and JSON-RPC.

• Failure Mode: Interface Confusion.

• Example: A developer uses MCP to perfectly connect a Research Agent to a PostgreSQL database (A2C). But when the Research Agent hands the data to a Writer Agent (A2A), the developer lets them communicate in conversational English. The Writer Agent misinterprets the unstructured text and hallucinates missing facts.

• Why it happens: Developers often treat A2A communication like H2A communication. Unless you enforce machine-readable protocols for peer-to-agent handoffs, conversational drift will inevitably break your architecture.

3. Shared Context and State

Principle: Agents need a shared understanding of the environment, current progress, and available data to collaborate effectively.

• Failure Mode: Context Desynchronization.

• Real-World Example: A Researcher Agent analyzes a 50-page PDF and passes a brief outline to a Writer Agent. The Writer tries to draft the article but fabricates details because it lacks access to the source material.

• Why it happens: Context windows are expensive. To save tokens and latency, builders often restrict the context passed downstream. This creates asymmetric information - Agent A knows something Agent B doesn’t, leading to poor decisions.

4. Intent Alignment

Principle: Every agent in the chain must understand the overarching goal of the user, not just its localized sub-task, to ensure the final output is cohesive.

• Failure Mode: The Telephone Game.

• Example: A user asks for a “brief, humorous summary of the latest AI news.” The Manager Agent passes the news to the Summarizer Agent but forgets to include the “humorous” instruction. The Summarizer writes a dry academic brief.

• Why it happens: Information decays across hops. When breaking a complex prompt into smaller agentic tasks, the nuance of the original user prompt is easily lost in translation.
  

  

5. Memory and Feedback Loops

Principle: When Agent B rejects Agent A’s work, Agent A needs memory of the failure and the ability to correct itself without repeating the exact same mistake.

• Failure Mode: The Infinite Death Spiral.

• Example: A Coding Agent writes a Python script. The Execution Agent runs it, encounters a SyntaxError, and passes the error back. The Coder apologizes, generates the exact same code, and sends it back. They repeat this loop 50 times until the API budget is drained.

• Why it happens: LLMs are highly sensitive to their immediate context. If the feedback isn’t explicit, or if the model’s internal weights heavily favor a flawed syntax pattern, it will deterministically generate the same wrong answer.

How To Solve This - Patterns That Are Working

Building reliable multi-agent systems requires shifting your mindset from “prompt engineering” to “protocol engineering.” Here is how top-tier engineering teams are building resilience into their agent networks.

1. Enforce Structured Outputs (a.k.a Strict Schemas)

Never let agents talk to each other in free-text prose if they are exchanging data. Treat agent communication exactly like an API. Use tools like OpenAI’s Structured Outputs, Pydantic, or standard Python libraries like instructor to enforce JSON schemas. If Agent A needs to pass an ID to Agent B, structurally guarantee that the output is only a valid JSON object matching your exact schema.

2. Adopt Standardized Protocols

Stop reinventing the wheel for tool use and communication. Implement MCP for all A2C interactions to securely connect your agents to external systems. For A2A interactions, adopt the A2A Protocol to standardize payload structures instead of injecting variables into conversational prompt templates. Leveraging these standards ensures your agents can operate reliably across different platforms and enterprise environments.

3. Centralize State (The “Blackboard” Pattern)

Instead of passing massive context back and forth between agents like a hot potato, use a centralized state mechanism. In graph-based frameworks like LangGraph, all agents read from and write to a single, shared state object or “blackboard.” This ensures no agent is operating on outdated or asymmetric information.

4. Implement Observability and Tracing

When a multi-agent system fails, it fails silently and weirdly. You cannot debug these systems with standard print statements. You need dedicated LLM observability platforms like LangSmith, Langfuse, or MLflow 3.0 to trace the exact input, output, and execution path of every single node. If the Telephone Game happens, you need to see exactly which agent dropped the context.

5. Defensive Programming: Retries and HITL

Expect agents to fail. Wrap inter-agent communication in standard retry logic with programmatic guardrails (like NVIDIA’s NeMo Guardrails). If Agent A sends malformed data, catch the error programmatically and format it into a rigid prompt to force a correction. For critical workflows like writing to a production database (or deleting production databases) - enforce a Human-in-the-Loop (HITL) pause. Let the system wait for human approval before executing destructive actions.

Lessons Learnt

• Treat agents like microservices: A2A communication should mirror microservice architecture. Define rigid, structured API contracts for every handoff and validate payloads before they reach the next node.

• Embrace MCP and emerging standards: Separate your A2C (tool use) from your A2A (agent coordination). Use standardized open-source protocols like MCP and A2A to offload the complexity of system integrations so your agents can focus on logic.

• Cap your feedback loops: Always implement hard limits on iterative loops. If agents go back-and-forth more than three times without success, throw an exception and escalate to a human or a deterministic fallback script.

• Persist the global goal: Inject the original user intent into the system prompt of every agent in the pipeline. Do not assume intent will survive passing through three different LLM nodes.

Multi-agent architectures are the future of complex AI applications, but they require rigorous distributed systems engineering. By enforcing strict protocols and shared state, you can stop the silent failures and build agentic systems that actually work in the real world.

See It In Action

I’ve talked about the common patterns and failure modes of multi-agent orchestration and how to design for them in this video. Have a look.

As always your comments and feedback are welcome. Please share your experience and thoughts.

Thanks,
Sandi.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

If you are reading yet another think-piece on “scaling autonomous agents” or “optimizing your basic RAG pipeline,” you are observing the trailing edge of the industry. We all know the standard playbook by now: deploy an LLM-as-a-judge, set up a vector database, and run basic semantic search. That is no longer a competitive advantage; it is table stakes.

To survive in production at scale today, engineering teams must stop treating generative models like brilliant, autonomous colleagues and start treating them like chaotic, highly expensive engine components.

Here are the three architectural blind spots that standard DevOps playbooks are ignoring - and how to fix them.

1. Stop Building Agents. Build State Machines.

The current industry obsession is giving LLMs autonomy - letting them chain tools, determine their own loops, and “think” their way out of problems. However, in an enterprise production environment, autonomy is just another word for liability.

You do not want an autonomous agent; you want a rigid, locked-down Finite State Machine (FSM).

Your software architecture should entirely dictate the exact path, the boundaries, and the execution graph. The LLM should only be utilized for the transition logic. Its sole job is to ingest messy, unstructured user input and output a deterministic decision: “Do we transition to State A or State B?”

By stripping the model of its agency and restricting it to routing and classification, your latency drops, your reliability scales, and crucially, your system becomes highly debuggable when an edge case inevitably breaks the flow.

2. Eradicate the “Politeness Tax”

If you audit your raw token logs, you will likely find that you are paying thousands of dollars a month - and sacrificing hundreds of milliseconds of latency per request - just to let your model clear its throat.

Every time a background model outputs, “Certainly! I’d be happy to extract that data for you. Here is the requested JSON:”, you are burning compute. At scale, politeness is an engineering flaw.

You cannot fix this with prompt engineering alone. You must enforce strict grammar constraints at the inference level. Do not politely ask the model to return JSON in the system prompt; force the API to accept { as the absolute only valid first token. Strip out all conversational abilities from your background processing models.

You do not need a polite assistant in your backend data pipeline; you need a ruthless text calculator.

3. Neutralize “Zombie Memory” in Semantic Caching

Semantic caching is universally recommended to reduce API costs. A user asks a question, you embed it, check if you have answered a mathematically similar query recently, and return the cached answer.

What nobody discusses is semantic cache rot. If you are caching answers about dynamic data, like your pricing tiers, live inventory, or active user permissions, the underlying reality will eventually change, but your vector cache remains static. When this happens, the cache intercepts the query and serves up a perfectly formatted, highly confident answer that is now entirely false. Your system isn’t hallucinating; it is remembering a dead reality.

To solve this, a simple Time-to-Live (TTL) expiration is insufficient. You must bind your vector cache invalidation directly to your database webhooks. If a product goes out of stock in your primary database, your system must aggressively and automatically flush the neighborhood of vectors in your cache that map to that specific product’s metadata.

The Takeaway

Moving AI from a compelling local demo to a hardened production environment requires a fundamental shift in engineering mindset. It is not about finding the perfect prompt or chasing the newest foundational model.

The best AI engineers do not try to find perfect model outputs . They build perfect architectural nets to catch the model when it inevitably behaves unpredictably.

What is your production AI blind spot?

We are all writing the playbook for production AI in real-time, and the best lessons come from the trenches, not the demo environments. Hit reply and tell me about the weirdest silent failure mode you have caught in production recently, the one that no standard DevOps tool saw coming.

If this issue helped you rethink your architecture, do me a favor: forward it to the engineer on your team who is currently trying to solve a systems problem with another paragraph of prompt engineering.

Talk soon,
Sandi.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

A team deploys an AI system into production. It passes every evaluation they ran. Accuracy looked good. The stakeholder demo went well. The pilot was declared a success. Three months later, the system is quietly shelved because the outputs no longer make sense - or worse, they never did, and nobody caught it until real users started complaining.

When I dig into what went wrong, I often find the shape of the evaluation resulting in low quality agentic decisions.

The teams running linear eval pipelines - input goes in, score comes out - are measuring a snapshot of a moment. They are not measuring how their system behaves as context shifts, as data drifts, as agents hand off to other agents, as the real world does what the real world always does. They are measuring a straight line. Their system is a graph.

That mismatch is why so many AI evaluations feel thorough and turn out to be worthless.

Pipelines vs Graphs

The word ‘pipeline’ is everywhere in AI engineering. Data pipelines, inference pipelines, eval pipelines. We’ve adopted it as the default mental model for how AI systems work.

And for a lot of data engineering, it’s correct. Data flows in one direction. You extract, you transform, you load. A pipeline is a clean metaphor because data really does flow like water through a pipe.

But AI systems in production - especially multi-agent systems, RAG architectures, and anything that has to maintain context across multiple turns or tool calls - do not behave like pipelines. They behave like graphs. There are loops. There are conditional branches. There are nodes that depend on the state of other nodes that were resolved two steps earlier. Context that was established at step one can poison or distort the output at step seven.

When you evaluate a graph as if it were a pipeline, you get a false sense of confidence. You test the happy path. You test the input-output pair. You miss the edges. You miss the feedback loops. You miss the context that has been accumulating and silently corrupting your system’s reasoning.

I’ve started calling this context drift - the phenomenon where a system’s outputs because the context it’s operating in has shifted in ways your evaluations weren’t designed to detect. A pipeline eval can’t catch context drift. Only a graph-shaped evaluation can.

What is an Evaluation Graph?

The Evaluation Graph is not a tool or a framework you install. It’s a mental model - a different way of thinking about what you’re actually evaluating and when.

In a pipeline eval, you define a set of test cases, run your system against them, and score the outputs. Done. Repeatable. Clean.

In an evaluation graph, you map out the nodes of your system - the points where decisions are made, where context is retrieved, where agents hand off to each other, where state is read or written - and you evaluate at each node, not just at the final output.

Here is what that changes in practice.

First, you gain localised failure detection. When a pipeline eval fails, you know something went wrong. You don’t know where. When a graph eval fails, you know exactly which node broke down - was it the retrieval? The reranker? The summarisation step? The router that decided which agent to call? You can fix what’s actually broken instead of rerunning the whole system hoping for different results.

Second, you can evaluate context propagation. I have seen this skipped many times. It’s not enough to evaluate whether each node produces a good output given its input. You need to evaluate whether the context being passed between nodes is coherent, relevant, and not accumulating noise. I’ve seen systems where individual components all scored above 90% in isolation, but the system as a whole produced nonsense because each node was passing slightly degraded context to the next one. No pipeline eval would catch that.

Third, you can evaluate decision boundaries. Multi-agent systems have routing logic - conditions that decide which agent runs next, or whether to escalate, or whether to call a tool. These decision boundaries are often the most fragile part of a production AI system, and they’re almost never tested explicitly. In an evaluation graph, they are nodes. They get evaluated just like everything else.

How to Build One

Starting with the evaluation graph doesn’t require you to throw away your existing evals. It requires you to extend them in a specific direction.

The first step is decomposition. Draw out your system - literally, on a whiteboard or in a diagram - and identify every point where a meaningful decision is made or meaningful state changes. Each of those points is a node. Each connection between nodes is an edge. What you’re drawing is the evaluation graph. Most teams are surprised by how many nodes they find that they’ve never evaluated.

The second step is context mapping. For each edge in the graph, define what context is being passed from one node to the next. What does the downstream node need to function correctly? What could the upstream node pass that would corrupt the downstream output? These become your edge-level test cases - not just input-output pairs, but context-propagation scenarios.

The third step is failure mode enumeration. For each node, ask: what does this node look like when it’s failing quietly? Not failing loudly - that’s easy to catch. Quiet failures are the dangerous ones. A retrieval node that returns plausible but wrong documents. A router that sends requests to the wrong agent 15% of the time. A summarisation step that subtly omits the most important information. These failure modes need to be in your evaluation suite explicitly. If they’re not, you won’t find them until a user does.

The fourth step, and this is where graph-shaped evaluation really separates from pipeline evaluation is composing your node-level evals into end-to-end scenarios that test the interaction effects. Not just ‘does node A work’ and ‘does node B work’, but ‘when node A produces this class of output, does node B degrade in a predictable way’. The interactions between nodes are often where production AI systems fail.

This Needs a Shift in Mindset

The teams that build AI systems that hold up in production are building the most rigorous evaluation infrastructure. And rigorous evaluation infrastructure starts with a simple question: is my evaluation shaped like my system?

If your system is a graph and your evaluations are pipelines, you have a gap. That gap is where production failures live.

The evaluation graph is not a perfect solution - no evaluation framework is. Context still drifts in ways you won’t anticipate. Failure modes you didn’t enumerate will still appear. But it gets you structurally closer to what’s actually happening in your system, and that’s the difference between catching problems in staging and catching them after a customer has seen them.

This is one of the core concepts I’m currently working on. If it resonates with what you’re seeing in your own work, I’d genuinely like to hear about it. Hit reply and tell me what you see. The patterns you share inform what I write next.

Talk soon,
Sandi

👉 I wrote more about the Eval Graphs in my article on Atlan’s community substack.

Context & Chaos

Context Graphs as AI Evaluation Infrastructure

About the Author: Sandipan Bhaumik have spent almost 2 decades building Data & AI foundations. Now, through AgentBuild Weekly, he shares how builders and founders can move beyond AI hype to create Agentic systems that think, adapt, and truly work…

Read more

2 months ago · 11 likes · Sandipan Bhaumik

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.

More valuable content coming your way.

Share agentbuild.ai

It’s the person who gets pulled into the room when the demo worked brilliantly and the deployment didn’t. The person who has to figure out why a system that impressed everyone in the boardroom is now sitting in a security review queue with no clear owner, no evaluation criteria, and a go-live deadline nobody wants to move.

That person is usually a Solutions Architect.

And in this new world of AI transfomration architects are lacking the frameworks to match the responsibility they’ve been handed.

What the role has become

I’ve spent eighteen years in enterprise data and AI. The last several watching what happens when organizations decide to take AI seriously.

Here’s what I keep seeing: Solutions Architects are becoming the load-bearing wall of AI transformation programmes. By default.

They’re the ones who understand both the technology and the business context. They’re trusted enough to sit in executive sessions and technical ones. They have enough credibility to push back on vendor claims and enough pragmatism to know what actually ships.

So they get handed things. Big things.

Define the production readiness criteria. Assess whether the data infrastructure can support this use case. Figure out who owns the outcome when the model is wrong. Translate what the VP wants into something the engineering team can build. Get security and compliance aligned before the launch date nobody will move.

That’s not an implementation role. That’s an organizational diagnostic role. And most architects are not prepared for it.

The gap nobody names

The architects I see are not struggling because they can’t build. They can build. They’re struggling because the job has shifted from build to diagnose, and they don’t yet have the instruments for it.

When a doctor walks into a room, they’re not improvising. They have a diagnostic protocol. Repeatable questions. Known patterns. A framework that tells them what to look for and in what order, so they can tell the difference between something that needs immediate intervention and something that needs monitoring.

Right now, most architects walking into an AI programme are improvising. Drawing on instinct built from past projects. Pattern-matching against things they’ve seen before, hoping the pattern holds.

Sometimes it does. Often it doesn’t.

And when it doesn’t, the cost isn’t just the failed project. It’s the six months of organizational trust that went with it. The next AI initiative that’s three times harder to fund because this one didn’t ship. The architect who now has a complicated story to tell about why the thing they led didn’t work.

What real preparation looks like

I’ve been thinking for a long time about what it would mean to give architects the diagnostic tools they actually need. Something closer to a practitioner’s handbook for the organizational side of AI deployment. Not a vendor comparison or a tutorial on which framework to use.

The kind of resource that helps you walk into an early-stage AI programme and ask the right questions before anyone starts building. That gives you a structured way to identify where the real risk is - not the model risk, but the Data Debt sitting in pipelines that haven’t been touched in three years. The Decision Debt in an organization where nobody has agreed on who owns an AI error. The Evaluation Debt in a team that’s been running vibe checks and calling it validation.

The kind of resource that helps you have the conversation with the VP that reframes the whole initiative - not as a technology project, but as an organizational readiness problem that happens to have a technology solution.

That’s the conversation that changes outcomes. And most architects don’t have a framework for it yet.

Why I’m spending time on this

I’ve watched enough of these programmes - close enough to see the failure modes in detail - that the patterns are starting to feel predictable. Which means these are preventable.

I can walk into a kickoff meeting now and have a reasonable sense of what’s going to go wrong six months later. Not because I’m smarter than anyone in the room. Because I’ve seen it before. Enough times that it’s stopped feeling like bad luck and started feeling like a diagnostic problem with a known set of causes.

What I want to do - what I’m actively working on - is make that pattern recognition transferable. To give architects the frameworks that took me years of seeing things go wrong to develop, so they don’t have to learn the same lessons at the same cost.

That’s the work I’m orienting around. That’s the shape I want to give this community.

If you’re an architect who’s been handed one of these programmes - or knows you’re about to be - I’d genuinely like to hear what’s hard about it right now?

Talk soon,
Sandi

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

Let me explain.

Flight data recorders (FDR) are popularly know as the black box of the aircraft. Technically the black box contains the FDR and the Cockpit Voice Recorder (CVR). The FDR turns raw sensor traces into timelines that explain crashes, reveal root causes, and drive global aviation safety improvements. Before flight data recorders were mandated, when something went wrong, investigators worked from witness accounts, wreckage patterns, and whatever instruments happened to be installed at the time. The analysis was mostly incomplete, often contradictory, and it rarely led to systemic changes.

The aviation industry knew flying was becoming more consequential with more routes, more passengers, more complex airspace, but the infrastructure to understand why things failed hadn’t kept pace with the deployment of the systems themselves. It was invented in response to the recognition that consequential systems operating at scale need a structured record of their reasoning - not just their outcomes.

AI agents are at the same inflection point today. And the industry, especially in the regulated space is recognizing that.

What’s the gap right now?

An AI agent deployed in a production system today typically produces two things: an input log and an output. What it doesn’t produce is the reasoning chain between them in any structured, queryable, auditable way .

This gap has a name. It’s called Decision Debt, one of the three categories of debt that block AI from working in production. Decision Debt accumulates when you build and deploy AI systems before defining how decisions get made, recorded, and reviewed. It’s not a future problem. It’s accumulating now, in every agent deployment that ships without trace infrastructure.

A decision trace is the record of how an agent got from context to conclusion: what it knew, what it considered, what it weighted, what it discarded, and at what confidence level it committed to an action.

IMPORTANT: It’s not a log file. Logs capture events. Traces capture reasoning.

The distinction matters because when something goes wrong - and in any system operating at scale, you need to answer a different set of questions than a log can address.

Answering “what happened” is not enough, but “why did the agent conclude that, given what it had access to?” matters more.

This is a historical pattern

Aviation gets to the black box through painful iteration. Financial services gets to trade surveillance infrastructure the same way. Healthcare builds clinical decision support audit trails only after near-misses force the question.

The pattern across every regulated industry is identical: consequential system deploys, operates without adequate observability, incident occurs, retroactive audit reveals the trace infrastructure was never built, expensive fixes follow.

What’s different with AI agents is that we can see this pattern coming before the incidents accumulate. The decision trace problem is visible now, in advance, to anyone who has watched the previous cycles play out in adjacent domains.

Nuclear power operations built decision logging infrastructure into control room design before widespread deployment. And that’s not because regulators demanded it initially, but because the engineers understood that a system making consequential decisions in real time needed to be interrogable after the fact.

The Chernobyl investigation was partially possible because operator actions were timestamped and sequenced. The lessons extracted shaped reactor design globally.

The equivalent for AI agents isn’t complicated in principle.

It is, however, work that almost nobody has started.

What Decision Trace Infrastructure actually need?

The architecture for a decision trace system has five functional layers, and each one has a specific job. Here’s how they fit together.

1. Input Capture Service is where the trace begins - at the moment a request enters the system. Query, user identity, session context, and request metadata are captured here, backed by a metadata store (PostgreSQL can be a straightforward choice). This is the “who asked what, when, and from where” layer. Without it, you have no anchor for the rest of the trace.

2. State Retrieval and Context Snapshot captures the world as the agent saw it at decision time: which data versions were active, which policy definitions were in force, which catalog references were resolved. This layer pulls from a prerequisites datastore - Redis for low-latency state, S3 for snapshot durability. It’s also the layer that makes post-incident analysis possible. When you need to understand why the agent concluded what it did three months ago, you need to know what it knew at that moment - not what the system knows now.

   This layer is, in practical terms, where a context graph lives - even if most implementations don't call it that yet. A context graph is simply the structured representation of what the agent knew and how those things related to each other at decision time: data assets, policies, catalog nodes, versions, and their connections. The reason "context graph" is gaining traction as a term without a settled definition is precisely because this layer has been missing from most agent architectures. Once you build the snapshot layer properly, you have one.

3. Reasoning Chain and Decision Engine is the core trace layer. Chain-of-thought steps, intermediate logic, intermediate outputs - all captured as structured records. It is the path the agent took to reach the final answer. Every branch, every intermediate conclusion, every tool invocation that shaped the reasoning is an addressable record here.

4. Policy Binding Service records the guardrails, rules, and decision logic that were active during the reasoning process. This is what separates a decision trace from a debugging log. You’re not just capturing what the agent did, you’re capturing the constraints it was operating under. When a compliance team asks “was the agent following the policy that was in force on this date,” this layer answers that question directly.

5. Outcome and Action Capturing records the final response, the action taken, and critically - any redress or complaint data attached to that outcome. This closes the loop between the agent’s decision and its real-world consequence. It’s also the layer that feeds dispute resolution workflows when customers or regulators challenge an outcome.

All five layers feed into an Immutable Audit Record - timestamped, hashed, and written to an immutable trace store (S3, Delta Lake or a ledger database). The immutability is a must-have. It is the architectural guarantee that the record cannot be altered after the fact, which is what makes it defensible in a regulatory or legal context. The diagram you see specifies retention period, which aligns with financial services conduct requirements and is a reasonable baseline for any regulated environment.

From the trace store, a Trace Query Service and Data Lake make the records queryable at scale. This is the operational distinction you need to understand. A queryable trace lets you ask: “Show me every decision where the policy binding service applied rule X and the outcome was Y.” That’s the difference between evidence and insight.

The four downstream outputs from this architecture tell you exactly what it’s designed to serve: Redress and Dispute Resolution (when a decision is challenged), Audit Trail Reporting (when a regulator asks), Debugging and Root Cause Analysis (when something fails), and Improvement and ML Training (when you want to make the system better using real decision data).

No single layer here is novel in isolation. Input capture, immutable storage, policy versioning exist in adjacent systems already. What doesn’t exist yet, in any standardised form for AI agents, is this stack assembled as a coherent, purpose-built trace infrastructure. That’s the gap this architecture closes.

Why enterprise architects need to move on this now

This infrastructure is necessary to build the cleanest parth through regulatory scrutiny, incident response, and enterprise customer due diligence. The same principle made structured engineering logging standard practice in distributed systems. You cannot debug what you cannot observe. You cannot improve what you cannot measure. And you cannot defend in a board meeting, a regulatory inquiry, or a customer audit what you never recorded.

Decision traces are the observability layer for AI reasoning. It is the infrastructure equivalent of distributed tracing in microservices, now applied to systems that don’t just execute code, but form conclusions and take actions.

The good news is that this is buildable now, with current tooling, before the incidents force it. The question is whether engineering organisations treat it as foundational infrastructure from the first production deployment, or discover its absence after the fact.

Call To Action

If you are building AI agents for anything consequential, the time to design trace infrastructure is before the first production deployment. Start by mapping which decisions your agent makes that you could not currently explain, audit, or defend: that list is your build priority.

If this framing is useful, share it with the architect or engineering lead on your AI team - this is the conversation that needs to happen before the system goes live, not after.

Leave a feedback or comment. Share your opinion about this topic.

Thanks,
Sandi.

👉 You might also find my article published on Atlan’s community Substack useful:

Context & Chaos

Context Graphs as AI Evaluation Infrastructure

About the Author: Sandipan Bhaumik have spent almost 2 decades building Data & AI foundations. Now, through AgentBuild Weekly, he shares how builders and founders can move beyond AI hype to create Agentic systems that think, adapt, and truly work…

Read more

2 months ago · 11 likes · Sandipan Bhaumik

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

I owe you an explanation for going quiet last Saturday.

We took an Easter break as a family - properly offline, no laptop, in the English countryside. It was superb, the rolling green fields actually delivered on the promise. - and it was sunny ☀️

Right. I’m back. And there’s quite a lot to catch you up on.

I was at an AI engineering conference this week

And I gave a talk, it will be out soon. This is the first time it happened in Europe and I got to meet so many smart, talented founders and engineers. It was awesome experience. In-person events are irreplaceable.

I attended some fabulouse sessions on cutting-edge stuff on AI. And of course OpenClaw dominated the discussion.

Check out the conference here: https://www.ai.engineer/europe

I also made it to the online track of the conference

And the topic was something I’ve been working towards for a while - Multi-Agent Orchestration Patterns for Production.

The core argument: the field is moving fast, but most teams hit the same wall. They build multi-agent systems like they built single-agent systems. Same assumptions, same trust in the “it works in the demo” signal. And then production arrives, and nothing holds.

The talk walked through choreography vs orchestration, immutable state patterns, circuit breakers, and why distributed systems thinking is no longer optional if you’re building agents at any meaningful scale.

Check it out.

A piece I wrote just went live

This one has been in the works for a while, and I’m genuinely proud of it.

I wrote a guest article for Context & Chaos introducing two concepts I’ve been developing from my work with regulated enterprises: context drift and the evaluation graph.

When an AI system gives you an answer, that answer wasn’t produced in a vacuum. It was produced against a specific version of your world - a specific definition of what “active customer” meant that week, a specific policy that was in force that month, a specific dataset that may or may not still exist.

Think of it like this: imagine a doctor’s notes. It’s not enough to record what prescription they wrote. You also need to know what guidelines were current that day, what the patient’s history showed at that point, what the lab results said. Without that context, the notes are incomplete. Enterprise AI has the same problem. We’re recording the prescription. We’re not recording everything else that informed it.

This is original IP, and I think it’s going to become a recurring theme in how regulated industries think about AI governance.

Here is the article:

Context & Chaos

Context Graphs as AI Evaluation Infrastructure

About the Author: Sandipan Bhaumik have spent almost 2 decades building Data & AI foundations. Now, through AgentBuild Weekly, he shares how builders and founders can move beyond AI hype to create Agentic systems that think, adapt, and truly work…

Read more

2 months ago · 9 likes · Sandipan Bhaumik

New YouTube video: The AI Latency Stack

While you’re in content-consumption mode this weekend, I also want to point you to a video I put out recently on AI application latency - it keeps coming up in conversations and I wanted to have something concrete to point people to.

The short version: after your AI system ships to production, the model is almost never the problem. It’s a set of architectural decisions - streaming, database writes on the critical path, cold starts, context window bloat, prompt caching, sequential calls that should be parallel - that compound into something that makes users give up and go back to the manual process. The video walks through seven of these layers and how to address them, without swapping models or changing vendors.

Worth a watch if you’re anywhere near a production AI deployment right now.

That’s it for this week.

A lot happened in a short space of time, and I wanted to share it with you directly. As always - reply if anything resonates, or if you’re wrestling with something I touched on.

Talk soon,
Sandi

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

I’m lucky. My job puts me in front of a lot of engineering teams across a lot of organisations. Some are moving fast. Some are moving slow. And I get to see both. Not from a distance, up close, in the actual conversations where decisions get made.

What I’m watching is a quiet split happening inside engineering teams. And I think it matters for anyone thinking about where this profession is heading.

Two engineers. Same company. Same tools available. Same access to AI. Completely different outcomes.

One of them, when they hit a hard problem, opens a chat window and starts working through it out loud. They dump in the messy context. The half-baked question. The data that doesn’t quite make sense yet. They’re not looking for autocomplete. They’re looking for a way through.

The other one says “AI isn’t reliable enough for this.” And goes back to doing it the slow way.

I’ve watched this play out across banks, fintechs, and large regulated enterprises. And the gap between these two engineers is only getting wider.

What high agency actually looks like

I was working with a team recently trying to make sense of a large pile of unstructured documents. Audit logs, policy docs, historical reports. This kind of work that normally takes weeks of someone’s time.

One engineer on the team didn’t wait to be told how. She had no prior experience with the specific tooling. But she sat down, broke the problem into pieces, and used AI to work through each one. By end of day she had something working. Not perfect. But working.

She didn’t have a playbook. She made one.

That’s what high agency looks like in practice. Not waiting for a process document. Not waiting for someone to say it’s approved. When they hit a wall, the first instinct is to figure out what question to ask - not explain why the wall is there.

What the resistance sounds like

I want to be careful here. The engineers pushing back on AI are not lazy. Many of them are the most experienced people in the room.

But the resistance has a pattern.

“It hallucinates too much for our use case.”

“Security hasn’t signed it off yet.”

“The outputs aren’t consistent enough to trust.”

“This is hype, let it settle.”

Some of these are valid. I work in regulated environments. I understand the constraints.

But what I notice is this. The engineers saying these things have usually not given AI their hardest problem. They’ve given it easy tasks, watched it stumble, and concluded it isn’t ready. They’re evaluating a tool they haven’t really pushed.

The high agency engineers hit the same limitations. They just treat them as constraints to work around, not reasons to stop.

There’s something underneath the resistance

I think it goes deeper than technology skepticism.

A lot of experienced engineers have built their identity around already knowing the answer. They’re the person people come to. The one who’s seen this before.

AI is uncomfortable for that identity. Because the value is shifting. It’s moving away from already knowing - toward knowing how to ask. That’s a different skill. And it asks you to be a beginner again, at least partially.

The engineers I see thriving have a looser grip on what they already know. They’re curious before they’re skeptical.

They pick the tool up before they critique it.

One practical thing

Ask yourself honestly: when did you last give AI your genuinely hardest problem?

Not “summarise this document.” or “tidy up this function.”

The real hard thing. The one you’ve been circling because you don’t quite know where to start.

I’ve seen engineers use AI to compress weeks of analysis into a day. I’ve seen it catch patterns in production failures that a team had been chasing for months. I’ve seen it unlock a business conversation that had been stuck for a quarter - just by helping someone structure their thinking clearly enough to explain it.

None of that happened because the technology was perfect. It happened because someone decided to figure it out.

The job of an engineer is changing. I’m watching it happen. The ones adapting aren’t the most experienced or the most technical. They’re the ones most willing to stay curious.

That’s the only practical advice I have.

One question before you go - what's the most interesting thing you've seen an engineer do with AI that nobody is talking about yet?

Hit reply and tell me.

Talk soon,
Sandi

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

Anyway, I have been following all the updates. I have collected the top things you should know in this newsletter.

Let’s have a look.

Folks, GTC 2026 was the week NVIDIA stopped selling us GPUs and started selling us AI factories - hardware, agents, and even token budgets included. Lovely stuff.

For years, GTC keynotes have been about bigger chips, more FLOPs, and eye‑watering benchmarks. This year was different. Mr. Jensen Huang’s message was clear: the center of gravity is moving from individual accelerators to full‑stack “AI factories” that ingest data on one end and ship intelligence on the other.

1. At the heart of that story is Vera Rubin.

Vera Rubin is an integrated platform: seven specialized chips, multiple rack‑scale systems, a supercomputer, orchestration software, and a roadmap to the next platform, Feynman. If Blackwell was the engine, Rubin is the entire plant. You don’t just get more TFLOPs; you get an opinionated way to build and run agentic systems at scale.

That framing matters if you’re an AI, ML, or data engineer.

Instead of asking “How do I get access to H100s or B100s?”, the real question becomes “Where will my AI factory live, and what will it produce?” That’s a very different conversation about architecture, data, and economics.

2. The trillion‑dollar AI factory build‑out

Mr. Huang also did something subtle but important: he didn’t talk about AI as a feature; he talked about AI as infrastructure. The combined order pipeline he referenced for Blackwell and Vera Rubin runs into the trillion‑dollar range over the next few years. Whether you believe in the exact number or not, the signal is unmistakable.

We’re no longer in the “let’s try a model” phase. We’re in a multi‑year build‑out of AI plants in the same way we once built data centers, clouds, and mobile networks. That means:

• Inference economics become a first‑class design constraint.

• Token budgets will be as real as laptop or SaaS budgets.

• Capacity planning for AI will look more like power and networking planning than like a one‑off POC.

If you’re building products, this is your wake‑up call to treat AI like infrastructure, not a sprinkle of magic dust at the end of a roadmap.

3. The “agentic moment” is now official

Another clear shift: NVIDIA is leaning hard into agentic systems.

NemoClaw and its surrounding tooling were positioned as core to how enterprises will build with these new platforms. The pattern is no longer “one giant model behind an API.”

It’s:

• Tool‑using agents orchestrating calls into models and services.

• Multi‑step workflows that reason, plan, and act.

• Customization and fine‑tuning on your own data, running on your own slice of an AI factory.

Practically, that means agent orchestration, evaluation, and safety move from hacker‑weekend topics to board‑level concerns. It also means AI and data teams who understand tools, context, and control flows will be disproportionately valuable.

4. Hardware envy and the pace problem

There’s a less comfortable undercurrent to all of this: hardware obsolescence.

If you invested heavily in last year’s “AI factory,” GTC 2026 probably gave you a twinge of regret. Rubin‑class systems move the goalposts again. Throughput, efficiency, network architecture - everything just jumped.

Most teams won’t be able to rip and replace every cycle. So the question becomes: how do you architect for optionality?

(By the way, this applies to any production-grade AI system architecture)

A few practical edges:

• Design around portable abstractions (containers, standard runtimes, open protocols), not vendor‑specific stuff.

• Separate concerns: data platform, model platform, agent layer. You want the freedom to swap pieces as the hardware evolves.

• Focus on investments that survive GPU generations: data quality, evaluation, governance, and product integration.

The platforms will keep getting better.

Your moat will be how quickly you can adapt your stack to whatever comes next.

5. Data and the physical world reclaim the spotlight

One of my favorite subplots from this GTC is that structured data, simulation, and physical AI quietly stepped into the spotlight.

DLSS 5 and the new wave of neural rendering aren’t just about prettier video games. They’re about real‑time, photorealistic, physics‑aware environments you can use to train and validate agents. Combine that with better edge hardware and you get a serious push toward robots, industrial agents, and AI systems that interact with the messy real world.

Check this out:

For data people, the implication is simple: tables, events, and logs are still the fuel. For AI engineers, simulations and digital twins are becoming as important as datasets. For product teams, the bar for “realistic” behavior in AI‑powered experiences just went up.

Why this GTC matters for you

If you strip away the marketing, GTC 2026 is telling builders three things:

1. The unit of competition is shifting from model to factory.

2. Agentic systems will be the default pattern for serious AI products.

3. The compounding advantage still comes from data, evaluation, and integration - not just chips.

If you’re in AI, ML, or data, your edge will come from how fast you can align your architecture, practices, and skills with that reality.

What you can actually do next (without a Rubin cluster)

Most of us are not spinning up NVIDIA Vera Rubin systems next quarter. The realistic move is to upgrade how you think, learn, and design.

Here are four learning objectives you can pursue right now:

1. Think in “AI factories,” not just models
   Map your current stack - data collection, feature engineering, model training, deployment, monitoring - against the AI factory idea. Where is data still manual? Where is evaluation an afterthought? Where are agents bolted on instead of designed in from the start?

2. Get comfortable with inference and token economics
   Even if you’re using cheap or free models, start tracking tokens‑per‑feature and cost‑per‑request. A simple spreadsheet or dashboard that shows “this feature costs X per 1,000 users” will change how you design prompts, choose models, and argue for optimizations.

3. Practice building small, robust agentic flows
   Use open‑source frameworks or your favorite LLM stack to wire up basic agents: retrieval + tool calling + simple planning. Focus less on exotic models and more on reliability, evaluation, and clear boundaries for what the agent should and shouldn’t do.

4. Re‑center your work on data, evaluation, and simulation
   Treat your tables, logs, and events as the core asset, not an afterthought. Experiment with offline evaluation harnesses. If your domain touches the physical world, explore simple simulation or synthetic scenarios - even if you’re not using Omniverse‑grade tools yet.​

This is too long already folks. I will stop here.

Thank you for reading, and please leave your comments, feedback. Get in touch, tell me what you are leanring and what you would like to know more of.

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

Last week, I sat down with Hamel Husain for the AgentBuild podcast. Hamel is one of the most influential voices on AI evaluation in the industry right now - the kind of person that other experts quote when they’re trying to explain something difficult. The conversation was one of the most practically useful I’ve had this year, and I want to share the best of it with you.

Who is Hamel Husain?

Hamel is a machine learning engineer with over 20 years of experience. He’s worked at Airbnb and GitHub - where his early LLM research contributed to what eventually became GitHub Copilot. He has led and contributed to popular open-source ML tools, and today he’s an independent consultant who has helped more than 35 organisations build real-world AI products that actually perform in production.

He co-teaches AI Evals for Engineers and PMs on Maven, a course with over 3,000 students from 500+ companies - including teams at OpenAI, Anthropic, and Google. He also writes one of the most substantive technical blogs in the AI space at hamel.dev, and is co-authoring an O’Reilly book on the subject - Evals for AI Engineers.

He is, in short, the person you call when your AI system’s quality is a mystery.

The biggest misconception about AI evaluation

I asked Hamel what the most common mistake is when enterprises approach evaluation. He didn’t hesitate.

“The biggest misconception is that evaluation is as easy as going to a vendor that will give you off-the-shelf metrics in a dashboard. You plug it in, and poof - you’ve done eval. You’ve checked the box.”

He’s seen this play out more times than he can count. The team wires up a platform. They get a dashboard with coherence scores, faithfulness scores, toxicity scores. Everyone feels good for the first week. And then, slowly, people start to realise: those numbers don’t mean anything. No one knows what they’re measuring. They can’t tell if the product is getting better or worse.

Generic metrics don’t correlate to what matters for your specific application. A hallucination score doesn’t tell you if your legal AI is giving dangerous advice. A coherence score doesn’t tell you if your scheduling assistant is actually booking the right slots.

As Hamel puts it: “When I see a company showing me only generic metrics, I already know they’re in trouble. There’s a direct correlation between generic dashboards and teams that feel lost.”

Foundation model evals vs. product evals

There’s a second source of confusion worth naming. When people hear the word ‘evaluation’, many think of the benchmarks that model providers publish - things like MMLU, SWE-Bench, HumanEval. These are foundation model evals. They measure the general capabilities of a model at large. They have almost nothing to do with how well your AI product performs for its specific purpose.

Hamel’s analogy is the one I’ll keep using: Foundation model evals are like a standardised test score. Product evals are like job performance. Your SAT score tells you very little about whether you’ll be a good engineer. The gap between the two can be enormous.

What matters for the enterprise is the second kind. Not ‘how capable is GPT-5 generally?’ but ‘is our claims-processing assistant handling edge cases correctly, and can we measure that consistently?’

Why traditional QA isn’t enough

One of the most common objections I hear from customers: “We already have a QA team. Why can’t they just test the AI?”

Hamel’s answer is direct: treating AI evaluation like traditional software testing is a fundamental mistake.

The reason is determinism. Traditional software has deterministic outputs. You write a unit test: given input X, expect output Y. Pass or fail. With AI, the output is stochastic by design. The system is explicitly built to produce varied responses. You can’t write a unit test for a stochastic system the same way.

What you need instead is something that already exists - but that most AI teams have left behind: data science thinking.

Data scientists have been measuring stochastic systems for decades. They know how to sample, analyse, spot patterns, and design experiments that account for variability. That entire discipline is exactly what’s needed for AI evaluation. We just need to adapt it slightly for LLMs.

Hamel summarises it simply: “Evals are essentially data science for AI.”

The eval loop - how it actually works

Before I go further, let me show you the structure of a proper evaluation loop. This is what we explored together on the podcast earlier this week:

The loop is simple in principle. You feed test inputs into your model. You compare what it produces to what you wanted. You score the gap. And you use that signal to decide what to change - the prompt, the model, the data, or the test cases themselves.

The hard part is what lives inside the “evaluator” box. There are four types of evaluators, each with different trade-offs:

• Exact match - Deterministic scoring. The output must match the expected answer. Fast and cheap, but brittle. Works well for classification, SQL, and structured outputs. Falls apart when the answer is right but worded differently.

• Heuristic - Rule-based checks. Regex patterns, keyword presence, schema validation, length constraints. Good for catching structural failures. Can’t evaluate meaning.

• Human review - Real people read outputs and rate them. The highest nuance. Also the slowest and most expensive. Essential for calibrating everything else, but doesn’t scale to thousands of daily outputs.

• LLM-as-judge - A second AI model evaluates the output against a rubric. Scales well, handles open-ended responses, captures nuance that heuristics miss. But it inherits the judge model’s biases and blind spots. Requires calibration against human labels.

In practice, mature teams use all four. Exact match and heuristics form the fast, cheap baseline. LLM-as-judge handles scale on open-ended outputs. Human review calibrates the judge periodically.

The most powerful habit in AI development

Here’s where Hamel said something that sounds counterintuitive - and that I think is the single most important insight from our conversation.

The highest-value activity you can do when building an AI product is to sit down and look at your data.

Just open your traces, read actual outputs, and write down what you see.

When most people hear this, something in them resists. “In the age of AI, you’re telling me to open a spreadsheet and read individual data points? That can’t scale.”

But Hamel has done this with more than 50 companies. Every single time, people discover it’s not just useful - it’s transformative. They find unexpected failure modes. They identify bugs they didn’t know existed. They develop intuition that no automated system would have surfaced.

And there’s a second reason it matters: looking at data is how you elicit your own requirements. This is what Hamel calls criteria drift. You can write a specification about what a good product looks like. But it’s only when you see real user interactions that you understand what “good” actually means for your context. The process of reading real outputs and writing down what you observe is the process of transferring your taste to the system.

His practical starting point: aim to read at least 100 traces. 100 is not a magic number, it’s a concrete goal that gets people started. Keep reading until you reach what he calls theoretical saturation - the point where new traces aren’t revealing new failure patterns. In his experience, people rarely want to stop.

Who should own evaluation - and how to champion it

The other question I pressed Hamel on was organisational. In a large enterprise with 50 AI use cases in the pipeline, who owns this? Is there a central eval function? Does it sit with a team or a role?

He’s a strong advocate for bottom-up adoption, not centralised mandates. Top-down approaches - “our platform will standardise eval across the organisation” - tend to produce checkbox compliance. Teams grudgingly report metrics nobody understands.

What actually works: start needs-based. One team, one product, one clear problem they’re trying to debug. Embed the evaluation practice into the building process - not as a separate audit step, but as part of how they iterate.

Evaluation must be owned by domain experts, not outsourced to a QA or engineering team. If it’s a legal assistant, a lawyer needs to be in the loop. If it’s a clinical tool, a clinician. The domain expert is the only person with the taste and judgment to say whether an output is genuinely good. The engineering team can build the infrastructure, but the ground truth comes from the domain.

As for championing it internally? Hamel’s advice is the same I’d give for any new practice: don’t sell the methodology. Sell the results.

Don’t walk into a meeting saying “we need to do evals.” Walk in with findings. Show the error rate you found. Show the specific failure pattern you fixed. Show how you caught a regression before it went to production. Once people see that you consistently know more about what the product is actually doing than anyone else in the room, they’ll ask how.

What this means for your enterprise AI programme

If I were to distil everything Hamel shared into the things you can actually act on this week, here’s how I’d frame it:

1. Resist the pull of generic dashboards. If your only eval metrics are off-the-shelf coherence and faithfulness scores, you’re not evaluating - you’re performing evaluation. The metrics that matter are the ones you derive from looking at your own system’s failures.

2. Spend 30 minutes this week reading traces from one of your AI systems. Don’t automate it yet. Just read. Write down what you notice. You’ll find things no algorithm would have flagged.

3. Identify your domain expert. For every AI use case you’re building, there should be a person who has the authority and the proximity to say whether an output is good. That person needs to be in the loop on evaluation, not just the engineering team.

4. When you want to bring others along, don’t present a methodology deck. Present results. Show the before and after. Lead with what changed for the user or the business, and let the process speak for itself.

If you haven’t listened to my conversation with Hamel yet, I’d encourage you to. It’s one of the best discussions I’ve had on what it actually takes to build AI systems that hold up in production - not just in the demo.

I’d love to know what resonated. Reply to this email or comment here - looking forward.

Talk soon,
Sandi

P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

The future of AI is going to be shaped by the people who build it, question it, and decide how it gets used. Right now, women in tech are doing all three - often with less recognition than they deserve.

The field needs more of their voices, not fewer. If you know a woman in tech who is doing great work, today is a good day to tell her.

Now - to this week’s newsletter.

Gartner recently predicted something that made me think hard.

By 2026, they say, roughly half of large organisations will introduce what they’re calling “AI-free skills assessments.”

In plain English: companies are going to start formally testing whether their employees can still think, write, and solve problems without any AI help at all.

Not instead of AI skills. In addition to them.

When I first read that, I thought it was a bit extreme. But the more I thought about it, and the more I thought about what I see inside big organisations every day, the more I think they’re onto something real.

Last month I was in a meeting with a team trying to solve a difficult problem.

Someone suggested asking ChatGPT. So they did. The AI gave them a confident, well-structured answer. Everyone nodded and moved on.

I asked one of them afterwards: “Do you actually think that was the right answer?”

She paused. “Honestly? I don’t know. It sounded right.”

That’s the problem Gartner is trying to name. Not that AI gives bad answers. But that we’re losing the ability to tell whether the answer is good - because we’ve stopped forming our own opinion first.

It’s like becoming so reliant on GPS that you no longer have any sense of direction yourself. Fine, until the signal drops.

Here’s why this matters specifically if you’re learning AI right now.

You’re entering a world where everyone will have access to the same AI tools. The tools are getting cheaper and easier every month.

In two years, using AI competently won’t be a skill that sets you apart - it’ll just be the baseline.

What will set you apart is the judgment to know when the AI is wrong. The ability to ask a better question. The confidence to push back on an answer that sounds plausible but isn’t quite right.

Those things only come from practising thinking for yourself. And that’s the muscle that quietly atrophies when every task starts with “let me ask AI first.”

The people who will get the most out of AI are the ones who bring their own thinking to it - not the ones who outsource their thinking to it.

One small habit worth building now:

Before you open any AI tool for a problem, spend five minutes writing down what you actually think. Not a perfect answer. Just your honest first attempt - in your own words, your own logic.

Then bring in the AI. Compare. Push back where something feels off.

You’ll get dramatically better results from the tool. And you’ll keep the judgment sharp that makes those results mean something.

The companies Gartner is talking about will be testing for exactly that judgment. The good news is it’s not hard to build - it just has to be intentional.

I’m curious whether this resonates. Have you noticed yourself reaching for AI before you’ve really thought something through?

Hit reply - I read every response and it genuinely shapes what I write next.

Talk soon,
Sandi

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

Someone opens a slide, or just starts talking, and within two minutes we’re deep into a conversation about models. Vendors. Which LLM is better for this use case. Whether to go with one orchestration framework or another.

Features. Availability. Pricing tiers. Token limits.

And I sit there. Listening. Waiting.

Then I ask something like: “What does success look like for this?”

Or: “How will you know in six months if this worked?”

The room usually goes a bit quiet. Sometimes people look at each other. Sometimes someone gives a vague answer about “efficiency” or “reducing manual effort.” And then, almost without fail, the tools conversation resumes.

I’ve stopped being surprised by this. But I haven’t stopped being bothered by it. Because the tool conversation feels productive. It has energy. People have opinions. There’s something to debate. Meanwhile the question of what you’re actually trying to achieve - measured, specifically, in a way you could verify, just sits there unanswered.

And then teams wonder why their agentic systems don’t survive contact with production.

This is the playbook I wish more of those meetings started with.

Subscribe now

First question: do you actually need multi-agent?

I ask this because nobody else does. The assumption in most rooms is that “agentic” means multiple agents.

Sometimes that’s right. If decisions in your process genuinely can’t coexist - different data access, different authority, different latency requirements, then splitting makes sense.

However, multi-agent systems are just distributed systems. And distributed systems are hard. When something breaks, you’re chasing a failure across boundaries, through handoffs, through tool calls you can’t always replay. That complexity doesn’t disappear.

Start single agent. Let the constraints of the actual process push you toward multi-agent if they need to.

Most of the time, the process doesn’t need it. The team just wanted to build it.

Where does the AI go, and where does the human stay?

The most common mistake I see: humans get put at the end. Final review. Rubber stamp before anything goes out. It feels like a safety net.

A human reviewing an output they didn’t generate, without the context that produced it, at the end of a chain they can’t fully see - that’s not oversight. That’s decoration.

AI belongs where errors are recoverable. Humans stay where they’re not.

A compliance violation, an irreversible action, something you’d find out about through an audit three weeks later - those stay human until the system has earned the right to handle them.

You don’t decide in a design session that the AI can handle something. You prove it. Slowly. With data.

The human doesn’t leave the loop because the architecture says so. They leave because the evaluation says it’s safe.

Does the whole process need to go agentic?

Almost certainly not. But the pressure to say yes is enormous right now.

The ROI case always gets built for the full process. End-to-end automation, scale infinitely. That’s how it gets approved. And then reality shows up - the data isn’t ready, the decisions aren’t defined clearly enough, and nobody can tell whether any of it is working.

What I’ve seen to work: find the one or two decisions where human time is most expensive or delay is most painful. Start there. Leave the rest human for now.

The process you want to automate probably wasn’t that well-designed to begin with. AI will find every shortcut, every undocumented exception, every “we just know” that your team built into it over the years. Automating the whole thing at once means hitting all of that simultaneously.

Pick one decision. Define it properly. Prove it works. Then move.

The 7-step playbook

This is the Reverse Strategy Framework applied to process agentification.

The order matters.

Each step is a gate - if you can’t pass it, you’re not ready for the next one.

1: Map the decisions, not the steps.

Get the people who actually run the process in a room. Have them document the judgment calls. At every point where a human exercises discretion: what are they looking at, what makes them go one way versus another, what would a wrong call look like, and how quickly would you know?

Ask: if you gave two experienced people the same input, would they make the same call? If they regularly don’t - you don’t have a process you can automate.

You have a process you need to design first. You can’t build an agent to make a decision the organisation hasn’t agreed on.

2: Define what ‘good’ looks like for each decision.

For each decision node you’re considering, map what precision do you need, what’s an acceptable error rate, what’s the cost difference between a false positive and a false negative? Quantify with numbers.

These aren’t metrics you figure out after you build. They’re the thing that tells you whether the system is working at all. Most AI projects fail because nobody defined what capable meant. Do it here, before anything else.

3: Check your data readiness, decision by decision.

Agents make inferences from data. For each decision node you want to automate, check whether the data exist, can an agent access it in real-time, and is it structured in a way the agent can reliably use?

Most enterprise processes run on data designed for humans. PDFs. Exports. Systems that require a login and three clicks. Context that only exists because someone’s been in the role long enough to know where to look.

Check five things per node: how accessible the data is, whether the schema is clean and consistent, whether there’s enough metadata for the agent to interpret what it’s looking at, how errors and edge cases are handled, and whether there’s any observability into what the data’s doing.

If a node’s data isn’t ready, build the data layer first. A good model on broken data is still broken.

4: Assign each decision - AI, Human, or Hybrid.

Using what you’ve defined in Steps 2 and 3: AI handles high-volume, well-defined decisions where errors are recoverable. Humans handle decisions where a wrong call is asymmetric and non-recoverable. Hybrid - AI proposes, human confirms - is for the middle ground, where you think it’s probably automatable but don’t yet have the data to prove it.

Write this down. It becomes the architecture contract. If someone later asks why the agent doesn’t handle a particular decision, the answer is already there.

5: Decide single vs. multi-agent.

You now have the decision map. Look at it. Are there nodes that genuinely require incompatible contexts - different data access, different authority, reasoning chains that need to be isolated from each other? Those are your split points. If not, stay single.

I have seen many teams start with this conversation. It actually belongs here, in Step 5, with real information in front of you.

6: Build the evaluation before you build the agent.

I know this feels backwards. Build the thing first, then measure it - that’s the instinct. Don’t do it. Please.

Before you write a line of agent code, collect 200+ real examples from the process. Actual inputs, paired with what a good human would have decided on each one. Then define how you’ll score whether the agent’s call matches that standard.

This forces a useful confrontation: can you actually define “correct” before the AI has to? Sometimes you can’t. That’s valuable to discover now rather than six months into production.

Evaluation isn’t a final checkbox. It’s the architecture that keeps the whole thing alive.

If you can’t build a golden dataset for a decision node, that node isn’t ready. That’s not a failure. That’s the process working.

Step 7: Shadow mode first. Then cut over.

Run the agent on live inputs in parallel with the humans. Humans keep making the real decisions. You compare outputs - systematically, against your golden dataset and against the human calls on the same inputs.

The edge cases that didn’t show up in your test set will show up here. They always do. Shadow mode is where you find them safely, without consequences, while building the evidence base that earns trust.

Cut over when the error rate threshold is met. Not when the launch date arrives.

The question that tells you if you’re ready

Before any of this starts, ask yourself one thing:

If you ran the human process and the agentic process side by side on the same inputs for 90 days, would you have the data to prove the agent is performing at least as well?

If yes - you’ve defined success, you have evaluation infrastructure, you’re ready.

If no - something foundational is missing. You haven’t defined success clearly enough, the data can’t support measurement, or you don’t have a golden dataset to compare against. That’s Evaluation Debt.

The process you want to turn agentic probably has a version that can work. Whether you get there depends on whether you’re willing to answer the hard questions before the tools conversation starts.

Most meetings I’m in, we never get there.

If you’re in the middle of this - mapping a process, arguing about scope, trying to figure out where the human stays in the loop - hit reply. Tell me where it’s stuck. I find these problems genuinely interesting could share my insights.

If you enjoyed reading this, please share with your friends. Leave a feedback, and tell me what you would like to read more of.

Thanks,
Sandi.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Thanks for reading agentbuild.ai! Subscribe for free to receive new posts and support my work.

Something quietly shifted in the last 12 months.

The senior engineers moving fastest right now - the principal engineers, the architects - are spending 80% of their time writing specs, not code. They’re defining inputs and outputs, mapping component contracts, eliminating ambiguity before an agent ever touches the implementation.

If that makes you uncomfortable, it should. It means the game has changed - and what made you good yesterday may not be what makes you valuable tomorrow.

I sat down with Lena Hall to talk about this. Lena has built distributed systems at Microsoft Research, led developer relations across AWS, and now drives AI infrastructure strategy at Akamai. She’s watched this shift happen in real time.

“Code is becoming like binaries. We don’t manage binaries - they’re generated. Code is heading the same way. The question is: what does that make you?”

- Lena Hall

The Role Is Changing. Here’s What It’s Changing Into.

Developers aren’t becoming obsolete. They’re becoming architects - and the best ones are operating more like CTOs. They own the logic, the system design, the edge cases. They define what needs to be built with enough clarity that an AI agent can execute it reliably.

But here’s where Lena’s technical background adds a layer most people miss: AI agents are non-deterministic by nature. If you don’t control them structurally - with structured outputs, phased execution, and human checkpoints at high-stakes decision points - they will break in ways you can’t predict or explain.

She calls this pragmatic AI: architecture matched to the stakes of the business problem. Low-stakes tasks can tolerate some ambiguity. High-stakes tasks - financial decisions, healthcare workflows, anything with legal exposure cannot. The expert must be in the loop before the system ships, not after.

What You’ll Take Away From This Episode

• Why the Two Generals Problem from distributed systems applies directly to every LLM call you make

• The 3-tier framework for deciding how much AI control your use case actually needs

• Why excluding domain experts from your AI workflow is the #1 mistake teams make

• The one habit that separates developers who ship reliable AI from those who don’t: fix the spec, not the output

WATCH THE FULL EPISODE - AgentBuild Expert Exchange

Whether you’re writing code every day or managing teams that do - this one reframes how you think about where your value actually lives in the AI era.

Thanks, and please leave some comments on the video.
-Sandi.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

His technical work was genuinely brilliant. The kind of thing that makes other engineers quietly jealous.

Then he presented it to leadership.

Forty-five minutes of architecture diagrams. Precision recall curves. Token-level breakdowns of embedding strategies. Every slide was technically correct... and completely forgettable.

The exec sponsor checked her phone twice. The VP asked one question: “So what does this actually mean for our customers?”

He stumbled. Not because he didn’t know - he absolutely did - but because he had never practised framing it as anything other than a technical achievement.

Someone else got the role. Someone less technically impressive, but who could walk into a room and make a CTO feel something about the work.

I’ve seen this pattern dozens of times now. Brilliant people, invisible impact. And it’s not because they lack skill. It’s because nobody ever told them that the story of the work matters as much as the work itself.

That gap is about about to get a lot more expensive.

And you need to pay attention.

This shift is already here

So here’s where it gets interesting.

The Wall Street Journal reported in December 2025 that LinkedIn job posts mentioning “storyteller” doubled in a single year. Not grew a bit. Doubled.

Let that sit for a second.

And it’s not just hiring. Executive mentions of “storytelling” on earnings calls hit 469 in 2025, up from 147 in 2015. That’s not a marketing trend. That’s a boardroom concept now.

So, you may ask why the spike?

You can probably guess.

AI made content cheap. Abundant, even.

Which made trust and human narrative scarce... and therefore valuable.

One communications CEO nailed it: the flood of AI-generated content created so much distrust that the brands winning right now are the ones that sound most human.

Here’s the weird side-effect if you’re in data or AI: your dashboards, models, and agents aren’t the final product anymore.

The story about them is.

How you actually get better at this

You don’t need to become a novelist. You just need to change how you frame what you’re already doing.

• Frame everything as a before and after. Next time you present work, try this: Before - here’s how decisions were made, or what was broken.
  Conflict - here’s the cost of staying like this.
  After - here’s what changes if this works. One slide. Three beats. That’s it. That’s your story. Most people skip the conflict part, by the way - and that’s exactly the bit that makes execs lean forward.

• Translate complexity into choices. Instead of “we used model X with technique Y,” try: “We chose this approach because it sacrifices a bit of accuracy for much better latency, which means customers don’t wait.” See the difference? You’re telling a story of trade-offs now. A VP can repeat that in a corridor. They can’t repeat your architecture diagram.

• Anchor every number to a human. “3% uplift” is forgettable. “That 3% means 8,000 fewer customers hitting this error screen every month” - that sticks. Whenever you’ve got a metric, ask yourself: what does this number feel like for a real person?

Why bother when you could just get much better at technical stuff?

Fair question. Here’s my honest answer.

AI is eating the production side of our work. Fast.

Code, analysis, first drafts - all getting automated.

What it can’t replace is picking the right problem, reading the room, and crafting a narrative that makes someone with budget authority say “we’re doing this.”

That’s the bit you don’t want to outsource.

Here's what I do.
Every project I work on, I write a five-sentence story about it before I present anything: who it helps, what hurts today, what we're changing, how we'll know it worked, what happens next.

No fancy framework. Just five sentences.
It forces me to find the narrative before I open a slide deck.

Then next time you send a Slack update or a deck, check: is there a clear before and after? Is there one sentence someone could repeat to their boss?

If you can answer that... you’re already ahead of most technical people in the room. Because you got clearer.

And clarity, it turns out, is what actually moves organisations.

Thanks for reading. Tell me in comments - what you think about this new skill employers are looking for? How are you preparing for this shift?

Thanks,
Sandi.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

Meanwhile, I just left a meeting last week where a $1B+ company spent 90 minutes arguing about whether “active customer” means someone who bought in the last 30 days or 90 days.

Different teams.

Different definitions.

Different databases.

These are not the same timeline.

The Anthropic Reality

At Anthropic, engineers stopped writing code because their stack was built for AI from day one. Clean data. Modern architecture. No legacy anything.

The Enterprise Reality

At most companies, the Head of Data is still explaining why you can’t just “put everything in a vector database” when nobody agrees on what an active customer is.

This isn’t about AI capability. It’s about infrastructure debt that’s 15 - 30 years deep.

The Real Gap

Most of my time with customers these days are spent on talking about AI Readiness.

You know what blocks them? Not models. Not talent. Not budget.

It’s that nobody can answer basic questions:

• Where is the source of truth for customer data?

• Can we access it in real-time or only batch?

• Do we have lineage? Do we have versioning?

• Can we trace decisions back to their data sources?

AI-native companies designed from scratch for these questions.

Everyone else is retrofitting.

The Opportunity in the Gap

Here’s what’s interesting about this moment.

AI companies built for a world that doesn’t exist yet.

Enterprises are still operating in the world that does.

Someone has to bridge that gap.

And right now, AI companies are realizing they can’t do it alone. Anthropic can’t retrofit your 2009 database. OpenAI can’t untangle your customer data across 12 systems.

This is where the real opportunity is.

Not in building better models.

In building the infrastructure that lets models actually work.

If you know:

• How to design cloud infrastructure

• How to build data platforms

• How industry-specific workflows actually operate

• How to translate technical requirements to business outcomes

You’re not behind. You’re exactly where the market needs you.

But here’s what you need to learn - and learn fast:

The gap between what models can do and what enterprises can actually deploy.

Because that gap is the entire business for the next 5 years.

Most people think they need to learn prompt engineering or RAG architectures.

What they actually need to learn is why a large enterprise can’t answer “what’s this customer’s balance?” without a nightly batch job.

And how to fix that before the AI even shows up.

The window’s still open. But it’s closing fast.

Not because AI is getting harder. Because the people who understand both worlds - AI capability AND enterprise reality - are getting snatched up.

The question isn’t whether you can catch up to Anthropic.

The question is whether you can help enterprises catch up to what AI requires.

That’s the real opportunity.

Next Week

I am releasing a plan for you to prepare for this opportunity.

Make sure you don’t miss that.

Ask your friends to join.
More valuable content coming your way.

Share agentbuild.ai

They had no measurement infrastructure. No test cases. No way to trace decisions. They’d celebrated the launch, moved the team to the next project, and now they are spending most time resolving issues - patching, and fixing.

He’s not alone. I have similar discussions with many companies who shipped thier AI features under pressur - from boards, from investors, from competition.

I keep seeing this pattern

Three times in the last quarter, I’ve worked with organizations dealing with the same crisis:

Scenario 1: This company deployed document processing AI to 10 enterprise customers. Six months in, their largest customer threatened to cancel. The AI was extracting wrong data from contracts. The team had no way to see why.

Scenario 2: A fintech launched an insurance documentation assistant. Their customers complained it was “getting slower” and “less accurate.” Thier team couldn’t verify either claim - they’d never established baselines.

Scenario 3: A retail bank deployed a chatbot handling internal claim disputes. Support tickets about “wrong AI answers” were climbing. Nobody could trace which policy the AI used or why it made specific decisions.

Here’s the common thread I noticed?

All three had deployed without building evaluation infrastructure.
They’d built the AI, but not the system to know if the AI was working.

What Actually Happens in These Meetings

I sit in a conference room with engineering, product, and business leaders. I ask:

“What’s your accuracy?”

“X%”

“What’s it costing per query?”

“Infrastructure costs are $X, but we don’t track per-query.”

“Do you have test cases?”

“We tested it before launch...”

“Can you show me traces of what went wrong?”

Silence.

This is what I call Evaluation Debt.

You deployed a system without building the measurement infrastructure to operate it. And now you’re paying interest - in firefighting, guessing, and eroding stakeholder trust.

The Recovery Framework I Use

Here’s what most advice gets wrong: it assumes you’re starting from scratch. But you’re not. Many AI POCs mde it to production - just that they were not production-ready. They need a recovery framework, not a startup guide.

I’ve developed a four-phase Recovery Pathway that rescues these systems without rebuilding from scratch:

1. Define what success should have been

2. Build measurement infrastructure retroactively

3. Diagnose with data, not guesses

4. Fix and validate systematically

That SaaS company? Itook them from 73% accuracy and customer threats to 96% accuracy and $1.4 million in annual savings.

Not by switching models.

By implementing evaluation infrastructure and working systematically.

Why This Matters Now

According to recent IDC research, enterprises are collectively spending $154 billion on AI initiatives in 2024. But McKinsey data shows that only 11% of organizations have achieved significant financial returns from their AI investments.

The gap between investment and return isn’t a capability problem.

It’s a measurement problem.

You can’t fix what you can’t measure.

And you can’t defend an investment you can’t prove is working.

Watch the Recovery Pathway Framework Video

I just recorded a complete walkthrough of the Recovery Pathway framework. -including a real case study where we rescued a failing AI system.

👉 I will be bringing more practical content like this - please subscribe to my channel if you want to stay updated. I share clips and short formats so you can learn something new everyday.

You’ll see:

• The exact diagnostic process that reveals where failures are happening

• How to implement tracing retroactively without rebuilding

• The week-by-week action plan to go from crisis to recovery

• Real numbers: $4.20 per document down to $1.80, 47 complaints per month down to 3

This isn’t theory. This is the actual process I use when organizations call me to rescue production AI systems.

If you’re dealing with an AI system that shipped but isn’t delivering the value you promised - this framework will show you the way out.

And if you know someone firefighting a struggling AI deployment, share this with them. Recovery is possible. But it requires working backward with discipline.

👉 BONUS: I’ve created a Recovery Pathway checklist with the workshop agenda, tracing implementation guide, and diagnostic framework.

Get in touch if you have questions.

Found this useful? Ask your friends to join.
We have so much planned for the community - can’t wait to share more soon.

Share agentbuild.ai