An agent is a language model inside a controlled loop. The decision "agent or workflow?" was never a question about architecture — it was a question about trust in the runtime. With deterministic execution, it goes away.
The definition, without magic
In two years, "agent" has gone from technical term to sales pitch. In many conversations the word now covers everything between a chatbot with a system prompt and a distributed system that moves money on its own. For companies bringing AI into regulated processes, that blur is expensive: if you cannot say what an agent is, you cannot say which controls it needs.
So here is the sober version:
An agent is a software system that embeds a language model in a repeated decision-and-execution cycle.
The model makes decisions. The surrounding system executes them, validates them, records them, and decides whether the loop continues. That is the most important sentence in this article: the model is a component, not the system.
The loop itself is unspectacular:
Goal → Model → Action → Observation → State → Repeat
- Goal and context. The model receives a goal, the state so far, and the available tools as a typed schema.
- Decision. The model formulates an action. It executes nothing — it expresses an intent.
- Validation and execution. The runtime validates the call, checks it against permissions and budgets, and executes it. That is deterministic code, not model discretion.
- Observation. The result — success, error, partial result — is written back into the state.
- Next turn. Until the goal is reached, a budget triggers, or a human has to decide.
A workflow is the counterpart: models and tools orchestrated through predefined code paths. The path is fixed before the first call happens. An agent steers its own path; a workflow has its path handed to it.
The old decision table
Until recently, one of the field's most-cited rules of thumb rested on this distinction — Anthropic formulated it cleanly in Building effective agents, and we passed it on ourselves:
| Situation | Standard advice | |---|---| | The path is known and stable | Workflow | | The number of steps is predictable | Workflow | | Process and controls must be validatable and repeatable | Workflow | | The path depends on intermediate results | Agent | | The process must handle unstructured exceptions | Agent |
The logic behind it: an agent buys flexibility and pays with predictability. In regulated processes that was the wrong trade — so, workflow.
As a description of the 2024 tooling landscape, this table is correct. As an architectural principle, it is not. Because the third row — validatable and repeatable — does not describe a property of agents. It describes a property of the runtimes agents have been operated in.
Why the trade-off existed
What made an agent "unpredictable" was never the loop. It was the environment:
- Unpinned model versions. The same prompt hits a silent model update next week.
- Unrecorded context. What the model actually saw in turn 7 cannot be reconstructed afterwards.
- Unrecorded tool state. The API answered differently yesterday than today — which state applied during the run?
- Budgets and permissions as suggestions. Phrased in the system prompt instead of enforced at runtime.
The workflow was validatable because its code path was fixed. The agent was not, because its execution was never captured in a form that constitutes evidence. That is not a law of nature. That is an implementation status.
It is worth noting what regulation actually demands: rarely bit-identical outputs, but that process, controls, data lineage and decisions are traceable, validatable and repeatable. The workflow recommendation was never "agents are forbidden." It was: "agents currently cannot prove this."
Deterministic execution changes the math
This is exactly where we built. In the LumeSec AIOP, every agent turn runs in a runtime that guarantees four things:
- Everything is versioned. Model version, system prompt, tool contracts, policy state and settings are part of the recorded run — not metadata next to it.
- Everything is an event. Every context, every requested action, every check, every observation is deterministically serialized and captured as an event.
- Every run carries a trace hash. The hash over the deterministically serialized events. A replay of the same run produces the identical hash — replay-equivalent, not merely "a similar result."
- Every event is signed. Ed25519, append-only, owned by the customer. Auditors verify a chain, not a narrative.
Permissions and budgets attach to the turn, not to the agent, and are enforced at runtime. Human-in-the-loop is a property of the loop, not an after-the-fact review.
With that, an agent has exactly the properties the table reserved for workflows: its execution is reconstructible, its controls are provable, its run is repeatable — under proof. And the workflow loses nothing: in the same environment, a workflow is simply an agent with zero degrees of freedom. Both run under the same audit contract.
The question that remains
The decision "agent or workflow?" is no longer a governance decision. It has become a design question: how much freedom does this process need?
- A stable, known path gets zero degrees of freedom — it runs as a fully predefined sequence.
- A process with unstructured exceptions gets room to move — inside runtime-enforced permissions, budgets and termination conditions.
- Both produce the same signed, replay-equivalent evidence.
You no longer choose between control and flexibility. You set a dial — and the evidence stays constant.
Honesty requires one boundary: determinism here means replay equivalence — same inputs, same trace hash, across versions, regions and time. It does not mean a model responds to new inputs like a lookup table. New cases still produce model judgment. The difference: every one of those judgments is bounded, budgeted, signed, and reconstructible step by step. That is the property auditors actually require — and until now, it was the reason to keep agents out of regulated processes.
A chat window does not make an agent. A loop does not make a system you can put into a regulated process. And a decision table built on distrust of the runtime does not survive the runtime that makes the distrust obsolete.
Predictable AI. Built for Enterprise.
Sources
- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022 (arXiv:2210.03629) — reasoning and acting in one loop.
- Anthropic, Building effective agents, Engineering Blog, 2024-12-19 — the distinction between workflows with predefined code paths and agents that steer their own execution.
- OWASP GenAI Security Project, Top 10 for LLM Applications, 2025 edition — LLM01 Prompt Injection, LLM06 Excessive Agency, LLM10 Unbounded Consumption.
- Russell & Norvig, Artificial Intelligence: A Modern Approach — the classical agent definition.