Ai AppliedAI agents cross an important line when they move from answering questions to taking action. The first time an agent updates a customer record, approves a refund, executes code, changes a forecast, or triggers an operational workflow, model accuracy stops being the only question.
A more consequential question appears: what is this agent allowed to do, under whose authority, and how do we stop it?
That question is becoming urgent as agentic AI moves from demonstrations into production. The market naturally focuses on model capability—better reasoning, longer context, more tools, and greater autonomy. But in an enterprise, the model is only one component. The quality of the surrounding control system determines whether an agent becomes a dependable capability or an unpredictable source of operational risk.
A production agent should not be defined only by what it can do. It should be defined just as clearly by what it cannot do.
Production looks different from the demo
Agent demonstrations tend to celebrate long, uninterrupted chains of work. Production systems reward something different: reliability, bounded execution, recoverability, and clear ownership.
A recent IBM Research study examined 20 production case studies and surveyed 306 practitioners across 26 domains. It found that 68% of production agents execute no more than ten steps before human intervention. Seventy percent rely on prompting existing models rather than model fine-tuning, and reliability remains the leading development challenge.
This is an important signal. Successful production agents are not necessarily the most autonomous systems. They are often the systems whose autonomy has been deliberately shaped around a well-understood workflow.
The hard work is not simply teaching an agent how to act. It is designing the boundary within which action is useful, observable, and safe.
Intelligence and authority are different things
An agent may be capable of reading an entire customer history, issuing a refund, changing an address, applying a retention offer, and closing an account. That does not mean it should receive all those permissions for every customer interaction.
Enterprise software has traditionally separated identity, permissions, workflow state, and business rules. Agentic systems blur those layers. A model interprets intent, selects tools, sequences actions, and adapts its plan as new information appears. This flexibility is what makes agents valuable, but it also creates a larger authority surface.
A static credential set is a poor match for a dynamic task. If an agent permanently holds every permission it might ever need, a prompt injection, reasoning error, compromised connector, or misunderstood request can turn a narrow task into a much larger incident.
Recent research on dynamic capability scoping makes the case for task-specific least privilege: combine a role-based permission ceiling with the current task context and policy rules to determine the minimum authority required for that action. The practical principle is simple: a permission that is not present in the agent’s context cannot be misused.
Build an Agent Authority Map
Before choosing an agent framework or model, I believe teams should create an Agent Authority Map. It is a concise description of the operating boundary within which the agent is trusted to work.
The map should answer seven questions:
- Outcome: What business outcome is the agent responsible for, and what is explicitly outside its mandate?
- Information: Which data can it read, at what level of sensitivity, and for how long can that context be retained?
- Actions: Which tools and systems can it invoke, and which operations are read-only, reversible, or irreversible?
- Limits: What caps apply to time, steps, cost, transaction value, volume, and frequency?
- Checkpoints: Which decisions require confirmation from a person or another deterministic control?
- Evidence: What must be logged so that the organization can reconstruct the agent’s inputs, decisions, tool calls, outputs, and approvals?
- Expiration: When should the permission, task, session, or operating assumption automatically end?
This is not a theoretical governance artifact. It is an implementation specification. Each answer should map to an identity rule, tool contract, policy check, runtime limit, approval step, audit event, or evaluation.
Give the agent only the authority the task requires
Consider a customer-service agent handling a refund request. It may need to read the order, confirm delivery status, review prior refunds, and calculate eligibility. Those are information-gathering actions. Issuing the refund is different: it changes a financial system and creates an external side effect.
A sensible design can let the agent gather evidence and recommend the outcome while requiring approval above a defined amount. For low-value, low-risk cases with strong evidence, the agent may receive a short-lived permission to complete the refund. That permission should apply to one customer, one order, one amount, and one time window—not to the entire refund system indefinitely.
The same pattern applies elsewhere:
- A finance agent can reconcile transactions without being able to release a payment.
- A sales agent can prepare an offer without being able to alter approved pricing boundaries.
- A coding agent can create and test a change in an isolated environment without receiving unrestricted production credentials.
- An HR agent can assemble policy information without making a consequential employment decision.
Least privilege must become contextual. The agent’s authority should expand only when the task, evidence, policy, and approval state justify it.
Separate reversible work from irreversible action
Not all agent mistakes have the same consequence. A weak draft can be discarded. A search can be repeated. A recommendation can be challenged. But a payment, customer communication, production deployment, account closure, or regulated decision may be difficult or impossible to reverse.
This distinction should shape the workflow. Let agents operate more freely where actions are low-cost and reversible. Introduce stronger gates where an action crosses an external, financial, security, privacy, legal, or reputational boundary.
Human oversight should not mean asking someone to watch every step. That defeats the purpose of automation. The better design is to place human judgment at material decision points and give the reviewer the evidence required to make a fast, informed decision.
Microsoft’s recently announced Project Perception illustrates this broader shift. Its security agents continuously perceive, reason, and act across specialized roles, but the architecture also emphasizes shared context, operational controls, and keeping defenders in control. The important lesson is not limited to cybersecurity: coordinated action requires a coordinated control plane.
Observability is part of the product
Traditional application monitoring asks whether a service is available, fast, and error-free. Agent monitoring must also ask whether the system selected the right goal, used the appropriate information, invoked the right tools, stayed within policy, and produced an acceptable business outcome.
Every material agent run should leave enough structured evidence to answer:
- What request initiated the work?
- Which identity and permissions did the agent use?
- What information influenced the decision?
- Which tools were called, with what parameters and results?
- Where did a person approve, reject, or modify the proposed action?
- Did the outcome satisfy the business and policy criteria?
This evidence supports more than incident response. It creates the data needed to evaluate reliability, tune policies, compare models, identify recurring exceptions, and decide whether the agent has earned greater autonomy.
Autonomy should be earned in stages
Organizations do not have to choose between a passive chatbot and a fully autonomous agent. A safer adoption path progresses through four stages:
- Observe: the agent watches the workflow and identifies patterns without affecting it.
- Recommend: the agent proposes decisions or actions while a person remains responsible for execution.
- Act with approval: the agent prepares and executes actions after a defined checkpoint.
- Act within bounds: the agent operates independently for a narrow class of cases, escalating exceptions and higher-risk decisions.
Movement between stages should be based on evidence, not enthusiasm. Accuracy alone is insufficient. Teams should measure exception rates, policy violations, reversals, time saved, user outcomes, operating cost, and the quality of escalation.
AWS has made a similar production distinction in its work on secure agent platforms: model and agent frameworks provide building blocks, but organizations still need runtime isolation, guardrails, least-privilege access, and operational governance to deploy agents at scale.
Do not let one model own the workflow
Models will continue to improve, and the best model for a task will change. An organization should therefore avoid embedding its workflow definitions, permissions, audit evidence, and business policy too deeply inside one model or vendor platform.
The durable enterprise asset is not the model. It is the combination of trusted data, well-defined workflows, explicit authority, evaluation evidence, and operational learning that surrounds the model.
A portable control layer makes it possible to adopt better models without redesigning the business process each time. It also makes model selection a measured engineering decision: use the capability that offers the right combination of quality, reliability, latency, privacy, and cost for the task.
From capable agents to accountable agents
The next phase of enterprise AI will not be won by the organization that gives agents the most freedom. It will be won by organizations that know where autonomy creates value, where judgment must remain human, and how to expand the boundary safely as evidence accumulates.
Better models matter. But model capability without bounded authority is not an operating model. It is an uncontrolled dependency.
Start with one meaningful workflow. Define the outcome. Map the authority. Separate reversible work from consequential action. Instrument the evidence. Then let the agent earn a wider role.
Explore how Ai Applied helps organizations design and implement production-ready Agentic AI →