An AI product needs write access when it must close a case, adjust an account, send a message, or change production state. Until then it can answer, summarize, and propose without authority over the system of record. Bigcircle sees the permission ceiling on client systems, where the controls already built for people, roles, and long-lived services meet an agent that has to act. The next release should ask for the smallest authority that can complete the task reliably.
Key facts
Definition
An AI product needs write access when it must close a case, adjust an account, send a message, or change production state, and until then it can answer without authority over the system of record.
How Bigcircle does it
- Bigcircle leaves the product on answers, summaries, and proposals until the task has to change a state another person or system depends on.
- The next release asks for the smallest authority that can complete that task reliably.
- Bigcircle puts five questions in the architecture: the exact action, who delegated it, the allowed target, the final state that proves completion, and what happens when the result is unknown.
Comparison
Before write access a wrong answer can mislead a user, and after write access a wrong action can change money, access, customer state, or production state.
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 perfectly well and the product still cannot let it perform the task, which is not only a security objection. Write access changes the product contract itself. 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 in the release plan, because a prompt cannot enforce any one of them by itself.
What changes at the first real write
Read access returns information and write access creates a consequence. A support assistant that finds a case is still an information product, while 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, and 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. The call that performs the write still has to be authorized in tool access in production.
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. Moving one action up a level is the release model in how to roll out agent autonomy.
| 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. The contract for that one action is an Agent Action Boundary. 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, and 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, and 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, and its authority must be more explicit because its path is less predictable. Choosing the next tool on that path is a production agent loop.
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 never required.
The same problem appears in different industries
The action changes from product to product, and the release question underneath it stays the same in every one of them.
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 the current task state. These are conditional situations, and 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, and a high-consequence action may lose stakeholder approval after a single unclear result. Score each candidate action on five tests.
| Test | What to ask |
|---|---|
| Business value and frequency | Does the action remove a real delay, repeated handoff or operating cost, and does it occur often enough to produce useful evidence? |
| Failure consequence | What is the worst credible result, once you have considered money, access, production health, customer trust, legal effect and manual recovery? |
| Reversibility | Can the team undo the change directly, and if it cannot, is there a defined compensating action that someone owns? |
| Verification strength | Can an independent system prove the final state, given that an agent which cannot know whether it succeeded cannot retry safely? That gap is why agents report unfinished work as done. |
| 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 scores well on all five at once, which means it 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, because 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, and it also makes disagreement useful. Product can challenge whether the action creates enough value, security can challenge the credential or the scope, operations can challenge the recovery path, and engineering can challenge how the result gets verified. The team can then improve one boundary at a time without reopening the entire AI strategy every quarter.
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 rather than the whole workflow, recording 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.
Production takeaways
- A permission ceiling is a product boundary, not a security objection. More model capability stops moving the roadmap once the next feature needs write access.
- Read access returns information and write access creates a consequence. That first write changes the product contract.
- Authority is five levels applied to one action class, and the level belongs to the action rather than to the agent.
- Mixed maturity is normal. One action can reach bounded execution while another stays behind approval indefinitely.
- Mature products carry more constraints because they already have roles, approval paths and audit duties built for people.
- Pick the first action on value, failure consequence, reversibility, verification strength and boundary precision, and score all five.
- "Can we launch an autonomous agent?" is not a reviewable release question. Name the action, the principal, the target and the limits.
Common questions
When does an AI product need write access?#
It needs write access when the next feature must change a state that another person or system depends on, such as closing a case, sending a message, or changing production. Answering, summarizing, and proposing can stay at read or recommend without write access. The ceiling appears when more model capability no longer moves the roadmap, because the controls were built for people, roles, and long-lived services.
What changes at the first real write?#
Read access returns information, and write access creates a consequence for money, access, customer state, production, or an external message. The product then binds authority to a task, matches the credential to the action, checks the current state, and keeps the parameters inside policy. It also verifies the final state on its own, and it stops a retry from creating a second consequence. A prompt cannot enforce any of those requirements.
What are the five levels of agent authority?#
The five levels are read, recommend, prepare, act after approval, and act inside policy. The level belongs to one action class, rather than to the whole agent. One customer-operations agent can read cases, prepare a status change, and run a low-risk update after approval, while a financial adjustment stays blocked. Each promotion changes the target, the parameters, the approval, the credential, and the recovery for that action.
How do you choose an agent's first write?#
Score the action on whether it removes a delay, on the worst credible failure, and on whether someone can undo it. Also ask whether a separate system can prove the final state, and whether the records, fields, tenant, and expiry can be stated as rules. The strongest first action has real value, a limited consequence, a clear reversal, strong verification, and a precise boundary. A trivial action teaches little, and a high-consequence action can lose approval after one unclear result.
What is a reviewable question for an agent write?#
Asking whether you can launch an autonomous agent bundles tools, targets, and failure paths that have not been defined. A reviewable question asks whether this agent can perform this action, for this principal and this task, on these targets, and inside these limits. It also names the approval, the verification, the recovery path, and the expiry. Product, security, operations, and engineering can then challenge one boundary.
Why do mature products constrain agent writes?#
A mature product already has roles, approval paths, systems of record, and audit duties built for a person who signs in and stays accountable. An agent can choose tools, change parameters, cross systems, continue past the first request, and retry when a response is unclear. The authority has to name who delegated the work, which agent version performed it, which policy allowed it, and which evidence proves the result.