Agentic systems need an operating model

Most agent demos show me what the agent can do. Fine.

First I want to know what it is allowed to do, how we prove what it did, and who owns the result when it gets weird.

An agent that can answer questions is a feature. An agent that can change an order, issue a credit, alter a price, or commit code is part of the operating model.

That distinction is the architecture.

Capability is not authority

A model may be technically capable of calling an API. That does not mean it should be allowed to call every operation exposed by that API.

The useful design question is narrower: what decisions may this agent make under which conditions?

A service agent might be allowed to explain an order status from trusted data. It may be allowed to start a return within a defined policy. A refund above a threshold may require approval. An address change after fulfillment starts may be prohibited entirely.

Those are not prompt details. They are business controls.

The authority model should be enforced outside the model wherever possible. Use scoped credentials, policy checks, transaction limits, idempotency rules, and approval steps. The model can propose an action. The system still decides whether that action is valid.

Give uncertainty somewhere to go

Agents will encounter missing data, conflicting policies, ambiguous intent, and cases nobody put in the demo. The system needs a defined response other than making something up.

That usually means three paths:

1. Complete the action when the evidence and policy are clear.
2. Ask for the specific missing information.
3. Escalate with enough context that a person can finish the work.

Escalation is not failure. An agent that knows where its authority ends is more useful than one that completes every interaction confidently.

The ugly version is an agent that hands the customer to a person after losing the conversation history. We already built that experience with chatbots. There is no reason to rebuild it with a larger model.

Audit the decision, not just the text

A transcript is useful, but it is not a complete audit record.

For a consequential action, I want to know:

• Which identity initiated the request?
• What data did the agent retrieve?
• Which policy and tool version were active?
• What action did it propose?
• What validation ran before execution?
• What changed in the system of record?
• Could the action be reversed?

This is especially important when agents cross commerce, CRM, payments, service, and fulfillment boundaries. The answer may be generated in one place while the consequence lands in four others.

If the organization cannot reconstruct that path, it does not have governance. It has a transcript and some optimism.

Ownership cannot be distributed into nothing

Agentic systems cut across normal team lines. Product owns the experience. Technology owns the integration. Security owns access. Operations owns the downstream process. Legal and finance may own parts of the policy.

That makes shared input necessary. It does not remove the need for one accountable owner.

Somebody should own the agent’s allowed outcomes, performance, exception rate, and change process. That person does not need to approve every prompt edit. They do need to know when the system is behaving differently and have authority to stop it.

Without that owner, incidents turn into a group investigation where everyone owns a component and nobody owns the behavior.

Start narrow enough to learn

The best first agent is rarely the one with access to everything. Pick a bounded job with real value, clear source data, reversible actions, and a manageable exception path.

Then measure the work the agent completed, the work it escalated, the interventions it required, and the errors that reached downstream systems.

That evidence should determine the next authority boundary.

The model will get smarter. Good. Now the company has to get better at deciding what that smarter thing is allowed to change.