Platform teams have a familiar conversation ahead of them, this time about a new kind of workload. A product team wants to put an AI agent into production. The demo works. The questions the platform team asks next decide whether the agent becomes a normal workload or a recurring incident.
I build and operate production AI agents at Amazon Advertising, including an audience strategy agent structured as 24 governed playbooks. Sitting on both sides of this conversation, as the person who ships agents and the person whose services they call, I have come to think the platform asks are not exotic. They are the same asks we make of any workload, translated for a system whose behavior is probabilistic and whose appetite for resources can be difficult to predict.
Give It an Identity of Its Own
The first demand is identity. An agent should run as itself, with credentials scoped to the tools and data its job requires. The pattern to reject is the borrowed one: the agent acting through a shared service account, or worse, through the permissions of whoever deployed it. When an agent with a shared identity does something wrong, the audit trail answers “the platform did it,” which ends the investigation before it starts. One identity per workflow sounds strict until the first incident review, when it becomes essential to answering the basic question of what acted.
Treat Its Appetite as a Capacity Question
A conventional service has a request rate you can model. An agent has loops. One user question becomes a plan, the plan fans out into tool calls, and a failed call triggers retries. The load an agent places on internal APIs and data services is bursty in a way that follows its reasoning, not your traffic curve.
Platform teams should ask for budgets before launch, enforced outside the agent: rate limits per workflow, a cap on concurrent runs, and a spend ceiling that trips automatically. The agent will not police itself, because from inside a loop, one more call always looks reasonable. The ceiling has to live in the platform, where the loop cannot argue with it.
Ask How It Stops
Every workload needs an off switch, and agents need a finer one. Shutting down the whole service because one workflow is misbehaving is the kind of blunt move teams avoid until things get bad. Ask instead for a per-workflow stop: the ability to suspend one playbook while the rest keep serving. Then ask the uncomfortable follow-up: Who has tested it? A stop mechanism that has never been exercised is a hypothesis. In our operation, the stop condition for each playbook is agreed upon at launch, while agreeing is still cheap, and the mechanism is part of the service, not a runbook hope.
Logs That Explain, Not Just Record
Standard request logs will tell you the agent ran. They will not tell you enough about how it arrived at its answer. Before an agent ships, ask what its records capture: the question it received, the data sources it accessed, the calls it made, and the answer it returned, tied together so one interaction can be reconstructed end to end. When a user disputes an answer, and they will, that record is the difference between an investigation and an argument.
The Short Version
Identity of its own. Budgets enforced outside it. A tested way to stop one workflow. Logs that can reconstruct a decision. None of these demands mention models, prompts, or frameworks, and that is the point. An agent is a workload. The platform discipline that made every previous workload survivable applies to this one too, and the time to apply it is before the demo becomes a dependency.
Vishnuvardhan Reddy Kaithapuram is a Software Development Engineer at Amazon Advertising, where he builds back-end services, APIs, and production AI agents for advertiser analytics. His writing has appeared in TDWI Upside and ExchangeWire, and he spoke at Marketplace Risk New York on data-layer AI governance.