The Bloodstream: Your Model Is a Commodity, Your Tools Are the Risk

At 3:40 am, the model provider running Dana's offboarding starts rate-limiting. A backup picks up mid-task and the job finishes. Nobody wakes up. None of that machinery shows up in a demo, which is exactly why teams forget to build it.

If you are just picking this up, here is the whole premise in a paragraph. An agentic system is not a model with some tools bolted on. It is eleven layers, grouped into seven organ systems, and the model is one of them, arguably the least interesting one. To keep it concrete, the series walks a single ordinary event through all eleven: a senior engineer, Dana Okafor, gives two weeks' notice. Offboarding one person happens to touch every layer, which is what makes it a good way to see the whole body at once. Part 0 drew the map, and the posts since have gone organ by organ.

In Part 1 the request got in the door and the agent got a name. In Part 2 the brain stem decided what to do and held the plan together. Now the plan has to actually reach the outside world. It has to call a model, and it has to touch six real systems that were built long before anyone said the word "agent." That is the bloodstream. Two layers live here, the Model Gateway and the Tool and Integration Surface, and between them they carry everything that moves: the tokens going out to a provider, and the actions coming back into your systems.

This is the layer that sleeps through your entire demo. The happy path never rate-limits, never leaks a Social Security number, and never meets a system without an API. Dana's offboarding meets all three. That is the point of running a scenario that lasts three days instead of forty-seven seconds. In the bloodstream, the model is the easy part. The plumbing around it is the actual work.

The gateway is where the model stops mattering

For most of Dana's offboarding, the model is a commodity. The routine work, classify a resignation, list what someone owns, draft a knowledge-transfer summary, runs fine on a cheap fast model. Swap the provider underneath it and no one could tell from the output.

What lets you treat it that way is the layer in front of it. The Model Gateway is a single chokepoint that every model call passes through, and it does five jobs at once.

Multi-model routing. Not every request deserves the same model. The routine work goes to the cheap fast one. The one decision that actually carries risk, computing Dana's forfeited equity four months short of her vesting cliff, goes to a frontier model, because the cost of a wrong number there dwarfs the cost of the tokens. Routing is the seam where that choice lives. Get it right and you spend frontier money only where frontier judgment earns it. Most of why an agent run costs what it costs is decided here, not in the prompt.

Fallback chains. This is the 3:40 am beat, and it is the reason this layer exists. Day two, middle of the night, Dana's primary model provider starts rate-limiting the agent. Without a gateway, the run dies there, and someone finds a half-finished offboarding in the morning: Dana's access partly revoked, no record of where it stopped. With a fallback chain, the gateway catches the failure, swaps to a backup provider, and resumes from a checkpoint written two minutes earlier. The offboarding finishes on time and nobody gets paged.

The fallback chain does nothing on every good day. Then one night a provider goes down, and it is the only reason you still have a working process in the morning. You do not build this for the demo. You build it for 3:40 am.

PII redaction. Look at what is in Dana's payload. Her salary, her Social Security number, her home address, her equity position. All of it is headed to a third-party model provider unless something strips it first. That something is the gateway. It redacts the sensitive fields before the tokens leave your trust boundary and restores them in the response on the way back. Skip it and you are quietly sending employee financial data to a vendor on every run, and you will find out the day your security team does. Put redaction at the gateway from day one, not after the first audit.

Semantic cache and cost governance. The last two are quieter but they compound. A semantic cache recognizes when the agent is asking a question it already answered and returns the stored result instead of paying for the tokens twice. Cost governance is the meter and the budget: what did this run cost, which model spent it, and where is the ceiling. I have written a whole piece on why a hard spend cap is the wrong instrument and a funded, measured budget is the right one, in Tokenomics in Practice. The gateway is where that measurement physically happens, because it is the one place every token is already passing through.

All five have one thing in common. None is a model capability. A smarter model does not route itself, fail over to a competitor, redact its own inputs, or track its own spend. The gateway is infrastructure you build once and every agent inherits. Skip it and each agent is wired straight to a single provider, with sensitive data flowing in the clear and the cost invisible until the invoice lands. That passes in a demo and turns into a governance problem in production.

The tools are where the risk actually lives

Cross the gateway and you reach the other half of the bloodstream. The Model Gateway carries what the agent says. The Tool and Integration Surface carries what the agent does. Talking is cheap and reversible. Doing is neither.

The difference is blast radius. When the agent reads Dana's record from Workday, the worst case is that it read something. When it revokes her production database access, the worst case is that a system changed and a person cannot do their job. Reading is a weekend project. Acting on real systems, correctly, is what separates a demo from a platform. The tool surface is how the agent reaches into your infrastructure, and it reaches in several different ways.

MCP servers and clients. The Model Context Protocol is how the agent gets a clean, declared set of tools instead of a pile of bespoke glue. Your agent is an MCP client. Your systems expose MCP servers. The tools are described in a way the model can reason about, with names, inputs, and permissions. This is the well-lit part of the surface. The trap is that once it works, teams expose every tool they own to every agent, and the surface bloats until the model cannot see the few tools that matter. I have written about paying that down in Progressive Disclosure for MCP Servers. Keep this half clean and it stays calm. Most teams do not, and it does not.

The API hub and A2A outbound. The API hub is the agent's connection to systems that already speak a modern language: the CRM, the ticketing system, the identity provider. A2A outbound is the mirror image of the inbound door from Part 1. Your offboarding agent calls your payroll agent to hand off the final numbers. Your agent is now a caller of other agents, and it has to prove who it is when it knocks, the same way a machine caller had to prove itself at your front door.

The code sandbox. When the agent computes Dana's forfeited equity, it should not do the arithmetic in the model's head. It should write actual code and run it in an isolated sandbox, where a wrong answer is a caught exception and not a confidently wrong number in a paycheck. The sandbox is also the blast wall: code the agent generates runs somewhere it cannot touch anything it was not handed. Reach for math you can verify, not a number the model asserts.

The last kind is the one worth dwelling on.

Computer Use. Dana's equity lives in a vendor application from 2003. It has no API. There is no MCP server, no webhook, no integration of any kind. The only way in is the way a human goes in: open a browser, log in, click through the screens, read the vesting schedule off the page. So that is what the agent does. It drives the browser like a person.

It is tempting to read this as a sign of how capable the model has gotten. It is closer to the opposite. The agent is reduced to pointing and clicking because someone bought a system twenty years ago with no way to talk to it programmatically, and nobody ever paid the debt down. The agent did not create that problem. It was the first thing in two decades that had to integrate with the equity app and found no clean way in.

Every place your agent has to drive a browser is a place your integration strategy failed years before the agent showed up. Computer Use is the tell. It marks exactly where your enterprise never finished the plumbing.

This is why the risk concentrates in the tool surface rather than the model. The model is contained: it produces text, and the gateway governs the text. The tools are uncontained by design, because their job is to reach out and change things in systems you do not fully control. A hallucinated sentence is embarrassing. A hallucinated tool call that revokes the wrong person's access, or drives the wrong number into payroll, is an incident. Governing the model protects your reputation. Governing the tools protects your operations.

Why the demo never shows you this layer

There is a pattern here that runs through the whole series, and the bloodstream shows it most clearly. Every component in this layer is dead weight on the happy path.

The fallback chain does nothing until a provider fails. PII redaction does nothing until a payload happens to carry an SSN. Multi-model routing looks like pointless complexity until the invoice for running everything on a frontier model arrives. Computer Use never comes up until you meet the one system without an API. A demo, by construction, runs the happy path. So a demo shows you a model and a couple of clean tool calls and none of this, and it looks like you are almost done.

That is the trap. You have built the part that works when nothing goes wrong, and skipped the part that exists for when something does. The bloodstream is plumbing, and plumbing is invisible right up until it is the only thing anyone cares about.

Three questions for your own bloodstream

You are running an agent program, or funding one. Three questions tell you whether its bloodstream holds.

When your primary model provider has an outage tonight, what happens to a job that is halfway done? If the answer is "it dies and someone cleans it up in the morning," you have no fallback chain and no checkpoints, and you will learn this on the worst possible night. The gateway should catch the failure and the job should finish. If it cannot, you do not have a production system. You have a demo that has not met its first outage.

What sensitive data is leaving your trust boundary in the clear? Trace one real request and look at what is actually in the tokens. If Dana's salary and SSN are in there and nothing is redacting them, you are one payload away from a disclosure. The gateway is where you fix this, and it has to be there before the data flows, not after the audit.

Where does your agent have to drive a browser? Every one of those places is an old system with no API, and it is telling you exactly where your integration debt is. That is not a reason to avoid the work. It is a map. But if you do not know where those places are, you do not know where your agent is one UI change away from silently breaking.

Most teams can answer none of the three cleanly. Again, that is not a failure of skill. It is the failure of a diagram that drew an arrow from the model to a box labeled "tools" and hid an outage, a breach, and twenty years of integration debt inside it.

What the bloodstream decides

The front door gave the agent a name. The brain stem gave it a shape and a plan. The bloodstream is what carries that plan into contact with reality: the model calls that have to survive a bad night, and the tool calls that have to change real systems without breaking them. Everything the agent actually accomplishes in the world flows through this layer, and every risk it poses to your operations enters here too.

The model will keep getting better at deciding what to do about Dana. It will not fail over to a backup provider on its own, it will not redact its own inputs, and it will not build the browser automation that limps into a 2003 app that should have had an API a decade ago. That is the bloodstream's job, and it is yours to build.

Next: The Memory. The knowledge graph finally earns itself, because "what does Dana own?" is a question about relationships, and no amount of vector search can answer it.

Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss the gateway and tool layers underneath your agent program.

References

1. Anthropic. "Building Effective Agents." December 2024.
2. Anthropic. "Introducing the Model Context Protocol." November 2024.
3. Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." June 25, 2025.
4. Matthew Kruczek. "Tokenomics in Practice: The Exact System I'd Build to Govern AI Spend." matthewkruczek.ai, 2026.
5. Matthew Kruczek. "The Token Tax Nobody Priced In." matthewkruczek.ai, 2026.