Part 2 of the AI Agents in the Real World series.
“Book the best flight under $800.”
The request sounds precise. It is not.
Does “best” mean shortest, refundable, nonstop, preferred airline, or arrival before a meeting? Can the agent use stored passport details? May it accept a basic-economy restriction? Is $800 the ticket price or the final price after bags? Can it move another calendar event? Does the user want a recommendation, a held itinerary, or a completed purchase?
A human travel agent would surface these questions because the commercial and social norms of the job demand it. A software agent can instead convert missing terms into silent assumptions.
The dangerous unit in agentic computing is not the prompt. It is the delegation: a person or organization temporarily grants a machine the authority, information, and resources to pursue an outcome.
Delegation needs a contract.
The real failure is authority drift
An agent’s plan changes as it encounters the world.
The preferred flight sells out. A form asks for another identifier. A support case links to a document. A deployment check fails. A vendor offers a substitute. Each event creates a new branch, and each branch can move the run farther from the authority the person thought they granted.
Five forms of drift are common:
| Drift | What changes | Example |
|---|---|---|
| Goal drift | The means quietly becomes the end | “Find options” turns into “complete purchase” |
| Parameter drift | A material field changes | Arrival moves from Tuesday night to Wednesday morning |
| Data drift | The agent reaches for another source | Calendar access expands to email and cloud drive |
| Authority drift | A reversible step becomes consequential | Drafting becomes sending; preview becomes deployment |
| Time drift | Old permission survives a changed situation | Yesterday’s incident approval is reused after containment |
Traditional software can validate a fixed API request. An agent creates requests while planning. The control therefore has to bind the evolving plan back to the original intent.
Why “ask me before doing anything” fails
Confirmation is necessary for some actions. Confirmation is not a complete delegation model.
OpenAI’s Operator system card reports model mistakes including an email sent to the wrong recipient, incorrectly removed email labels, an incorrectly dated medication reminder, and a wrong food-delivery item. The deployed mitigation included confirmation before consequential actions, watch mode on sensitive sites, and refusal of some high-risk tasks. The system card reports that confirmations reduced the measured risk from model mistakes by about 90% in its evaluation setting.
That is evidence that confirmations can work. It is also evidence that the confirmation screen carries real responsibility.
If a user sees twelve prompts during one task, each with vague language such as “Allow?” or “Continue?”, the interaction becomes a compliance ritual. NIST warns that overly chatty agents can create consent fatigue analogous to repeated authentication prompts: people learn to click through.
The design goal is not maximum confirmation. It is minimum sufficient, high-information confirmation.
The delegation contract
A delegation contract is a frozen, inspectable statement of the task and the authority available to complete it. It exists before the first consequential tool call.
delegation_id: del_20260901_0042
principal:
user_id: user_1842
organization: tenant_acme_prod
goal:
outcome: "Reserve one refundable flight to Mumbai"
completion_definition: "Hold itinerary; do not purchase"
constraints:
origin: "Bengaluru"
arrival_before: "2026-09-18T18:00:00+05:30"
maximum_total_price_inr: 18000
stops_allowed: 0
substitutions_allowed: false
data_scope:
allow: ["calendar.availability", "travel.profile.basic"]
deny: ["email.body", "contacts", "payment.credentials"]
authority:
allow: ["search", "compare", "hold"]
deny: ["purchase", "cancel_existing", "send_message"]
approval_triggers:
- "price exceeds limit"
- "arrival window changes"
- "new data source required"
- "action becomes a purchase"
validity:
expires_at: "2026-09-01T10:15:00+05:30"
maximum_tool_calls: 20
on_uncertainty: "return options and ask"
on_failure: "stop without side effects"
receipt_required: trueThe schema is illustrative, not a universal standard. Its value comes from the questions it forces.
Seven fields that cannot remain implicit
1. Completion definition
“Plan,” “handle,” “fix,” and “manage” are not completion states.
Use an observable end state:
- produce three options,
- create a draft but do not send,
- hold a reservation but do not purchase,
- open a pull request but do not merge,
- prepare a refund proposal but do not issue it.
The completion definition is the first boundary between assistance and action.
2. Material constraints
Record the fields a reasonable person would use to decide whether the result is still the same deal: recipient, amount, date, destination, affected account, cancellation policy, environment, and reversibility.
Do not hide these inside the conversation history. Put them in structured state that can be compared before execution.
3. Data scope
Authority to act does not imply authority to inspect every possible source. A scheduling task may need free/busy information, not meeting titles. A refund task may need order state, not the customer’s entire message history.
Use purpose-specific views wherever possible. “Calendar availability” is safer than “calendar.” “Customer eligibility facts” is safer than “CRM access.”
4. Action scope
Separate verbs that products often collapse:
| Read | Prepare | Commit |
|---|---|---|
| Search flights | Build itinerary | Purchase ticket |
| Read incident state | Prepare mitigation | Change production |
| Read order | Draft refund proposal | Issue refund |
| Read inbox headers | Draft response | Send email |
The agent should receive only the verb class needed for the completion definition. ContextOS uses explicit approval-mode tiers to keep this distinction in the runtime contract.
5. Resource limits
Set limits on money, time, external messages, mutations, and tool calls. A resource limit is both a cost control and a signal that the plan is no longer the plan the user authorized.
“Under $800” should mean total charged amount, currency, tax treatment, and whether the limit applies per item or to the whole run.
6. Change triggers
The agent should not ask again because a page changed color. It should ask when a material term changes.
At minimum, re-authorization should be considered when any of these changes:
- recipient or affected party,
- price or financial exposure,
- data category,
- destination system,
- reversibility,
- public visibility,
- legal or policy basis,
- environment, such as test to production,
- the agent or subagent performing the action.
7. Expiry and revocation
Delegation should end. Bind it to a task, a time window, and ideally a short-lived capability. Do not convert “help me today” into a standing credential.
NIST’s identity guidance calls out the risk of static API keys and long-lived bearer tokens, particularly when carried across tools and networks. The technical implementation may use OAuth, workload identity, sender-constrained tokens, or another mechanism. The product principle is simpler: authority should expire with the reason it was granted.
Design the confirmation as a diff
The best confirmation screen answers three questions:
- What exactly will change?
- How is this different from what I already authorized?
- What will be difficult or impossible to reverse?
Bad confirmation:
Continue with booking?
Better confirmation:
Purchase one non-refundable ticket for INR 17,420 on Flight XY123, arriving 17:40 on September 18. This changes the authorized action from “hold” to “purchase” and introduces a non-refundable fare. Charge Visa ending 1842?
The user should see the frozen proposal, not a summary generated from a proposal that may continue changing underneath it. After approval, execution should be bound to the proposal hash or exact typed fields. If a material field changes, the approval is invalid.
This is the same reason Google’s Agent Payments Protocol work added Verifiable Intent: autonomous transactions need a tamper-resistant link between the user’s authorization and the agent’s action. A payment protocol is narrower than a general delegation contract, but the principle travels.
A useful receipt closes the loop
The run should end with a receipt, including when it failed.
delegation_id: del_20260901_0042
status: completed
authorized_by: user_1842
proposal_version: 3
actions:
- tool: travel.hold
target: itinerary_881
result: success
reversible_until: "2026-09-01T09:42:00+05:30"
data_sources_used:
- calendar.availability
- travel.profile.basic
material_changes: []
policy_exceptions: []
expires_at: "2026-09-01T10:15:00+05:30"For a person, this is the “what happened?” screen. For an enterprise, it becomes the evidence needed for support, audit, dispute handling, replay, and incident response.
Personal checklist: before connecting an agent
An individual can apply the same model without writing YAML.
- State whether the agent should research, draft, reserve, send, buy, or change.
- Give a price and time limit in explicit units.
- Name data the agent must not use.
- Require confirmation for recipient, total charge, deletion, publication, and non-reversible changes.
- Prefer logged-out or separate-session browsing when account access is unnecessary.
- Do not paste passwords or recovery codes into an agent conversation.
- Revoke the connection when the task ends.
- Save the final receipt for purchases, cancellations, and account changes.
Enterprise checklist: before granting authority
- Give the agent a distinct identity; do not make it indistinguishable from the employee.
- Bind authorization to task, principal, audience, and expiry.
- Compile a typed proposal before consequential action.
- Show approvers evidence and material diffs, not a generic yes/no prompt.
- Enforce denial at the tool gateway, not only in the model prompt.
- Re-authorize on material plan changes and subagent delegation.
- Record the exact approved proposal and exact executed mutation.
- Test rejection, timeout, duplicate execution, revocation, and rollback paths.
The governance foundation and approval-gate tutorial show how those controls fit a governed runtime.
The test: can authority survive a changing plan?
A delegation system is not good because the first prompt looks clear. It is good when the tenth step is still authorized by the first person for the same purpose.
That requires more than a capable model and more than a row of confirmation dialogs. It requires a contract that travels with the run, narrows its permissions, detects material change, expires, and leaves a receipt.
The goal is not to keep a human clicking.
The goal is to keep human intent attached to machine action.