An AI product can answer questions, summarize records, and propose changes without receiving authority over the customer or business system.
The architecture changes when the same product must close a case, adjust an account, send a message, approve a document, or change production infrastructure.
The product has reached a permission ceiling. Its next useful feature needs write access, but its existing controls were built for people, roles, and long-lived services.
The next release needs a new question: what is the smallest amount of authority that can complete this task reliably?
The permission ceiling is a product boundary
A permission ceiling appears when more model capability no longer moves the roadmap forward. The model may understand the task. The product still cannot let it perform the task.
This is not only a security objection. Write access changes the product contract.
Before write access, a wrong answer can mislead a user. After write access, a wrong action can change money, access, customer state, production state, or an external communication.
The product now needs to answer five questions:
- Which exact action may the agent perform?
- Who or what delegated that authority?
- Which target, fields, values, tenant, and environment are allowed?
- What final state proves that the task is complete?
- What happens when the result is unknown or partly complete?
These questions belong in the architecture and release plan. A prompt cannot enforce them by itself.
What changes at the first real write
Read access returns information. Write access creates a consequence.
A support assistant that finds a case is still an information product. A support agent that changes the case status is an operator inside the support system.
A commerce assistant that explains a refund policy is still advising. A commerce agent that applies a credit changes financial and customer state.
An infrastructure assistant that drafts CloudFormation is still preparing work. An infrastructure agent that deploys it changes a cloud account.
The distinction is not whether the action uses an API, MCP, a browser, or generated code. The distinction is whether the action changes a state that another person or system depends on.
That first write introduces new product requirements:
- authority must be bound to a task;
- credentials must match the action scope;
- current state must be checked before execution;
- the exact parameters must remain inside policy;
- the final state must be verified independently;
- retries must not create a second consequence;
- a person must be able to reconstruct why the action was allowed.
Five levels of agent authority
“Autonomous” and “not autonomous” are too broad for release planning. Authority is easier to review as five levels applied to one action class.
| Level | Agent authority | Human responsibility | Release evidence |
|---|---|---|---|
| 1. Read | Read permitted information | Interpret and act | Correct access, provenance, and tenant scope |
| 2. Recommend | Propose one action with evidence | Decide and execute | Useful proposals and safe escalation |
| 3. Prepare | Create the exact pending change | Review and submit | Correct target, fields, values, and evidence |
| 4. Act after approval | Execute one approved action | Approve the exact action | Fresh approval, safe execution, verified final state |
| 5. Act inside policy | Execute within proven limits | Own policy and exceptions | Stable outcomes inside explicit limits |
The level applies to the action, not the whole agent.
A customer-operations agent may read all eligible cases, prepare a status change, execute a low-risk tag update after approval, and remain unable to apply a financial adjustment.
That mixed state is normal. It lets useful parts of the workflow move forward without turning one release into a vote on unlimited autonomy.
Why mature products carry more constraints
A mature product does not begin with an empty permission model. It already has customers, roles, approval paths, systems of record, audit duties, and several teams that own parts of the workflow.
That installed operating model is valuable. It is also why an action-taking agent cannot be treated as another interface.
A person signs in with a role, sees a screen, performs a known action, and remains accountable under an established process.
An agent can choose tools, change parameters, cross systems, continue after the first request, and retry when a response is unclear.
The agent is a non-human operator. Its authority must be more explicit because its path can be less predictable.
The product team must preserve existing controls while adding four new links:
- the person or business process that delegated the work;
- the agent identity and version that performed it;
- the policy decision that allowed each action;
- the final-state evidence that proves the result.
This does not mean the internal team failed. It means a new product actor needs a control layer that the earlier product did not require.
The same problem appears in different industries
The action changes, but the release question stays consistent.
Commerce
If an agent can adjust an order, the boundary may include an amount limit, reason code, eligible order state, market, customer type, and approval rule.
The final state may need evidence from both the order system and the payment or credit ledger.
Customer operations
If an agent can close a case, completion may depend on a provisioning job, identity update, delivery event, or external message.
The support system alone may not be the final source of truth.
Regulated workflows
If an agent can update a compliance, finance, health, or legal record, the release may need source provenance, named approval, field limits, reason codes, and a durable authority chain.
The action must remain reviewable without assuming that the model explanation is the audit record.
Platform and infrastructure
If an agent can change cloud or platform state, the boundary may include account, environment, region, resource class, change window, budget, and rollback path.
A valid deployment request is not evidence that the resulting service is healthy.
Enterprise workflows
If one user request crosses CRM, billing, messaging, and a system of record, the request does not create unlimited authority across every later tool call.
Each action needs to remain tied to the original purpose and current task state.
These are conditional situations. A public AI feature does not prove that a company has given an agent write access.
Choose the smallest useful action
The first action should be useful enough to matter and narrow enough to teach the team something reliable.
A trivial action may create activity without producing release evidence. A high-consequence action may lose stakeholder approval after one unclear result.
Score each candidate action on five tests.
Business value and frequency
Does the action remove a real delay, repeated handoff, or operating cost? Does it occur often enough to produce useful evidence?
Failure consequence
What is the worst credible result? Consider money, access, production health, customer trust, legal effect, and manual recovery.
Reversibility
Can the team undo the change directly? If not, is there a defined compensating action?
Verification strength
Can an independent system prove the final state? If the agent cannot know whether it succeeded, it cannot retry safely.
Boundary precision
Can the team state the eligible records, allowed fields, parameter ranges, tenant, environment, volume, and expiry in clear rules?
The strongest first action has material value, limited consequence, clear reversal, strong verification, and a precise boundary.
The release question engineering and security can answer
“Can we launch an autonomous agent?” bundles too many decisions into one question.
It asks engineering and security to approve an undefined set of tools, targets, parameters, future states, and failure paths.
A reviewable release question is narrower:
Can this agent perform this action, for this principal and task, on these targets, inside these limits, until this expiry, with this approval, verification, and recovery path?
That question turns a general risk discussion into an architecture decision.
It also makes disagreement useful. Product can challenge whether the action creates enough value. Security can challenge the credential or scope. Operations can challenge recovery. Engineering can challenge verification.
The team can improve one boundary without reopening the entire AI strategy.
Use the Agent Action Boundary Canvas
The Agent Action Boundary Canvas turns this release question into a working action contract.
Use it for one state-changing action, not the whole workflow. Record the system, principal, task, scope, credential, evidence gate, approval, expected state, retry rule, recovery path, and audit owner.
For a faster working session, use the one-page decision sheet.
The goal is not maximum authority. The goal is the smallest authority that can complete a useful task and produce evidence for the next decision.