AI agents need operational thinking, not only better prompts

The public conversation around AI agents is still dominated by models, benchmarks and tools. Which model reasons better? Which coding agent can use a terminal? Which framework can connect the largest number of tools?

Those questions matter, but they are not where most agentic systems succeed or fail.

The difficult part begins after the first impressive demo, when an agent meets a real application, real permissions, incomplete documentation, inconsistent data, financial limits and a process that was never designed to be automated.

At that point, a better prompt is useful, but it is not an operating model.

The demo is the easy part

A demo usually has a clean starting point, a visible objective and a human watching every step. If the model makes a mistake, the human corrects the prompt and tries again. The unsuccessful attempts disappear from the final presentation.

Production does not offer that luxury.

A production agent may run when nobody is watching. It may receive an ambiguous request, call an unreliable service, modify persistent data or start several expensive branches of work. It needs to know when to retry, when to stop and when the correct action is to ask for help.

This is why I find the distinction between an agent and a workflow useful. Anthropic describes workflows as systems that orchestrate models and tools through predefined paths, while agents dynamically decide how to use their tools and complete a task. The more freedom we give an agent, the more operational responsibility moves into the system around it.

Autonomy does not remove process. It makes the quality of the process more consequential.

Instructions are part of the architecture

We often use the word prompt as if it were a clever paragraph placed before a request. In a serious agentic system, the instructions are closer to executable policy.

They define:

• the role the agent is performing;
• the evidence it must collect before acting;
• the tools and data it may access;
• the changes it may make without approval;
• the conditions under which it must stop;
• the checks required before it can claim success;
• the format in which it hands work to another agent or a human.

The model remains probabilistic, but its working environment does not have to be vague.

I saw this distinction while working on Project Mosaic, a game project, and while examining systems such as gstack. They are very different projects, but the useful lesson is the same: the result does not come from one magical prompt. It comes from accumulated guidance, explicit roles, review stages, constraints, artifacts and feedback.

The surrounding instructions are not documentation added after the system is built. They are part of the system.

Workflow matters more than model theatre

The temptation is to put everything into one context window and ask the strongest available model to handle the whole job. That works surprisingly often, which makes it easy to overlook how fragile it can be.

A better workflow decomposes the work where decomposition adds control:

intent
  → plan
  → bounded execution
  → evidence
  → review
  → approval or revision
  → release

Each transition is an opportunity to inspect state, validate assumptions or stop an error before it becomes a side effect.

This does not mean every task needs a committee of agents. Anthropic's guidance on building effective agents recommends simple, composable patterns and adding complexity only when it improves measured outcomes. A direct model call may be the correct architecture. A deterministic script may be better than any model. A fixed workflow may be safer than an autonomous agent.

Operational thinking includes knowing when not to use an agent.

Parallelism is leverage, not a default

Parallel agents are attractive because the speedup is visible. Research, implementation, testing and review can sometimes proceed at the same time. Several independent perspectives can also find problems that one long-running context misses.

But parallelism is valuable only when the work can be divided cleanly.

Every parallel branch adds coordination cost. Agents may inspect the same files, make incompatible assumptions, duplicate research or produce outputs that cannot be merged. If the original goal is unclear, parallelism does not clarify it. It allows several interpretations of the same ambiguity to run simultaneously.

Before parallelizing a task, I want four things to be explicit:

1. What unit of work does each agent own?
2. Which state may it read or change?
3. What artifact must it return?
4. Who or what decides whether the results are compatible?

Without those contracts, multiple agents are not a team. They are concurrent uncertainty.

The financial effect matters too. A workflow that is twice as fast but launches eight expensive model calls may be a poor optimization. Speed, quality and cost have to be evaluated together.

Observability has two planes

Traditional applications taught us that a green status indicator is not enough. We need logs, metrics and traces to understand what happened across a distributed system. Agentic systems add another layer: we must understand not only whether a request completed, but how the system reached its conclusion.

I think of this as two connected planes of observability.

The first is execution and semantic observability:

• which instruction and prompt version were active;
• what context and retrieved data were supplied;
• which model and tools were selected;
• what actions and external calls were attempted;
• where retries, refusals and failures occurred;
• which evaluations and human approvals were applied;
• what evidence supported the final result.

The second is financial observability:

• input and output tokens per step;
• cost by model, tool, task and user;
• latency and cost introduced by retries;
• parallel fan-out and work that was later discarded;
• cost per successful, accepted outcome rather than cost per API call;
• budget thresholds that slow, reroute or stop execution.

These cannot be separated for long. A cheap workflow that repeatedly produces unusable work is expensive. An accurate workflow that spends without a limit is not operationally safe.

The emergence of OpenTelemetry conventions for generative AI is a useful sign of where the engineering is heading: agent operations increasingly need common spans, metrics and events, not screenshots of a chat window.

Observability is not there to produce a prettier dashboard. It creates the evidence needed to debug, evaluate and improve the system.

Learning requires a closed loop

People often call any self-improving AI workflow reinforcement learning. That is understandable, but technically too broad.

Formal reinforcement learning updates a policy through reward signals. Most practical agent workflows are doing something simpler and still extremely valuable: capturing operational feedback and feeding it into future runs.

run
  → observe
  → evaluate
  → record a failure or useful pattern
  → update the instruction, tool or process
  → replay against known cases

I would call this an operational learning loop or continuous evaluation loop. The name matters less than closing it.

If a reviewer repeatedly catches the same missing check, the system should not depend on somebody remembering that lesson in the next chat. The check can become a test, a validation rule, a tool constraint or a durable instruction. gstack, for example, records structured operational learnings from sessions and makes them available to later workflows. The model itself may be unchanged while the system around it becomes better adapted to the project.

This is the same discipline we apply to other applications: incidents create runbooks, defects create regression tests and recurring manual corrections become validation rules.

An agentic system that forgets every failure is not learning. It is merely retrying with confidence.

Human judgment is a control, not a failure

There is a tendency to measure progress by how completely the human can be removed. I think that is the wrong objective for consequential work.

The useful question is where human judgment has the highest leverage.

A human should not have to supervise every tool call. But changing production access, deleting data, accepting a security risk, publishing externally or deciding between materially different product directions may deserve an explicit gate. The agent can prepare evidence and recommend an action without owning the final decision.

Good approval points are specific. They explain what will happen, what data or system is affected, what was verified and how the action can be reversed. A generic “Are you sure?” after a long opaque run is ceremony, not control.

AI cannot rescue a broken process

This is the least glamorous and most important part.

If an application has unclear ownership, contradictory requirements, poor tests and no reliable deployment process, adding AI does not repair those weaknesses. If the underlying business process contains unnecessary steps or ambiguous decisions, an agent will inherit them.

Put brutally: shit in, shit out.

AI can make the output arrive faster, at a larger scale and with more convincing prose, but it cannot make a broken process coherent simply by participating in it. In some cases it makes the original problem harder to see because the system continues moving instead of failing loudly.

Before automating a process, we should still ask the old engineering questions:

• Is the objective clear?
• Is the input trustworthy?
• Can success be measured?
• Are failure states understood?
• Is ownership explicit?
• Can consequential actions be reversed?

Only then does model capability become the multiplier we want.

The most durable agentic systems will not be the ones with the longest prompts or the largest number of agents. They will be the ones whose instructions reflect a sound process, whose actions are visible, whose costs are attributable and whose failures make the next run measurably better.

AI does not repair a bad process. It industrializes it.