Deploy AI Agents to Production

Why prototypes stall

The demo proved the agent can do the task. Production asks a different set of questions, and nobody on the team owns the answers.

Where does it run. Who can deploy it. What happens when it fails at three in the morning. How do we know what it did last Tuesday. What does it cost per run. Who approves a change. How do we roll back. What does security need to see before this touches customer data.

None of those are about the model. They are all operational, and they are the reason the gap between a working agent and a deployed agent is measured in months.

What production actually requires

1. 1. Somewhere to run. Your laptop is not it, and neither is a notebook. The agent needs an environment that stays up, scales with load, and handles processes that run longer than a request timeout.
2. 2. Separate environments. Development, staging and production, with separate credentials and separate data. Testing an agent against production data because it was faster is how incidents start.
3. 3. Versioning. You need to know which version is live, be able to promote deliberately, and roll back without a deploy cycle. Agent behaviour changes with a prompt edit, which means small changes have large effects and rollback matters more than it does in ordinary software.
4. 4. Secret management. Model keys, API tokens and database credentials out of the source code and out of environment files on someone’s machine. Scoped so a staging agent cannot reach production systems.
5. 5. Observability. Every execution recorded: inputs, tool calls, token spend, duration, outcome. When an agent gives a bad answer to a customer, you need to be able to reconstruct what happened. Sampling is not enough for anything that matters. What to instrument.
6. 6. Cost control. Agents cost money per execution and the cost is not obvious in advance. A retry loop that looks harmless in testing can produce a five-figure bill over a weekend. Limits and alerts before launch, not after the invoice.
7. 7. Human approval where it counts. Some actions should not happen without a person. Sending an external email, moving money, changing a record in a system of record. The runtime needs to support pausing for approval, not just running to completion.
8. 8. Access control. Who can deploy, who can change configuration, who can read execution data. Your security team will ask, and “everyone with the repo” is not an acceptable answer.

Where the security review goes wrong

For most teams, the real blocker is not engineering. It is the vendor security review.

The pattern repeats: the team picks a hosted agent platform, builds on it for two months, then gets to security. Security asks where customer data goes. The answer is that it goes to a third-party vendor, gets processed alongside other tenants, and passes through that vendor’s model account. For a bank under DORA, a hospital, or a public sector body, that conversation ends there.

The way around it is architectural, not contractual. If agents execute inside infrastructure the customer already owns and already had approved, and model calls use keys the customer already holds, most of the review is answered before it starts. How we handle it.

A sequence that works

1. 1. Pick one agent with a measurable outcome. Not a platform strategy. One task where you can say what good looks like in a number.
2. 2. Decide where it runs before you build. Involve security in week one, not month three. This single change removes most of the delay.
3. 3. Ship to staging with real integrations. Mocked integrations hide the failures that matter.
4. 4. Instrument before launch. Logging, cost alerts and failure alerts on day one. Retrofitting observability after an incident is expensive and late.
5. 5. Launch narrow. One team, one workflow, a human approving anything irreversible.
6. 6. Widen once the numbers hold. Remove the approval step when the data says you can, not when the roadmap says you should.

Common questions

How long should this take?

With the operational layer already in place, days. Without it, teams routinely spend a quarter or more building deployment, versioning, secrets and observability before the agent goes anywhere.

Can we deploy agents in our own cloud?

Yes, and for regulated work it is usually the only version that passes review. What you want is a managed control plane with execution in your own account.

What breaks most often in production?

Not the model. Integrations that change, rate limits, long-running executions that die halfway, and cost from retry loops.

Stackbone

Stackbone handles the operational layer so your team works on the agent. Deployment, environments, versioning, secrets, observability and access control, with execution inside your own cloud account and your own model keys.