If your roadmap says an AI agent will book, buy, schedule, update records, or trigger a workflow, the decisive product question is not whether the model can produce a plausible plan. It is whether your system can turn a person’s intent into an authorized action without silently crossing a boundary.
Before you add more tools, define the delegation contract, permission model, evidence trail, and failure path. Those choices determine whether useful automation becomes a trusted product or an expensive source of side effects.
Treat delegation as a product contract
A conversational assistant returns information for a person to review. An agent can change the state of the world: send a message, reserve inventory, modify a customer record, submit an order, or move a workflow forward. The interaction shifts from asking for an answer to giving the system a goal, relevant materials, constraints, and a result to produce.
That shift changes the unit of product design. You are no longer designing only a response. You are designing a delegation: who is asking, what outcome they want, what authority they have granted, which actions the agent may take, and what evidence it must return.
Intent is not the same as authority. If a user asks an agent to find an option, that does not authorize a purchase. If the user asks it to handle a task, that still may not authorize every possible method. Your agent should treat the request as the start of an authorization decision, not as permission to improvise.
Put a delegation contract in the product requirements
For each agent journey, write down seven things before discussing prompts or model choice:
- Outcome: What completed job will the user recognize? Define the result, not a vague capability such as helping with procurement.
- Inputs: Which records, files, messages, preferences, and live system data may the agent use?
- Constraints: What budget, deadline, geography, policy, quality bar, or business rule limits the result?
- Permitted actions: Which tools and state-changing operations may the agent invoke for this job?
- Approval boundaries: Which decisions require confirmation, and exactly what information must the user see before approving?
- Stop conditions: When must the agent pause because information is missing, constraints conflict, or the available options fall outside policy?
- Evidence and recovery: What receipt will the user receive, and how can the action be corrected, canceled, or escalated?
Consider a request to find a laptop under $1,500 with 32 GB of RAM, good battery life, and delivery before Friday. The agent can retrieve products, filter specifications, compare prices, and check delivery while remaining inside a discovery task. Purchasing introduces new decisions: whether the budget includes tax and shipping, which sellers are acceptable, whether substitutions are allowed, which payment method may be used, and whether accepting the seller’s terms is authorized.
Do not leave those decisions hidden inside a system prompt. Represent them as product policy. If a missing detail could materially change cost, recipient, commitment, or access, the agent should ask at the decision boundary. It should not guess and explain afterward.
Grant authority per action, not per agent
An agent is not simply safe or unsafe. The same agent may be trustworthy enough to read a catalog but not to place an order, draft a refund but not approve it, or prepare a customer message but not send it. Assign autonomy to individual actions and conditions rather than giving the agent one broad permission level.
This action ladder is a useful starting posture:
| Action class | Examples | Default starting posture | Evidence to retain |
|---|---|---|---|
| Observe | Search, retrieve, read, and compare | Allow only after the user has consented to the relevant data access | Data accessed, retrieval time, filters, and sources considered |
| Recommend or draft | Rank options, prepare an order, draft a message, or propose a record change | Allow creation of a reviewable artifact, but do not represent it as the user’s decision | Options considered, applied constraints, assumptions, and proposed change |
| Reversible execution | Create a freely cancelable reservation or update a noncritical editable field | Automate only inside explicit limits with a dependable undo path | Before-and-after state, policy used, confirmation, and reversal method |
| Consequential execution | Charge a payment method, send an external message, approve a refund, accept terms, or delete data | Require explicit approval unless the user has granted narrow, standing authority for that exact action | Recipient, value, terms, approver, timestamp, resulting state, and receipt |
Reversibility is a business property, not merely an API feature. Deleting a calendar event may be technically reversible but still cause a missed meeting. Refunding a charge may restore the money but not the inventory or customer relationship. Sending a correction does not unsend the original message. Evaluate the real consequence, not the presence of an undo endpoint.
For every state-changing action, assess:
- Impact: What can the user, customer, company, or third party lose?
- Reversibility: Can the prior state be restored completely, quickly, and without an additional cost?
- Scope: Does the action affect one record, one account, or an entire portfolio?
- Ambiguity: How many reasonable interpretations of the instruction exist?
- Dependency risk: Can an external service fail after an earlier step has succeeded?
- Detectability: Will you know promptly if the result is wrong or incomplete?
Translate that assessment into controls. Use least-privilege credentials, action-specific scopes, recipient allowlists, budget caps, rate limits, expiration times, and step-up approval for exceptions. Use preview or dry-run operations where available. Attach an idempotency key to retryable transactions so a timeout does not become a duplicate order, booking, or payment.
The approval experience must show the commitment, not just an inviting button. Display the action, recipient, amount or scope, important terms, and what can or cannot be reversed. For regulated, contractual, privacy-sensitive, or financial workflows, involve the appropriate security, privacy, legal, and risk owners before granting standing authority. A prompt telling the model to be careful is not an authorization control.
Build an interface agents can understand and use correctly
Your own product may deploy an agent, but your company may also receive requests from agents operated by customers or partners. A customer could complete discovery, comparison, and a transaction without navigating your website. That means your service needs an agent-facing product surface in addition to its human interface.
Being agent-ready requires more than publishing an API. The service must be discoverable, interpretable, accessible, actionable, attributable, authorized, and auditable:
- Discoverability: Give products, plans, policies, and actions stable identifiers. Make supported capabilities findable without relying on visual navigation.
- Interpretability: Return structured fields with explicit units, currencies, status values, timestamps, and definitions. Do not make an agent infer whether a price includes tax or whether available means available for the requested delivery location.
- Access: Offer a documented, authenticated interface with predictable schemas, pagination, versioning, and machine-readable errors.
- Action: Provide transactional operations with validation, previews where appropriate, idempotency, confirmation, and a clear representation of the resulting state.
- Identity: Distinguish the end user, the agent acting for that user, the agent’s operator, and the credential used for a particular request.
- Authority: Verify that the user can perform the underlying action and that the agent has been delegated the necessary scope. Both conditions must hold.
- Auditability: Produce a durable receipt that ties intent, identity, authorization, policy, tool execution, and outcome together.
Policies deserve the same treatment as product data. A cancellation rule buried in prose may be understandable to a person but difficult to apply consistently during an automated decision. Where possible, expose material conditions as structured fields: eligibility, geographic restrictions, cancellation cost, return window, required approvals, and exceptions. Keep the human-readable explanation, but do not force the agent to reconstruct operational policy from marketing copy.
Machine-readable does not mean publicly accessible. Personal data, negotiated pricing, account-specific availability, and privileged operations should remain protected by authentication and authorization. The goal is precise access, not unrestricted access.
Your website and brand still matter to the person establishing preferences and trust. What changes is the path between intent and action. In an agent-mediated journey, software can evaluate alternatives and select a provider before a human visits a page. Product and growth teams should therefore measure whether agents can retrieve an accurate offer, understand its conditions, complete an authorized transaction, and return a usable receipt. Traffic and click-through rate cannot describe that journey by themselves.
Evaluate behavior at the point where state changes
A polished answer is weak evidence that an agent can act safely. The important evaluation unit is the complete trajectory: instruction, interpretation, permission check, tool choice, arguments, external response, state change, confirmation, and recovery.
Build an evaluation set from the actual jobs you intend to support. Include more than successful examples:
- A well-specified request that fits every policy.
- An underspecified request where a material decision is missing.
- Conflicting instructions, such as a budget that cannot satisfy the required delivery date.
- An expired, revoked, or insufficient permission.
- A price, policy, or availability value that changed between recommendation and execution.
- A tool failure after an earlier step has already changed state.
- A timeout followed by a duplicate retry.
- An instruction embedded in retrieved content that conflicts with the user’s request or product policy.
- A request that is valid for one record but unsafe when applied in bulk.
Score each trajectory on separate dimensions:
- Outcome correctness: Did the user receive the requested result?
- Constraint adherence: Were budget, timing, quality, policy, and other boundaries respected?
- Authorization correctness: Did every action stay within the user’s permissions and the agent’s delegated scope?
- Decision grounding: Can the selection be traced to current product data and explicit criteria?
- Execution integrity: Did the tools receive the correct arguments, and did the resulting state match the confirmed action?
- Side-effect control: Were duplicate, unrelated, or excessive changes prevented?
- Escalation quality: Did the agent stop and ask a focused question when it should?
- Recovery: Could the system reconcile partial work and present a safe next step?
Do not collapse these dimensions into one flattering pass rate. A completed purchase made without authorization is a failed task. So is a correctly authorized action that charges twice. Establish release thresholds for each critical dimension before the pilot begins, and make them stricter as impact and irreversibility increase.
Production telemetry should let your team reconstruct what happened without collecting unnecessary sensitive data. Record the instruction as received, the applicable policy version, identities and scopes, requested action, tool calls, sanitized arguments, response codes, state changes, approval events, and final receipt. Redact secrets and apply a retention policy appropriate to the data. An audit trail that creates a second privacy problem is not a sound control.
Design the incident path before launch. Your operators should be able to suspend an agent’s credentials, stop pending work, prevent retries, reconcile partial transactions, reverse an action when reversal is genuinely safe, notify affected users, and preserve the evidence needed for investigation. If the team cannot do those things, it is not ready to automate the corresponding action.
Roll out autonomy by earning it one boundary at a time
Start with one user job, one system of record, and a small action set. Broad mandates such as manage my operations combine too many permissions, dependencies, and interpretations to produce a trustworthy first release.
Move through five stages:
- Shadow: Let the agent inspect only data the user is entitled to access and produce a proposed plan. It cannot change state. Compare its decisions with expected decisions and investigate disagreements.
- Draft: Let the agent prepare messages, orders, updates, or workflow changes as reviewable artifacts. Nothing is submitted externally.
- Approve: Let the agent execute after the user reviews the exact commitment. Measure whether approvals are informed and whether execution matches the approved preview.
- Bounded autonomy: Allow automatic action only inside explicit policies such as permitted recipients, defined transaction types, budget limits, and time windows. Escalate every exception.
- Selective expansion: Add actions, users, and systems independently. Do not treat success on one workflow as proof that a higher-impact workflow is safe.
Before advancing a workflow, verify that unauthorized requests are refused, revoked access takes effect, retries do not duplicate actions, partial failures leave a reconcilable state, and the receipt matches the real system of record. Confirm that users can inspect current permissions, revoke future authority, and identify which actions were performed on their behalf.
Your launch metrics should distinguish at least three outcomes: the agent could not act because authority was correctly denied; the agent was authorized but execution failed; and the agent acted successfully within policy. Combining all three into a generic failure rate will punish correct refusals and hide operational defects.
Key takeaways
- Treat a user’s instruction as a request to interpret, not unlimited permission to act.
- Assign autonomy to individual actions based on impact, reversibility, scope, ambiguity, dependencies, and detectability.
- Make products, policies, identities, permissions, actions, and receipts machine-readable.
- Evaluate the full action trajectory and resulting side effects, not just the quality of the agent’s prose.
- Expand autonomy only after the system can refuse, execute, recover, and explain behavior reliably inside the current boundary.
At your next roadmap review, take the highest-value agent journey and underline every verb that changes state. For each verb, name the authority required, approval rule, maximum scope, receipt, and recovery path. The missing answers are the real product backlog.
Ship the first version when its boundary is clearer than its capability. Broader authority should be earned through observable, reliable behavior, while the user remains able to see what the agent can do, what it did, and how to stop it.
References
- AI Wide Open — Your Next Customer May Be an AI Agent
- Learn Easy AI — How Non-Technical People Can Work With AI!
