What it actually takes to put AI agents into production

› Where pilots stall

The numbered layers are easiest to explain through the problems a pilot runs into on its way to production, roughly in the order they appear. Each paragraph below covers one problem and how to fix it; if you would rather see the solution first, the next section shows the full stack as we deploy it.

Reach. The first agent usually lives in one engineer’s terminal, and six months later it still has one user. Agents create value where work already happens, in Slack, Teams, email, or a job that runs overnight, used by people who never saw the demo. Once people other than the builder use it, the agent has to know who each of them is, and it has to get that from your identity provider rather than from what they type. Otherwise anyone can claim to be the CFO in the chat and receive the CFO’s answers.

Data. The prototype connected to the data warehouse with a single service account, because that was quickest. In production, that shortcut means a manager asks about their team’s spend and gets a colleague’s salary in the answer, because to the database every question comes from the same user. The fix is decades old: the agent queries as the person who asked, and the database applies the permissions it already has. Of the problems on this list, a data leak is the one most likely to become a regulatory matter, and it is far cheaper to prevent before launch than to clean up after.

Cost. Agents retry, loop, and fan out. One that hits an error it cannot parse on a Friday evening can spend the month’s budget before anyone opens a dashboard on Monday, and the invoice arrives as a single number with nobody’s name on it. The fix is a model gateway: one service that sits between every agent and every model provider. It checks each call against the budget of that agent and that user before the call is made, blocks it if the budget is spent, and attributes every dollar to a person and a use case. That same cost data then tells you which agents are worth what they cost.

Model choice. The pilot was wired to one provider’s model, with an API key pasted into its configuration. Once every call goes through the gateway, the model becomes a setting you manage centrally. Routine work can go to a cheaper cloud model or an open model on your own hardware, requests involving sensitive data can stay on a local model inside your network, and only the hardest tasks need the most expensive frontier model. You can try a new model on a share of real traffic and compare cost and quality before switching, without changing the agent. The gateway also keeps the provider keys, so no team or agent ever holds one, and tracks each user’s token usage against their allowance.

Control. Something will go wrong at an inconvenient hour. What matters is whether stopping it takes one click from a console, or an hour of working out which machine it runs on while the engineer who deployed it is on a plane. Agents also take instructions from whatever they read, including a line hidden in a support ticket or a vendor’s PDF. So the agent should hold no keys or passwords, and its limits should be enforced by the systems around it rather than written into its instructions, where the next document it reads could override them.

Accountability. A customer forwards an email your agent sent and asks what it was based on. You need an answer in minutes: who asked, which version of the agent ran, what data it touched, and what it cost. Ordinary logs, written by the same machine that ran the agent, are fine for debugging. A customer or an auditor needs a record stored outside the agent’s reach that cannot be altered after the fact.

Change. The agent got worse this week. Someone edited the prompt, swapped a tool, or the provider updated the model underneath it, and nobody can say which, because none of it was versioned together. Treat the prompt, tools, model, and engine as one release, pin every deployment to a version, and a bad change becomes a one-command rollback instead of a week of guesswork. Because mistakes are cheap to undo, teams can release improvements more often.

None of this is new. Companies already run people and software this way: a login tied to a name, a spending limit, a manager who can say stop, a paper trail, a change process. What is new is that for agents these controls cannot live only in a policy document. A policy can say nobody may wire $50,000, but it is the payments system that actually blocks the transfer. Agents need that kind of enforcement built into the systems they use, because an agent will not reliably follow written rules. That is what we mean by runtime governance: controls enforced by software on every action an agent takes.

› Where to spend, and where not to

Most of this stack should not be built by you. Model providers, identity, search, Kubernetes, observability backends: buy or adopt them, and resist building a custom version of anything on that list. The same goes for guardrails that screen prompts and outputs. They are worth having because they reduce how often the model makes mistakes, but they cannot limit the damage when it makes one anyway. That is the job of the layers above.

A few things are worth standardizing across the company early, before every team picks its own: one model gateway, one way for agents to reach tools, one format for the record of what they did. Standardize those, and a new agent plugs into what exists instead of rebuilding it.

Where your engineers’ time does pay off is in what no vendor can give you: the agents themselves, the integrations into your own systems, and the test cases that describe what good work looks like in your business. That last one is the most underrated asset in AI right now. Models will keep changing underneath you. With a good set of test cases, you can check in a week whether a new model does your work better and switch with confidence; without them, every model change is a judgment call.

› Where we fit

A disclosure, since you are reading this on our website: this stack is what we build. AgentHippo is the numbered layers, packaged so a team can stand them up in its own environment with any model and any agent framework, on its own provider keys or our credits. Every layer deploys from a plain script your engineers can read in full before it runs, and every deploy checks itself before it reports success. That said, you do not need AgentHippo to apply anything in this post: the same design can be built from other components.

› Where to start

You do not need all eight layers on day one. Four carry most of the risk, and they fit in one sentence: the agent acts for a verified person, within a budget, under an off switch, and on the record. Add per-user data access the day it touches a system of record, and release discipline the day a second person edits the prompt.

Then pick one workflow where a mistake would be visible and reversible, and where you can measure the outcome in money or hours. Run it behind those four controls for a month. Widen the agent’s authority only as fast as the evidence supports, and let what you learn decide what the second agent should be. By the third agent, the leadership discussion usually shifts from whether agents work to which workflow to automate next.