When AI Acts for the Company

A customer asks for a refund.

An AI agent retrieves the order, checks the relevant policy, calculates the amount, calls the payment system, updates the customer record and sends a confirmation.

The interesting part is no longer the answer.

It is the action.

The system has moved from producing information to changing something outside itself. A payment has been issued. A record has changed. A customer has received a commitment from the company.

That transition is becoming one of the defining changes in enterprise AI.

In the earlier Verba article, "When AI Speaks for the Company," the central question was what happens when AI-generated content crosses the boundary from internal assistance to official company communication. An answer could become an email, a filing, a customer promise or the basis for a decision.

Agentic systems extend that boundary. They do not only prepare work; they increasingly participate in carrying it out.

An assistant can explain a refund policy.

An agent can issue the refund.

The first produces information.

The second changes state.

That distinction changes what a production AI system has to get right.

Model quality still matters. But so do identity, authority, permissions, decision state, tool execution, recovery, human involvement and the evidence left behind.

A capable model is only one part of an agentic system.

The architecture determines what that capability is allowed to become.

From Capability to Authority

The language around agents often starts with capability.

Can the model plan across several steps, choose the right tool, navigate a website or continue a workflow without being prompted at every stage?

Those questions matter.

But enterprise systems eventually encounter another one:

Who authorised the action?

Software has always operated with permissions. What changes with agents is that the path from a person's intention to a system action becomes more dynamic.

The model may interpret what the user wants, retrieve information from several systems, choose a tool, construct its arguments and determine that the conditions for execution appear to have been met. It can propose all of that. It should not become the source of its own authority.

A useful distinction is therefore:

Capability answers what a system can do.

Authority answers what it may do.

The two should remain separate.

An employee may be allowed to view an order but not refund it. A customer may be entitled to one action but not another. A permission that existed ten minutes ago may have been revoked. An agent may technically possess credentials that allow an API call even though the person behind the request does not have the corresponding business authority.

The architecture has to carry that distinction all the way to execution.

Authority Should Follow the Principal

This becomes especially clear when an agent acts on behalf of someone else.

A convenient design is to give the agent a powerful service credential and let application logic decide what each user may do. Integration becomes easier, but the action can drift away from the authority of the person who initiated it.

A stronger pattern keeps the principal visible.

If the agent is acting for a named employee, the relevant action should be evaluated against what that employee is entitled to do, not merely against what the agent's infrastructure credential is technically capable of doing.

Vinicius Pereira, a senior AI engineer focused on production-oriented agent systems, delegated authority, durable execution and evaluation, explores the same principle in his on-behalf reference implementation. Rather than treating copied access-control information inside an AI index as permanently authoritative, candidate documents are checked against the source at request time as the signed-in user. The project deliberately models cases such as revoked grants, group membership changes and expired sharing links to show why permission state can become stale when it is merely copied.

The example is retrieval, but the principle extends naturally to action.

Authority is state, and state changes.

If an agent is about to perform something consequential, the question is not only whether permission existed when the workflow started, but whether that authority still applies when the action is about to occur.

The design rule is simple:

Keep the principal attached to the action for as long as the action depends on that principal's authority.

Identity systems will differ. The principle does not. An agent should not quietly become an independent bearer of privileges simply because it sits between a person and a tool.

A Tool Call Is Not a Business Decision

Authority tells us whether an actor may perform a class of action.

It does not tell us whether this particular action is valid.

An employee may have authority to issue refunds while a particular customer is not eligible. A purchasing agent may have authority to place an order while the price or inventory state supporting the decision has already changed. A payment mandate may be valid while the commercial conditions behind the transaction are no longer the same.

This is a second boundary.

The tool call and the decision that justified it are not the same thing.

Dimitrios S. Sfyris, senior software architect at AspectSoft and researcher, addresses this problem in his recent preprint, "A Decision-Centered Reference Architecture for Trustworthy Agentic Commerce," by treating the decision that authorises a consequential action as a first-class architectural object.

The architecture separates commercial eligibility, actor authority, checkout validity, payment dispatch, generated claims and evidence. It also introduces execution-time revalidation of dependencies so that an earlier decision does not silently survive a material change in the state on which it depended.

The principle is broader than commerce:

A decision can be correct when it is made and wrong when it is executed.

A valid decision belongs to the conditions under which it was made. If those conditions change materially, the system may need a new decision.

Consider a shopping agent that correctly concludes that a customer is eligible for a promotion. Between that decision and checkout, inventory, delivery destination, promotion eligibility or the authorised amount may change.

The original reasoning may have been entirely correct. It is simply no longer sufficient.

The same gap appears in ordinary business automation. The sequence-gate implementation checks whether the next step of a follow-up sequence should still fire: a payment reminder, an escalation to the next supplier, a text to a lead. The wait between steps is where the state can go stale. While the workflow sleeps, the debtor may pay, the supplier may accept or the contact may opt out. The gate reads the current signals before the next step and returns its decision with the reason and evidence it used.

This is why a record that says "the model chose tool X" provides only part of the evidence.

For consequential workflows, the system should also be able to answer:

What state supported the decision?

Which authority applied?

Which conditions were considered material?

Did those conditions still hold when execution occurred?

The model produces a proposal; the system carries responsibility for deciding when that proposal can cross into action.

The Model Proposes. The Code Disposes.

The same separation appears across the agent implementations discussed here.

The implementation philosophy is simple: "The model proposes, the code disposes." The web-pilot project applies it to browser automation through a closed action vocabulary, domain constraints, restrictions around credential and payment fields, a step budget and an execution trace.

The point is larger than browser automation.

Models are good at interpreting natural language and choosing among possibilities.

Code is good at enforcing invariants.

A mature agentic architecture uses each for the work it does best.

A model can decide that opening a page is the next sensible step; deterministic code can decide whether the destination belongs to the permitted domain.

A model can propose filling a form; the execution layer can refuse fields the application has decided the agent should never populate.

A model can choose a refund tool; a schema can validate the arguments, while a policy layer decides whether the operation needs approval.

The model remains useful precisely because it does not have to carry all of these responsibilities itself.

The useful middle ground is neither fixed workflows for every case nor unconstrained model improvisation:

Probabilistic reasoning inside deterministic boundaries.

Tool protocols such as MCP make this separation even more important.

A tool protocol does more than give models more things to call. It creates a modular operating environment in which capabilities can be discovered and composed, making tool metadata, permissions, schemas and execution policy part of the agent architecture.

Execution Has Memory

Once agents produce real side effects, familiar distributed-systems concerns become part of the AI workflow.

Distributed workflows fail in ordinary ways: processes stop, networks time out, workers restart and messages arrive twice. An external service may even complete an action before the acknowledgement reaches the caller.

Agentic workflows inherit those conditions.

Suppose an agent issues a refund. The external payment service accepts it, but the process terminates before the workflow records the result. When the system resumes, what should happen?

The agent should not have to reason its way out of this ambiguity from scratch. The execution architecture should already have an answer.

Recovery is part of the action, not something that happens after it.

The langgraph-production reference implementation is built around exactly this layer. It combines routing evaluation, human gates before irreversible tools, single-use approvals, durable workflow state, idempotent effects, crash-and-resume testing and explicit handling for states where the local system cannot determine with certainty whether an external effect occurred.

The project is careful about its scope. It uses synthetic data, an offline stand-in rather than claims about a live production model, and SQLite for the durability story. That limitation is part of its value: the repository demonstrates control-flow properties without presenting a reference implementation as production evidence.

Retries Belong to the Business Workflow

If the operation is read-only, retrying may be straightforward. If it issues a refund, places an order or sends a customer message, retry semantics can change the business outcome. Idempotency is therefore not merely an infrastructure optimisation; it expresses the intended meaning of repeated execution.

The question becomes:

If the same intended action is presented again, should the outside world change again?

Identity Should Survive Representation Changes

An agent may represent the same amount as 4500, "4500" or another equivalent form.

If deduplication operates on raw model output rather than normalised business arguments, superficial variation can make the same intended action appear different.

The action identity should therefore be derived from the meaning of the operation, not the incidental syntax generated by the model.

Some Uncertainty Should Remain Explicit

Distributed systems cannot always reconstruct the outside world from local state. A payment service may have completed an operation at the precise moment the local process stopped.

A mature system does not need to invent certainty. It can mark the effect as unresolved and route it for reconciliation, representing what it actually knows rather than pretending the ambiguity has disappeared.

A related revenue-loop implementation applies the same rule to measurement. It sends closed deals from a CRM back to advertising platforms under one guarantee: a conversion is uploaded exactly once, attributed to the campaign the lead actually came from, or quarantined with the reason named. It never invents an attribution identifier to fill a gap. The repository is explicit about its own limits in the same spirit: both platforms are modelled as offline fakes of their documented behaviour, and no live advertising account stands behind it.

Durable execution is not about making failure disappear. It is about making continuation well defined.

Human Involvement Is Part of the Routing Logic

As agents become capable of completing longer workflows, human involvement does not disappear; it becomes more selective.

The simplest human-in-the-loop design inserts approval before every important action. That can work at low volume. At scale, the more interesting question is which actions deserve human attention.

A reviewer asked to approve everything is not necessarily exercising more judgment; they may simply be processing a queue.

The confidence-gate project approaches the problem by treating human review as one possible routing outcome. Instead of relying on the model's own statement of confidence, the gate uses external signals such as structural validity, grounding and stability across repeated samples, then routes the result toward automatic acceptance, human review or abstention.

The principle is broader than that implementation.

Human-in-the-loop describes a location in a workflow. It does not guarantee meaningful judgment.

The better question is what it is about this case that makes human judgment valuable.

The answer might be the financial amount, novelty, a conflict between sources, missing evidence, a state change after the original decision, disagreement across repeated model runs, or simply company policy reserving a class of decisions for people.

The important part is that escalation has a reason that can be evaluated: did the system send the right cases to humans, avoid unnecessary review, and provide enough evidence for reviewers to understand what they were approving?

The same principle appears in langgraph-production, where unnecessary stops are measured rather than treated as automatically desirable. The point is practical: a review mechanism that interrupts everything eventually becomes part of the normal workflow rather than a meaningful decision boundary.

Human involvement works best when the system knows why it is asking.

Reliability Is More Than One Correct Run

Agent demonstrations are naturally narrative: the system receives a goal, chooses tools and completes the workflow. The result is persuasive because the whole chain can be watched from beginning to end.

Production asks a less cinematic question.

What happens when the same task is run again?

Language models introduce variation, and a multi-step agent adds several places where that variation can influence the trajectory. Evaluation therefore cannot stop at demonstrating that the system is capable of succeeding; it has to measure how behaviour distributes across repeated attempts.

The bedrock project approaches this with a stability harness around a natural-language-to-SQL agent. Each question is run multiple times against a defended answer key, unstable cases are surfaced, and a CI gate can block a candidate when reliability regresses.

SQL is only the test case. The reliability problem is broader.

Capability asks whether the agent can succeed. Reliability asks how often the same conditions produce an acceptable result.

This matters especially when the output becomes an action.

If a system occasionally formats a paragraph differently, the variation may not matter.

If it occasionally selects a different refund amount, it does.

Agent evaluation therefore needs to follow the consequence.

Did the system choose the correct route?

Did it choose the correct tool?

Were the arguments correct?

Was human escalation triggered when required?

Did the same business input produce materially different actions across runs?

Did the workflow recover correctly when interrupted?

This makes evaluation part of software delivery, not a post-deployment dashboard.

A model, prompt, policy or workflow change can be treated as a candidate release. If an important metric regresses, the build can fail before the change ships.

Across these projects, the pattern is consistent: evaluation is attached to the software lifecycle through explicit gates.

That approach makes agent reliability look less like magic and more like engineering.

Two Sides of the Same Boundary

Our work reaches the action boundary from different directions.

The decision-centered architecture for agentic commerce begins with the question:

What has to remain true for this action to still be justified?

The execution and reliability work begins with another:

What has to remain enforced for this action to execute correctly?

The first leads to commercial eligibility, actor authority, decision dependencies, generated claims and execution-time revalidation.

The second leads to permission-aware access, deterministic tool boundaries, human gates, durable state, idempotency and repeated-run evaluation.

One architecture establishes why the action is justified. The other carries the controls needed to preserve that justification through execution.

The questions meet at execution. A system should not execute merely because the model produced a plausible action.

It should execute when:

• the actor has authority;
• the relevant decision remains valid;
• the tool is permitted;
• the arguments satisfy the contract;
• required human judgment has been obtained;
• and the execution layer knows how to record, resume or reconcile the effect.

This is where agentic architecture becomes more than orchestration.

It becomes an architecture of delegated action.

Tools Expand the Operating Environment

Agent systems increasingly depend on tools and services developed outside the immediate application. Protocols such as MCP make those capabilities more composable.

An enterprise agent can retrieve data from one system, call a service in another, update a third and pass the result into a further workflow. That modularity can accelerate development, but it also means the agent's operating environment is larger than the model and its prompt.

Tool schemas, identity propagation, permission scopes, version changes and the semantics of external side effects all become part of the architecture.

The architecture therefore needs to describe not only model behaviour, but how capabilities enter the system and under what conditions they become executable.

The same pattern appears in permission-aware retrieval, where entitlements are applied before ranking rather than inferred by the model. In tenant-fence, the entitlement filter runs before any candidate is scored, so a document from another tenant never becomes a candidate at all.

The model is part of a larger machine, and that is a strength: not every requirement has to be solved by making the model smarter.

What Should Be Recorded?

As agents perform more of the path between a request and an outcome, auditability becomes easier to define if we stop asking for a transcript of everything.

The useful question is:

What evidence would we need to reconstruct the consequential decision?

That may include:

• the initiating principal;
• the relevant authority;
• the decision that was made;
• the dependencies on which it relied;
• the tool and arguments selected;
• the human decision, if one occurred;
• the execution identity;
• the external result;
• and the recovery or reconciliation state.

This is more useful than preserving an unlimited amount of model text without structure.

A model can later generate an explanation of why it believes it acted.

That explanation is still generated text.

The stronger record is the state that actually governed execution.

In decision-centered agentic commerce, this appears as protected decision state and execution-time dependency checks.

In execution-oriented implementations, it appears as approval ledgers, stable action identities, effect records, traces and reconciliation state.

The implementations differ, but the principle is the same.

Evidence should follow the action.

What Changes for the Organisation?

The technical architecture eventually changes the organisation around it.

If an agent can retrieve information, interpret a request, prepare a decision and execute bounded actions, then some workflows no longer require a person to carry every intermediate step.

The human work does not simply disappear; some of it moves. People still define what authority can be delegated, which state is decision-relevant, which tools require review, how unresolved execution is handled, what acceptable reliability means, and when a new capability should receive broader permissions.

This makes the economics of agentic systems more interesting than the cost of a model call.

A company may reduce some manual execution while adding work around integration, evaluation, observability, exception handling, identity, workflow design and maintenance.

The balance will differ by organisation, as will the effect on jobs and compensation.

It would be premature to reduce that change to a single prediction about how many roles agents will replace.

A more useful question is what kind of work remains scarce.

As routine execution becomes easier to automate, value may shift towards defining policy, designing controls, resolving exceptions, validating evidence and taking responsibility for decisions that cannot be reduced to a stable rule.

Agentic AI may therefore change not only who performs a task, but where judgment enters the workflow.

Autonomy Is Configured

It is common to describe an AI model as autonomous.

In an enterprise system, autonomy is more useful to think of as a property of the whole architecture.

The same model can sit in several environments: one may allow drafting only; another may permit retrieval or read-only tools; another may allow bounded execution; another may continue automatically unless policy, confidence or state change routes the case to a person.

The intelligence may be identical.

The operational autonomy is not.

It is produced by permissions, tools, limits, human gates, workflow state and execution policy.

This is why improved model capability does not automatically imply increased authority.

A new model release may reason more accurately. That is a reason to evaluate it, not an automatic reason to broaden its permissions.

Autonomy is not discovered in a model. It is configured by the organisation around it.

The Company Still Defines the Boundary

Agentic AI is making software more capable of participating in work rather than merely supporting it.

That is the important development.

The model can interpret, plan, choose tools, recover context and coordinate several steps. Increasingly, it can produce outcomes in systems outside itself.

This does not make architecture less important.

It makes architecture visible.

The company still decides whose authority an agent can exercise, what state makes an action valid, which proposals become executable, what requires human judgment, and how effects survive interruption and reliability is measured over time.

Those decisions do not constrain agentic AI from becoming useful.

They are what allow useful autonomy to expand.

A capable agent can do more.

A well-designed agentic system can determine when doing more is appropriate.

When AI speaks for the company, the company owns the words.

When AI acts for the company, the architecture determines how capability becomes authority.