Quick answer
An AI agent development scope should specify the job to be completed, the tools the agent may use, the actions it may take, and the evidence required before release. Start with the business transaction. Add autonomous decisions only where choosing the next step is genuinely useful and where the consequences can be bounded and tested.
First, decide whether choosing the next step is the problem
An invoice that follows a fixed validation and approval sequence may need extraction plus a conventional workflow. A research task that must investigate several systems, resolve missing context, and decide which allowed lookup to perform next may benefit from an agent. Neither needs an unrestricted ability to act.
Ask the provider to identify the decisions delegated to the model. ‘We use agents’ is a design choice, not a business deliverable. If the next step is always known, a fixed sequence can be easier to inspect and operate. If an agent is justified, define what it should do when it has exhausted its permitted tools, time, or attempts.
| What varies? | Starting point | Question for the provider |
|---|---|---|
| Nothing; fields and routing are fixed | Rules and ordinary integration | What uncertainty would an LLM resolve here? |
| Language or document format | A bounded model step inside a fixed workflow | Can the output be validated before anything changes? |
| Which evidence to gather next | An agent with scoped tools and an explicit stopping point | Which choices improve the outcome, and which actions remain prohibited? |
Commission actions individually
Consider an illustrative service-desk assistant that investigates a customer’s request. It can retrieve eligible case history, propose a category, draft a response, and prepare a refund recommendation. Each verb needs a separate permission. A useful assistant can prepare a refund without being allowed to issue one.
OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency. Its guidance supports limiting tools and enforcing authorization in downstream systems. A prompt telling the model to be careful is not a substitute for those controls.
Investigate
Read the records the requesting user is permitted to see.
Recommend
Present a proposed response or action with supporting evidence.
Execute if authorized
The application checks approval and policy before a consequential change.
These are separate capabilities. Giving the agent the first two does not require giving it the third.
Replace ‘human oversight’ with an explicit permission matrix
Use an action matrix in the proposal review. This example is a starting design to adapt, not a universal refund policy. Your process owner must define any monetary limits, restricted cases, and approval authority. The implementation team must show how those decisions are enforced.
| Action | Allowed in this design | What must be demonstrated |
|---|---|---|
| Read a customer case | Only records within the user’s access | A record outside the user’s permitted scope cannot be retrieved or exposed |
| Draft a response | Prepare text without sending | Uncertain statements are visible to the reviewer |
| Send a response | Only after approval of the exact content and recipient | Changing the draft or recipient invalidates that approval |
| Propose a refund | Prepare evidence and amount for review | The recommendation cannot call the payment operation |
| Issue a refund | Separate authorized operation with policy checks | An unauthorized or duplicate attempt cannot create a payment |
Choose the acceptance cases before the demonstration
Agree a representative set of normal, ambiguous, and adversarial cases, including inputs the developer did not use while tuning the system. Ask for the case-level outcome, tool actions, escalation reason, elapsed time, and cost. A single aggregate success rate hides the difference between a wrong draft and an unauthorized payment.
For the service-desk example, include a message that asks the agent to ignore company policy, a missing record, an ambiguous customer match, an expired approval, and a timeout after a write. Show that a malicious instruction inside a retrieved document is treated as untrusted content. Test the policy checks themselves as well as the model’s behavior.
Set thresholds according to the consequences and sample coverage. A requirement that every tested unauthorized payment is blocked is a release gate for that test set; it does not establish that no future failure is possible. Record the remaining limitations and who accepts them. Keep a manual route available for cases the system cannot finish.
Cost a completed case, including the review queue
A low model bill can coexist with an expensive operation. Count tool calls, hosting, licenses, review, correction, and maintenance. An agent that makes repeated attempts may have a different cost and latency profile from the demonstration you watched.
Use a case-level estimate: model and tool cost + additional infrastructure cost + review minutes × loaded cost per minute + correction cost. Allocate shared support costs separately. State whether routine review is already included in your time-saving assumption so it is not counted twice.
For a simple illustration, suppose a case uses $0.20 of model and tool services and needs three minutes of review at $40 an hour. Review adds $2, bringing the case to $2.20 before infrastructure, support, and corrections. These are invented planning inputs, not market prices or measured PlatformBridge results. The point is to make the review assumption visible.
Make the handover an acceptance milestone
Require the configuration, source or agreed usage rights, deployment instructions, test cases, action permissions, and runbook that your team needs to operate the system. Confirm who owns model-provider and tool accounts. A change to a prompt, model, tool definition, or data source should have a named approver and a clear route through retesting.
Ask an operator to pause execution, locate a stuck case, inspect its history, and follow the recovery procedure before sign-off. Define support hours and escalation responsibilities in the engagement rather than inferring them from the word ‘managed.’ Only expand the action set after the first scope has evidence of acceptable behavior in use.
- A bounded job, with explicit completion and stop conditions.
- A permission matrix connected to real system controls.
- Acceptance evidence for complete cases, including failures.
- A cost model that includes people and ongoing operation.
- An owner who can pause, recover, and approve changes.
Take this into the conversation
A brief your team can use.
An editable Markdown brief for comparing proposed actions, acceptance evidence, and handover responsibilities.
Download the agent commissioning briefSources & further reading
Primary documentation for the technical points cited above. The decision frameworks and illustrative examples are PlatformBridge’s editorial guidance.