Enterprise agents
Agent patterns that a risk committee can approve
This page is about control, not category. For what agents are, how they differ from chatbots and automations, and what they cost, use the category reference at aiagent.co.zw. Here: the five patterns that let an agent act inside a regulated institution without creating an unreportable decision or an unapproved write.
An agent is a model given tools and a goal. The governance question is therefore not "how clever is the model" but "what can the tools do, on whose authority, and who can see the record afterwards". Everything below follows from that.
Five patterns
- 01
Permission tiers: read, propose, write
Every tool is classified once. Read tools return data. Propose tools create a draft, a case note or a pending transaction that a person completes. Write tools change a system of record and exist only for action types the risk committee has approved, each with limits (amount, count, customer segment). Most enterprise value sits in read and propose; write is rare and slow by design.
- 02
Approval gates in the gateway, not the prompt
Instructing a model to "always ask before sending" is a preference, not a control. The tool gateway holds the rule: write actions are queued for a named approver who sees the proposed action and the evidence the agent gathered, and approves under their own identity. If the approver is unavailable the action waits; it does not fall through to the agent.
- 03
Three identities
The requester, the agent and the executing service are distinct principals. The agent's identity has the allow-list; the requester's entitlements govern what the agent may retrieve on their behalf; the approver's identity is what the target system records when a write happens. Merging any two hides accountability.
- 04
Bounded runs
Every run has a maximum number of steps, a token and money budget, a time limit and a set of systems it may touch. Budgets are per requester and per agent, enforced at the AI gateway and tool gateway, and reported monthly in the model risk pack. This is both a cost control and the mitigation for unbounded-consumption attacks.
- 05
Replayable audit
For each run: requester, agent version, model and version, every tool call with arguments and result hashes, every approval with approver identity and timestamp, and the final outcome. Retained for as long as the outcome can be disputed. This is what answers a s.14 access request, a customer complaint, an internal audit query and the 21-day breach report.
Where agents earn their place first
| Sector | First agent | Tier | Why it is approvable |
|---|---|---|---|
| Banking | KYC refresh assistant that assembles evidence from existing records and drafts the review for an analyst | Read + propose | No customer-facing decision; the analyst decides; full retrieval log; fits the AML/CFT guideline's evidence expectations |
| Insurance | Claims triage that classifies and routes claims and drafts the request-for-information letter | Read + propose | Rejection remains human (s.25); reduces the claims-delay complaints IPEC reports; auditable routing rules |
| Telecoms | Network-incident summariser that reads alarms and tickets and proposes a customer notice | Read + propose | Operational data, little personal data; human sends the notice |
| Mining | Shift-report assistant that reads historian data and camera events and drafts the shift handover | Read only | No write path to plant systems; supervisors sign the handover |
| Public sector | Correspondence triage that classifies inbound queries and drafts responses for an officer | Read + propose | Officer remains the decision-maker; supports the National AI Strategy's service-delivery aims without a statute |
For architecture see the agent platform diagram; for the threat model see security. For definitions, agent types, agent versus chatbot versus workflow automation, and cost ranges, the network's category reference is aiagent.co.zw.