Article
A prototype agent and an enterprise agent can do the exact same task and still be different systems, because most of what "enterprise" adds is not visible in a demo. It shows up in the review before launch, and it is where prototypes that work perfectly in a sandbox stall for months. None of it is exotic; all of it is easy to skip until someone asks for it.
Identity, not API keys
A prototype agent authenticates with one shared key. An enterprise agent authenticates as the user who invoked it, through SSO, so every action it takes carries the permissions of a real identity and every log entry answers "on whose behalf." This single change is what makes tool permissions enforceable rather than aspirational — the agent literally cannot see what the requesting user cannot see, because the database enforces it at the identity level, not the prompt level.
Audit trails a compliance team can read
"We log everything" is not an audit trail if the logs live in an APM tool nobody in compliance has access to. Enterprise deployments need a record, exportable and retained on a schedule, of every action an agent took, the data it used, and who approved it if approval was required. This is the same observability discipline every serious agent needs, aimed at a different audience with a different retention requirement.
Data residency and model choice are linked
Which model can process which data is a legal question before it is a technical one. An enterprise agent's architecture has to separate the model call cleanly enough that swapping to a region-hosted or self-hosted model, for a subset of data that cannot leave a jurisdiction, is a configuration change, not a rewrite. Teams that hard-code one provider's SDK throughout the codebase find this out during procurement, not during design.
Governance is a role, not a hope
Enterprise rollouts need someone who can answer "what is every agent in this organization allowed to do" without reading source code. That means a central registry of agents, their tools, their permission tiers, and their owners — the same tool registry we describe in platform architecture, surfaced as a page a governance team can actually review, not just a config file engineering reads.
Change management, because agents change behavior without a deploy
A model provider updates their model and an agent's behavior shifts, with no code change and no pull request. Enterprises need the evaluation set to run automatically whenever the model version changes, not just when someone remembers to check, and a rollback path to the previous model version when the new one regresses. This is the difference between an incident that trips a test on Tuesday morning and one a customer reports on Friday.
Procurement asks questions the demo never faced
Where is data processed and retained. What happens on a security incident. Can this run in our VPC. Is there a human always in the loop for irreversible actions. None of these are hard to answer if the architecture was built with them in mind from the start; all of them are expensive to retrofit into an agent that was designed to just work in a demo. Our AI Agents engagements for larger organizations scope these answers before the first line of the agent's logic, because the review is not a formality to survive, it is the actual spec.