Why AI agents need the whole system in context

An AI agent is only as capable as the slice of your business it can see. Give it your whole route-to-market system — order capture, stock, loyalty, returnables, delivery, analytics — behind consistent events and typed APIs, and it can draft a task, estimate the blast radius and execute the change. Bolt it over a fragmented vendor stack and it sees one module at a time: it can chat about your business but cannot run a change through it.

What does full system context actually buy you?

The clearest existence proof is agentic coding. A tool like Claude Code works because the agent operates against the whole repository rather than a single file — it reads the code, runs it, inspects the tests and opens a change end to end. The market reception tells you what that end-to-end capability is worth. As of September 2025, Anthropic reported Claude Code was generating over $500 million in run-rate revenue with usage growing more than 10x in three months, while the company's overall run-rate climbed from roughly $1 billion at the start of 2025 to over $5 billion by August. People pay for agents that finish work, not agents that answer questions about it.

A codebase is a coherent system: one build, one test suite, one set of types, one place to see what happened. That coherence is exactly what lets an agent plan and act. Your route-to-market operation rarely has it — it is more often six vendors and an integration layer, each product carrying its own data model and its own private idea of what an order or a customer is.

Why can't your current stack give an agent that context?

Because a fragmented stack hands the agent fragments. The order-capture product knows about orders, the loyalty product knows about points, the delivery product knows about drops, and none of them agrees on an identifier or a schema. An agent wired into one module sees one module. It cannot reconstruct what happened across the chain, because there is no shared ordered history of events; it cannot form payloads safely, because the APIs are not typed; and it cannot tell a safe change from a dangerous one, because nobody wrote the invariants down.

This is Conway's law surfacing in your data model: the seams the agent keeps tripping over are the seams between the vendors and teams that built each piece. We make that argument in full in Conway's law is your integration bill. The practical consequence is that the two capabilities you actually want — estimate and execute — are the two a fragmented stack cannot support. Estimating blast radius needs downstream visibility. Executing safely needs a way to replay and verify. Fragments give you neither, which is why an agent over a vendor patchwork degrades into a chatbot with API access.

How do you make the platform legible to an agent?

You stop treating AI as a feature to bolt on and start treating your platform as something an agent has to read. Concretely, five things.

1. Put every state change on one event bus. Emit consistent, typed, versioned domain events — OrderPlaced, StockReserved, EmptiesReturned, DeliveryConfirmed — as facts on a shared bus. That gives the agent a replayable history it can reconstruct and reason over. We treat that same stream as the system of record, argued in an event stream is an audit trail your auditors will like, and it is the substrate the whole suite runs on.
2. Expose typed APIs, not screens. Every operation an agent might perform needs a schema for its inputs, outputs and error shapes, so the agent calls a contract instead of scraping a UI or guessing at payloads.
3. Write your invariants down. State the rules that must always hold — a returnable deposit is never negative, an order cannot ship stock it never reserved — somewhere both engineers and agents can read them. An agent that knows the invariants can distinguish a safe change from a dangerous one.
4. Give it a real interface through MCP. Expose the platform's events, APIs and documentation through one protocol, so the agent reads every module the same way rather than learning six bespoke integrations.
5. Give it staging with production-shaped data. An agent that plans and estimates needs somewhere to execute and verify before it touches production. That environment is also what turns a change into a controlled rollout rather than a leap — see rollout as a config change: feature flags across OpCos.

The Model Context Protocol, which Anthropic published in November 2024, is what makes the fourth step practical. Anthropic describes it as

a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol.

Replacing fragmented integrations is the whole game. The fragmentation is precisely what starves your agent, and no amount of model capability substitutes for a platform it can actually see.

None of this is free, and it is worth being honest about where the cost lands. The hard part is not adopting a protocol or standing up a staging environment; it is retrofitting consistent, typed events onto systems that were never built to emit them, and getting six vendors' worth of identifiers to agree on what a customer is. That work is slow and unglamorous, and it is most of the bill. What you buy with it is a platform legible to your engineers and your agents at once — the same coherence that makes agentic coding work, applied to route-to-market.

The models will keep improving on their own schedule, and that is not the variable you control. What you control is whether your platform is legible enough for an agent to act on the day a better one ships. Brewers who spend the coming year making their route-to-market operation event-consistent and typed will find that new agent capability arrives as a configuration change rather than a re-platforming — while the fragmented-stack incumbents are still explaining why their chatbot can answer questions but cannot place an order.