An agent can make decisions inside a task. Your organization decides what work it may perform, what access it receives and whether its results are acceptable. Those responsibilities need named owners.
The framework below is a suggested division of responsibilities. Small teams may combine roles, but each decision still needs an accountable person.
Separate the five decisions
| Decision | Accountable role | Record to keep |
|---|---|---|
| What counts as success? | Process owner | Task agreement and acceptance criteria. |
| What actions may run independently? | Process owner, with relevant control owners | Action list and approval conditions. |
| What access may be used? | Access and data owners | Scopes, credentials and data handling. |
| Does the implementation meet the criteria? | Evaluation owner | Versioned cases and results. |
| Who responds when it fails? | Service owner | Runbook, escalation and stop procedure. |
“IT owns the agent” does not answer all five. A developer can implement a refund limit, but the business must define it and who may authorize exceptions.
Users need a task-level agreement
A user should know what the agent may do in the current task and what requires a decision. A support task might allow retrieval and preparation while reserving sending for the case owner.
Make permissions visible before execution. Approval should show the exact action, affected record and proposed content. Asking someone to approve an unspecified plan gives them little basis for a decision.
Provide an activity record and correction route. Users should be able to report unsuitable output without diagnosing the model or integration.
Process owners define consequences
Reading a case, saving a draft, sending a reply and issuing a refund can have different conditions. An approval for one operation should not silently authorize another.
State which exceptions return to a person. An unverified identity differs from a carrier outage. The first may need confirmation; the second may need a retry or delayed response.
Review the agreement after incidents and scope changes. Access accepted for a supervised pilot may be unsuitable for unattended work.
Builders implement the decisions
Builders map policy to application behavior: argument validation, access checks, action limits and useful failures. Model instructions help express intent. They do not replace authorization in the system performing an action.
Document controls supplied by the framework, hosting and business application. An SDK approval callback and a backend permission check operate at different places. Claude Agent SDK permissions.
Give reviewers evidence of the controls: a denied action in a test, a recorded approval and a matching destination record. A configuration screenshot alone may not prove the execution path works.
Service teams own the running system
Assign monitoring, failed jobs, credentials, cost and recovery to named people. Record who can pause work or revoke write access. Test the procedure with a controlled task.
The evaluation owner records the assessed version. The service owner confirms that version is running. Both need to know when prompts, tools, models or sources change.
Work through a disagreement
Suppose support wants automatic replies, security permits retrieval only, and developers have implemented sending. The tool’s existence does not settle the decision.
Record the proposed action, consequences and required approval. Keep sending unavailable until the appropriate owners agree and application controls enforce their decision. Assess wrong recipients, duplicate sends and changed case details before introducing the action.
Responsibility checklist
- Name the owner of the business outcome.
- Name people who approve access and action changes.
- Assign evaluation and service responsibilities.
- Give users a correction and escalation route.
- Record who stops processing and who authorizes resuming.
Technical integrations need explicit security decisions too. MCP security guidance.
Testing whether an agent completes the task ↗
Measure results, permissions, recovery and cost with repeatable normal and difficult cases.
Prepared with AI assistance and checked against the linked documentation. Examples and numerical limits are illustrative unless stated otherwise. These guides do not report independent product testing. Check current documentation before choosing a tool.