From Answering to Acting: What AI Agents Need That Chatbots Don’t

Most organisations arrived at agents by extending what already worked. The assistant that answered questions well was given the ability to update a record, raise a request, send a message. The controls came along unchanged — the same identity, the same access, the same review process.

They don’t cover the gap. A chatbot that gets something wrong produces a bad answer, and a bad answer can be questioned before anyone acts on it. An agent that gets something wrong produces a changed record, a sent email, a closed case. Everything downstream of that difference — identity, permissions, audit, oversight, testing — changes in kind, not degree.

Most organisations arrived at agents by extending what already worked. The assistant that answered questions well was given the ability to update a record, raise a request, send a message. The controls came along unchanged — the same identity, the same access, the same review process.

They don’t cover the gap. A chatbot that gets something wrong produces a bad answer, and a bad answer can be questioned before anyone acts on it. An agent that gets something wrong produces a changed record, a sent email, a closed case. Everything downstream of that difference — identity, permissions, audit, oversight, testing — changes in kind, not degree.

---

The assertion/action line

The useful distinction isn’t chatbot versus agent as capability tiers. It’s assertion versus action.

A read operation borrows a person’s permissions, produces a claim, and ends with the session. The person is present, the output is visible, and someone can disagree with it before anything happens. A write operation creates a state change that outlives the session and often outlives anyone’s memory of having authorised it.

The same agent design shows up across every sector with the same shape. An agent that drafts a purchase order and one that raises it are different systems. An agent that identifies duplicate customer records and one that merges them are different systems. An agent that recommends a payment and one that releases it are different systems. In each pair the model may be identical, the prompt nearly identical, and the retrieval identical. What differs is the action surface — the set of things the agent is actually permitted to do — and that surface, not the model, is what determines the controls the system needs.

Most of the difficulty organisations hit with agents comes from never having written that surface down.

---

What changes when AI acts

Six requirements that a read-only assistant either doesn’t need or gets for free.

1. Identity and authority

Every action needs an actor attached to it. Not a log line saying the automation ran, but an identity that answers the question on whose authority did this happen.

There are two defensible patterns and they behave differently. An agent running under delegated user identity acts as the person who triggered it, inherits their permissions, and produces a record that ties the action to a human. An agent running under its own workload identity acts as itself, which is the only option for scheduled or event-driven work where no human is present at execution time, and which means the authority has to come from somewhere else — a designated owner, an approved purpose, a scope defined in advance.

In practice this is a design decision made early, not a configuration setting adjusted later. In Microsoft Entra ID it resolves to whether the agent uses on-behalf-of flow or a workload identity with its own app roles, and the two produce materially different audit trails. Deciding it late usually means deciding it by accident.

Antipattern: one shared agent identity used across multiple use cases. Every action traces back to the same principal, so no action can be attributed to a purpose, and any attempt to scope permissions has to accommodate the union of everything the agent does anywhere.

2. Standing permissions and blast radius

A chatbot’s exposure is bounded twice over: by the session, and by the person sitting there watching it. Neither bound applies to an agent running on a schedule at two in the morning. It holds standing access and there is no witness.

That makes least privilege the primary control rather than general hygiene. The permission set has to be scoped to the action surface — the specific operations on the specific data the agent needs — and it has to be reviewed when that surface changes, which it will, because agent scope creeps faster than almost anything else in a platform.

Scoping alone isn’t containment, though. What bounds an agent at runtime is the set of limits around it:

• Spend and rate limits, so a retry loop or a malformed instruction can’t run for six hours before anyone notices.
• A kill switch that works mid-run, not one that prevents the next scheduled execution. Revoking the identity should stop work in flight.
• Idempotency on every action, so a retried step doesn’t send the message twice or apply the adjustment twice. Agents retry constantly; systems built for human-paced input often assume they don’t.
• Volume ceilings per run, which is the cheapest possible protection against the failure mode where the agent is behaving exactly as designed against data that turned out to be wrong.

Antipattern: provisioning the agent with an existing service account because it already had the access. Those accounts are almost always over-permissioned — nothing had ever exercised the full grant, so nobody had reason to trim it. The agent is the first thing to exercise it, at machine speed, with no ceiling.

3. Reversibility as a first-class design axis

The taxonomy that matters for agents isn’t a risk tier. It’s whether the action can be undone.

Drafting a letter is reversible. Sending it is not. Flagging a case for closure is reversible. Closing it is not. Proposing a refund is reversible. Transacting it is not. The distinction is sharper and more useful than “high risk” or “medium risk”, because it maps directly onto an architectural decision: where the irreversible step sits, and what stands in front of it.

This is the single highest-leverage design choice in an agent system. An agent with a large reversible surface and a narrow, well-guarded irreversible one can be given real scope safely. An agent where the two are fused has to be constrained everywhere, which usually means it’s constrained into uselessness or shipped without the constraint.

Antipattern: pilots that collapse propose and execute into a single step because the demonstration is cleaner that way. The demo is the thing that gets approved, and the approval carries the fused design into production.

4. The decision record

Lineage answers where did this number come from. It’s the right artefact for analytics and it isn’t sufficient here.

An agent needs a record of what it did: the inputs it retrieved, the conclusion it reached, the action it took, the identity it acted under, and the time. That record has to be durable independently of the system that produced it — the model will be swapped next quarter, the prompt will be edited next month, and neither should erase the account of a decision made in between. A system prompt in a deployment config is not documentation of something that happened six months ago.

Where this lands matters. Azure AI Foundry gives you the agent’s tool definitions and traces at runtime; the durable record belongs somewhere it can be retained on your terms and queried later, which for most organisations means writing it into the data platform alongside everything else. In Microsoft Fabric it becomes a curated asset with its own retention and its own owner, versioned separately from the agent that generated it. It is, in the vocabulary of a medallion architecture, a new class of Gold table — not a log.

Antipattern: relying on application logs. They’re retained on an infrastructure schedule, they capture calls rather than reasoning, and they’re the first thing to be rotated away when storage gets tight.

5. Consistency of path

Two materially identical inputs should produce the same action.

Variation that is harmless in a summary becomes a defensibility problem when the output is an outcome. If one customer’s request is approved and an equivalent one is declined because retrieval returned a different chunk, or tool selection went a different way on a warmer sampling setting, that is not a quality issue to be tuned later. It is the system behaving unfairly, and it is very difficult to explain after the fact.

The contributing factors are usually treated as separate concerns and are really one: sampling temperature, non-deterministic tool selection, and retrieval drift as the underlying index changes. Agents that take actions should be evaluated on consistency across equivalent inputs, not only on accuracy against a test set — and equivalent inputs have to be constructed deliberately, because they rarely occur naturally in evaluation data.

6. Oversight that functions

The approval step is the control everyone points to and the first one to degrade.

At low volume, with clear reasoning presented and time to consider it, human review is a genuine control. At high volume, with no visible reasoning and no realistic ability to decline without stopping the work, it becomes a rubber stamp — and a rubber stamp doesn’t make a decision non-automated. It only makes it harder to see that it was.

If oversight is the control the design depends on, it has to be built as one:

• The reasoning behind the proposed action has to be reviewable, not just the action itself.
• The volume has to be achievable by the number of people actually assigned to it.
• There has to be a genuine reject path that doesn’t create more work than approving would.
• Approvals should be sampled and audited, because a 100% approval rate is a signal about the control, not about the agent.

Antipattern: treating human-in-the-loop as a compliance answer rather than a design constraint. It appears on the architecture diagram, it satisfies the review, and it never functions.

---

Why this is a data problem, not just an agent problem

Every requirement above assumes the agent is operating on data whose terms mean one thing.

A curated Gold layer was built to serve as the contract of meaning for explanation: when a model produces a number, the organisation can point at an agreed definition behind it. Agents need that same contract for execution, and execution is a higher bar. A definition that’s consistent enough to report on is not automatically correct enough to act on. “Overdue”, “eligible”, “inactive”, “resolved” — each can be stable across every dashboard in the business and still be wrong as a trigger for an irreversible action, because reporting tolerates a margin that transacting does not.

The controls also inherit from the platform beneath them rather than being reimplemented in the agent. When Microsoft Purview classifications and sensitivity labels are applied at the data layer, an agent reading from governed assets inherits them; an agent reading from a folder of exported documents inherits nothing, and every protection has to be rebuilt inside the application, where it will drift. Foundry’s tool definitions make the action surface explicit and reviewable, which is only meaningful if what those tools read is itself governed.

The order of operations is the same as it has always been. What changes is the consequence of getting it wrong: an ungoverned foundation used to produce an indefensible answer. Now it produces an indefensible act.

---

The economic argument

The cost of an agent programme isn’t tokens.

It’s rebuilding the same substrate for each use case — a new identity model, a new action surface, a new set of runtime limits, a new approach to retaining decision records — because the first agent was built as a project rather than as an instance of a pattern. Each subsequent agent then costs roughly what the first one did, and carries its own audit gap.

Organisations that build the substrate once see the opposite curve. The identity pattern, the propose/execute split, the decision record schema, the approval tooling and the runtime limits are common infrastructure. The second agent is mostly a new action surface on top of it, and the fifth is a week’s work. This is the same portfolio effect that curated data layers produce, applied one level up, and it shows up in the same place: not in the pilot, which will look fine either way, but in whether there is a second and third agent in production a year later.

---

Signals your organisation is (or isn’t) agent-ready

Positive signals

• There is an inventory of the actions each agent can take, split by whether they can be undone, with a named owner against each.
• Agent identities are scoped per use case, and the permission grant matches the action surface rather than exceeding it.
• Decision records are retained in the data platform, independently of the model and prompt that produced them.
• Approval steps have measured decline rates, and someone looks at them.
• Agents read from governed, curated assets rather than from exports.

Warning signs

• Multiple agents sharing a service account, or an account inherited from something else.
• Nobody can list what an agent is permitted to do without reading the code.
• Human-in-the-loop with a 100% approval rate, or with no measurement at all.
• Propose and execute are the same call.
• The only record of an agent’s actions is in application logs, on the platform’s default retention.
• Retrying a failed run is understood to be unsafe, and is handled by someone checking manually first.

---

Bottom line

The move from answering to acting is not an increment in capability. It is a change in what the system is, and it brings requirements that read-only assistants never had to satisfy: an actor on the record, permissions scoped to a defined surface, a deliberate split between what can and cannot be undone, a durable account of each decision, consistency across equivalent cases, and oversight built to function rather than to appear.

Before any agent goes to production, one artefact is worth more than a policy document: the list of actions it can take, split by what can be undone, each with a named owner. It takes an afternoon. If it can’t be produced, the agent isn’t ready — however well the demonstration went.