What is an AI Agent operating model?
Short definition: an AI Agent operating model is a written set of rules stating what each AI Agent does, which tools and data it may use, when it must stop or hand over to a person, and who is accountable for the outcome. Think of it as a job description plus a delegation-of-authority policy, written for a software system.
When businesses deploy AI Agents, the biggest risk is usually not the language model's capability but the operating framework around it: vague authority boundaries, missing approval steps and no process for exceptions. If you are unsure how an AI Agent differs from a chatbot or RPA, start with what is an AI Agent.
| Component | Question to answer | Output |
|---|---|---|
| Role | What does this agent do, for whom, within what scope? | One-sentence role description, list of allowed and forbidden tasks |
| Permissions | What may the agent read, write or send? Which actions need approval? | Permission matrix by tool and data |
| Handover | When does work go to a person, with what information, to whom? | Trigger conditions, context-pack template, on-call owner |
| Failure handling | What happens with missing data, conflicting instructions, ambiguous requests? | Predefined behaviour: ask, stop, escalate |
| Accountability | Who owns the process, approves changes, reviews logs? | RACI table and review schedule |
Step 1: define the role before choosing tools
Each agent should have a job title a human would recognise: intake coordinator, records reviewer, reporting assistant. The title implies the scope of work and its natural boundaries. If the role cannot be described in one sentence, the scope is too broad for a first release.
Also write down what the agent must not do. That list often matters more than the list of tasks, because it drives permission configuration and testing.
- Illustrative example: "The intake agent reads emails arriving in the support inbox, classifies them by topic and drafts replies; it does not send emails, change customer records or promise resolution times."
- Every role has a business owner, not just the engineer who built it.
- Start with one agent for one narrow process; split into multiple agents only once the first role is stable.
Step 2: least privilege and approval steps
The principle of least privilege applies to agents just as it does to a new employee: start with read access and open write access only for actions that have been tested. OWASP lists Excessive Agency—giving an agent more power than it needs—in the OWASP Top 10 for LLM Applications (2025 edition, LLM06), with three root causes: excessive functionality, excessive permissions and excessive autonomy.
OWASP recommends limiting the tools an agent can call to the minimum, avoiding open-ended tools such as arbitrary command execution, enforcing authorisation in downstream systems rather than letting the model decide whether an action is allowed, and requiring human approval for high-impact actions. Technical detail is in our guide to access control and audit logs for AI Agents.
| Level | Type of action | Mode |
|---|---|---|
| Low | Read permitted internal documents, summarise, classify | Agent acts alone, everything logged |
| Medium | Draft emails, update non-critical fields | Agent acts, a person reviews samples regularly |
| High | Send information externally, change customer data, payments | Human approval required every time |
| Forbidden | Delete data, change permissions, make decisions about people | Tool not granted to the agent |
Step 3: a RACI table for roles, permissions and handovers
RACI records who is Responsible (does the work), who is Accountable (owns the outcome), who is Consulted and who is Informed. For AI Agents the key rule is simple: an agent can be R but never A. Final accountability always sits with a named person.
| Activity | AI Agent | Operations staff | Process owner | Engineering / IT |
|---|---|---|---|---|
| Classify requests and draft replies | R | C | A | I |
| Approve and send replies to customers | C (prepares context pack) | R | A | I |
| Hand over difficult cases to a person | R (triggers, attaches context) | R (receives) | A | I |
| Grant or change agent tool permissions | — | I | A | R |
| Review logs and quality periodically | — | C | A | R |
| Handle incidents, pause the agent | — | R (presses stop) | A | R (fixes) |
| Update the operating model | — | C | A | C |
Handovers with context
A handover works only if the receiver does not have to research the case from scratch. Each escalation should carry a standard context pack:
- Why it was escalated (which condition triggered).
- The original request and the steps the agent took, with the data sources used.
- The agent's proposal, if any, and its confidence.
- The receiver, expected response time and a fallback channel.
Step 4: design failure handling up front
Agents fail in predictable ways: missing data, conflicting instructions, ambiguous requests, tool errors or input content containing unexpected instructions. Each case needs a defined behaviour: ask, stop or escalate. The worst design is an agent that carries on confidently when it should have stopped.
OWASP also notes that logging, monitoring and rate limiting do not prevent an agent from doing the wrong thing, but they help detect problems early and limit damage. You need both layers: preventive boundaries (permissions, approvals) and detection (logs, alerts, a stop button).
- Set limits on steps, tool calls and cost per task.
- Treat content from emails, documents and web pages as data, not commands.
- Test the stop button and rollback mechanism regularly.
Vietnam's AI Law 2025: humans keep the decision
Vietnam's Law on Artificial Intelligence No. 134/2025/QH15 took effect on 1 March 2026. Article 4(2) states that AI serves people and does not replace human authority or responsibility; human control and the ability to intervene must be maintained over all decisions and behaviour of an AI system, together with the ability to inspect and supervise its development and operation.
The operating model is where this principle becomes real: the RACI table names who is accountable, the permission matrix defines where people approve, and the stop button provides the ability to intervene. Article 7(4) also prohibits obstructing, disabling or falsifying human oversight, intervention and control mechanisms.
For high-risk AI systems the duties are more specific: providers must design systems that allow human oversight and intervention and keep technical files and activity logs (Article 14(1)(c), (d)); deployers must ensure human intervention during use (Article 14(2)(b)). Decision 33/2026/QD-TTg on the List of high-risk AI systems also states that using AI does not change, transfer or remove the authority and responsibility of competent agencies, organisations and individuals.
For a full overview of obligations, see Vietnam's AI Law 2025: what businesses using AI should prepare; for approval-point design, see human-in-the-loop.
Step 5: write it down, then build
The operating model is a short document, typically one or two pages per agent, reviewed by the people who own the process. It is updated when the business workflow changes, not only when the software changes. Teams that write it first spend less effort correcting behaviour later and already have documentation when they need to explain their system.
EYC is building toward an operating model in which AI Agents handle most repeatable work under human direction, following the principle "Human-led systems. AI-coordinated work." Through our AI automation and integration consulting services, we can work with your team to write the operating model, configure permissions and design handovers; scope is set under contract.
- Minimum template: one-sentence role, allowed and forbidden tasks, permission matrix, handover conditions, failure behaviour, RACI table, review schedule.
- Tie each version of the operating model to the version of the agent configuration in production.
Frequently asked questions
Where should a business start when deploying AI Agents?
Start with one narrow, high-volume process with a clear owner. Write the operating model for a single agent (role, permissions, handover, failure behaviour, RACI), run it in read-only or draft mode, then widen permissions gradually as testing confirms behaviour.
Can an AI Agent make decisions on its own?
An agent can handle permitted low-impact actions on its own, but under Article 4(2) of Vietnam's Law 134/2025/QH15, AI does not replace human authority and responsibility, and human control and intervention must be maintained. High-impact actions should always have a human approver.
How is a RACI for AI Agents different from a normal RACI?
The structure is the same, with one rule added: an agent can be Responsible but never Accountable. Every agent activity must map to a named person who owns the outcome.
How do you grant permissions to an AI Agent safely?
Apply least privilege: grant only the tools and permissions the role actually needs. Enforce authorization in the downstream systems rather than relying on the model to decide. Require human approval for high-impact actions, as OWASP recommends for the Excessive Agency risk.
When should an AI Agent hand work over to a person?
When data is missing, instructions conflict, a request is ambiguous, an action exceeds its permission threshold, or the agent is uncertain. Each handover should include the reason, steps taken, data sources and the receiver.