The demo is not the operating model
An agent demo can summarise a document, search a knowledge base and take an action in another system. That is enough to make the possibility visible. It is not enough to put the agent into the organisation.
Production questions arrive quickly. Which identity does it use? What may it see? Which actions can it take without approval? What does it remember, for how long and on whose behalf? How does a person inspect its reasoning and evidence? Who owns the workflow when the model, integration or source system fails?
These are not technical footnotes. Together they define the agent’s place in the operating model.
Give the agent a job
“General assistant” is rarely a useful enterprise responsibility. Start with a bounded job inside a workflow: prepare the evidence for a decision, reconcile a recurring set of records, draft a response using approved sources, coordinate a hand-off, monitor a condition or execute an authorised sequence.
The job should have an outcome, an owner, inputs, tools, decision rights, exception paths and a way to judge performance. Without those, the agent cannot be managed; it can only be admired or blamed.
Redesign the work before automating it
Existing processes contain historical workarounds, duplicated checks and hand-offs created by old system boundaries. Reproducing them in an agent makes the same process faster and less visible.
Map the actual decisions and evidence. Remove steps that exist only to route information. Decide where judgement is valuable, where a rule is sufficient and where an agent can assemble context or act. The target workflow may look materially different from the current process.
A chatbot attached to a broken process is still a broken process. It just replies faster.
Memory is a policy choice
Persistent memory makes an agent more useful because it can retain preferences, decisions, relationships and prior work. It also changes the risk profile.
Memory needs scope, provenance, retention, correction and deletion. The organisation must distinguish durable context from temporary working state, and a user’s memory from shared organisational knowledge. An agent should not turn every message into permanent truth simply because storage is cheap.
The same applies to retrieval. Access should follow the user, purpose and workflow — not the theoretical appetite of the model.
Autonomy needs explicit authority
Autonomy is not a personality setting. It is a bundle of permissions and stop rules.
For each action, decide whether the agent may observe, recommend, draft, execute with approval or execute independently. The threshold should reflect reversibility, sensitivity, financial or operational consequence, and the quality of available verification.
A calendar suggestion and a production deployment do not belong in the same approval model. Neither do reading a public report and disclosing a confidential one.
Operate the whole system
The model is one dependency among many. Enterprise agents also rely on prompts, policies, memory, retrieval, tools, credentials, integrations, schedules, queues, hosting and observability.
Operations therefore needs traces, cost and latency controls, integration health, evaluation suites, incident handling, versioned changes and a named owner. If the organisation cannot explain how the agent is monitored and changed, it is not ready to depend on it.
The executive choice
The strategic question is not whether agents can perform useful work. They can. The choice is which work deserves redesign, what authority the organisation is prepared to delegate and what operating capability it will build around that delegation.
Get those choices right and agents become part of how the enterprise works. Skip them and the organisation acquires a fleet of confident interns with root access.