The problem shows up afterwards, when finance asks which document the address was read from, why no manual check was requested, and who authorized the change before the next invoice went out: at that point, the agent's generated response is probably the least interesting part of the whole story.
In just a few months, AI agents have moved out of the AI team's notebook and into a far less comfortable vocabulary, made up of tool contracts, tracing, and human approval. LangChain captures this well in its 2026 State of Agent Engineering, where 57.3% of respondents say they already have agents in production, and among those, 94% have some form of observability, while 71.5% apply detailed tracing on steps and tool calls. It's a partial snapshot, but it says something precise: as soon as an agent touches a real process, someone in the company wants to see the receipt.
The limits of the "digital colleague" metaphor.
The "digital colleague" metaphor has had its uses, because it helps explain why an agent can read, search, decide the next step, use tools, and ask for clarification. In a product team, this image makes it easier to picture light delegations like triaging a ticket, drafting a reply, searching documentation, opening a pull request, or summarizing a retrospective.
It's a warm, intuitive metaphor that's easy to communicate, and it carries a technical merit that isn't obvious at first: it guards against the opposite excess of reducing every process to a form with mandatory fields and rigid states. If the work were already fully codifiable, a function or a scheduled job would do: agents earn their place precisely where context keeps shifting, sources are incomplete, natural language carries useful signals, and the business procedure lives across a mix of documents, messaging channels, people's memory, and old tickets.
This is where the metaphor breaks down, though: a colleague can explain themselves in the hallway, remember an exception discussed out loud, take on personal responsibility, while a software system has to leave a trail. The real enterprise leap for agents comes down to this point: the ability to proceduralize judgment. It's not about eliminating ambiguity — which is often exactly why an agent is needed in the first place — but about turning some ambiguous steps into sequences that are observable, interruptible, and improvable.
When an agent can stay simple, and when it can't.
An agent built for internal search can stay a single agent when the context is compact: one question, one set of sources, one answer with citations and a confidence level. Here reversibility is high, because if the summary is wrong it can be corrected, and the damage stays contained as long as it's clear which documents it read and which it ignored.
A customer support agent is already a different animal, because it can pull up orders, commercial policies, conversation history, and shipping status. If it only drafts a reply, the risk stays close to that of an editorial assistant, but if it sends the reply, applies a discount, or promises a replacement, the workflow moves straight into the company's finances and the customer relationship: the difference here isn't "more AI," it's a different level of operating permission.
Multi-agent: only useful when it genuinely reduces complexity.
Even the most recent frameworks move in this direction: OpenAI's Agents SDK distinguishes patterns like agents as tools and handoff, where in the first case a manager agent keeps control and calls specialists for sub-tasks, while in the second a triage agent passes the conversation on to a specialist that takes over.
That doesn't mean every project needs to turn into a multi-agent system: in fact, multi-agent setups are often an expensive way to shift ambiguity from a prompt instruction to a coordination problem. A "researcher" agent, an "analyst," a "reviewer," and a "writer" make for a working demo and a nice dashboard, but in production nobody can figure out which agent introduced the error or why two specialists read different sources.
Multi-agent setups make sense when specialization genuinely cuts down the noise — for example in the knowledge management of an enterprise group with legal policies, technical manuals, and commercial documentation: one agent can retrieve technical sources, another can check regulatory constraints, while an orchestrator decides whether the answer is ready or needs human review. Here, dividing up roles genuinely helps separate contracts, sources, and responsibilities.
The planning, execution, review cycle — and the role of human-in-the-loop.
The same principle applies to the planning, execution, and review cycle, useful when the plan produces a checkable artifact before any action is taken — as with an agent that states: "I'll search closed tickets from the last 90 days, compare them against the updated policy, and propose a reply without sending it." In AI-assisted coding, this step can translate into a list of files to change and tests to run, while in operations it can become a runbook with explicit checkpoints: read a metric, check a dashboard, open an incident, ask for confirmation before a rollback.
In this framing, human-in-the-loop stops being a brake imposed by a cautious company and becomes the point where the organization actually signs off. It's not needed everywhere, but it's needed wherever an action is hard to reverse — where it changes an entitlement, generates a cost, communicates a promise to a customer, or opens up a security gap.
Our approach: boundaries before prompts
For us at Moku, boundaries come before prompts: which tools exist, with what permissions, on what data, and with what logging. Before an agent's personality comes its operating contract, and before the demo comes the question every CTO will ask after the first incident — whether it's possible to reconstruct what actually happened.
This also brings a less visible organizational effect: agents force teams to write down procedures that used to live in informal steps — a private message to a senior colleague, a note in a ticket, an exception granted "just this once." When we codify an agentic workflow, we're effectively deciding which parts of business judgment deserve a defined form.
The risk of the workflow-based approach is real, because over-rigidifying an agent strips it of exactly the ability to handle unforeseen cases; the opposite risk, though, is costlier in production, because a system that looks flexible right up until someone has to explain its decisions to finance, legal, or security quickly becomes a liability.
In many processes, the next management interface might no longer have screens at all — but it will have tool contracts, policies, checkpoints, and approvals: the agent will talk, and the company will still need to be able to read the minutes.
