Every AI programme eventually lands on the technology owner's desk with the same questions. Where does this run? What can it touch? Who is on call when it misbehaves at 2am? And what happens when the model we picked is replaced next quarter?
Agents are different from earlier software in one way that matters: they act on your systems with judgement. That makes identity, context and monitoring the real architecture work. The platform choice matters less than most vendor pitches suggest.
The problem, and who has it
Business teams buy assistants and agent tools faster than IT can assess them. Each one wants its own connectors, its own copy of the data and its own idea of who the user is. Without a pattern, you end up with a dozen agents, a dozen access models and nobody who can say what any of them did yesterday.
The steps
1. Start from the workflow, not the platform. Write down what the agent reads, what it decides, what it writes and who approves. That list tells you the systems, data and permissions involved, and it is the same list risk and audit will ask for.
2. Decide where agents run, by type. Most enterprises need three homes: the enterprise tier of an assistant your people already use, for drafting and search; a cloud agent platform in your own tenancy, for governed workflows; and your existing automation or integration layer, for deterministic steps. Choose by data residency, identity integration, model choice and cost per task, then publish the rule so teams stop debating it.
3. Build the context layer once. Agents are only as good as what they can see. Put retrieval over approved sources behind one service that inherits each user's existing permissions, and expose systems of record through APIs rather than copies. Every new agent reuses it.
4. Give every agent its own identity. Each agent gets a named service identity in your identity provider, with least-privilege scopes, short-lived tokens and secrets in your vault. Never let an agent borrow a person's credentials. Route approvals through tools people already use, such as email, chat or the system of record.
5. Evaluate before go-live, and keep evaluating. Keep a test set of real cases with expected outcomes for each agent. Run it before launch, on every prompt or model change, and on a schedule. Monitor cost per task, latency, error and escalation rates the way you monitor any production service.
6. Plan for the model to change. Models improve and get retired every few months. Version prompts and configurations, keep model calls behind an abstraction, and make switching a tested change, not a rebuild.
7. Write the run book before launch. Name the owner, the on-call route, the incident steps and the off switch. Decide what happens to work in flight when an agent is paused. Test the off switch and time it.
Who signs off
The CIO or CTO signs the reference architecture and the rule for where agents run. The CISO signs the identity and access model and the data residency position. The lead architect owns the context layer and the evaluation standard. The business owner of each workflow signs the go-live, as with any production change.
What good looks like
- A one-page reference architecture that every new agent follows.
- Every agent has its own identity, scoped access and an owner.
- One context layer, reused, with permissions inherited from source systems.
- Evaluation results on file for every agent and every change.
- A tested off switch and a run book per agent.
- Switching a model is a change ticket, not a project.
Questions to ask any vendor or partner
- Does it run in our tenancy and region, under our identity provider?
- Can each agent have its own identity and scoped permissions?
- Are prompts, configurations and evaluation sets ours, in our accounts?
- How do we export the full action log?
- What changes, and who is told, when the underlying model changes?
- What does one task cost to run, and how is that monitored?
Put this playbook to work
Book a call and we will apply it to your organisation with your teams.
