Choosing Between Workflows and Agents
Agentic over-engineering is the pattern of adding agents, multi-agent designs, or orchestration frameworks where a simpler design would suffice.
A Feature With a Known Sequence
Imagine you are asked to build a feature that receives a document, extracts its fields, checks them against a rule, and saves the result. Every step is known before the system ever runs. Your first instinct might be to reach for something more sophisticated, such as an agent that decides what to do next. Before reading on, consider which kind of design you would expect to succeed more reliably in production.
What do you think happens?
For a task whose sequence of steps is already fully known, which design would you expect to succeed more reliably in production: a fixed workflow or an agent?
Reveal answer
A fixed workflow.
The source states that the simpler design wins in production almost every time, and that an agent should be used only when the path is genuinely unknowable in advance. When the steps can be written down ahead of time, a workflow is the right starting point.
The Belief That Complex Designs Are Better
A common instinct among people building AI products is that a more sophisticated architecture signals a more capable solution. An agent sounds more advanced than a fixed sequence of steps. A team of cooperating agents sounds more advanced than one agent. An orchestration framework sounds more professional than a handful of direct calls to a model API. This instinct is the misconception this article addresses: the belief that complex designs are always better.
The source treats this instinct as a real and recognizable failure pattern, which it calls agentic over-engineering. Agentic over-engineering is the pattern of adding agents, multi-agent designs, or orchestration frameworks where a simpler design would suffice. The practical point is that extra machinery is not free. Every added component brings its own ways to break, and in production those costs usually outweigh whatever the extra sophistication was supposed to buy.
Agentic over-engineering is the pattern of adding agents, multi-agent designs, or orchestration frameworks where a simpler design would suffice.
Tracing Who Decides the Next Step
The clearest way to see the difference between a workflow and an agent is to follow the control flow. In a workflow, the designer fixes the order of the steps in advance. The system runs them in that sequence, and the next step is always known before the current one finishes. An agent works differently. It repeatedly chooses an action, carries it out, looks at the result, and decides whether to continue or stop. The model, not the designer, determines the next step at each point in the run.
Read the two columns as two different programs. The workflow column has a fixed path, so an engineer can check every branch before deployment. The agent column has no fixed path. Its behavior depends on what the model decides at each pass through the loop, which is exactly why an agent can only be justified when the path cannot be specified ahead of time.
The Ladder of Added Complexity
The source describes what unites the three forms of over-engineering: the direction of the escalation. The designer moves one step up a ladder of complexity without asking whether the task requires that step. The ladder runs from direct API calls, to workflows, to single agents, to multi-agent designs. Orchestration frameworks are additional layers on top of this stack rather than a separate rung.
- 1Direct API calls: the application sends requests to a model and uses the responses.
- 2Workflow: the designer fixes a sequence of steps, and the model participates within that fixed order.
- 3Single agent: the model chooses its own actions in a loop until it stops.
- 4Multi-agent design: several agents cooperate on the task.
- 5Orchestration framework: an additional layer added on top of the stack above.
The question to ask at each rung is whether the task truly needs that rung. Moving up feels like progress, but each step up adds machinery that must be built, run, and understood.
The Three Forms of Over-Engineering
The source describes agentic over-engineering as a pattern with three distinct forms. Each form escalates a design beyond what the task actually needs. The table below summarizes each form and the simpler design it should have used. The subsections that follow explain each form in turn.
| Over-engineered choice | Simpler design it should have used | Direction of escalation |
|---|---|---|
| Agent where a workflow would do | Workflow | Moves from a fixed sequence to a loop of model-chosen actions |
| Multi-agent design where a single agent would do | Single agent | Splits one task across several cooperating agents |
| Orchestration framework where direct API calls would do | Direct API calls | Adds layers between application code and the model |
The three forms of agentic over-engineering and their simpler alternatives
Why Extra Machinery Costs More Than It Gives
The source gives three reasons the over-engineered system is the weaker choice. Each reason is a cost that grows with every added component.
- Failure modes: each added agent, layer, or framework is another place where something can go wrong, so an over-engineered system has more ways to fail than a simpler one.
- Debugging: when an output is wrong, the engineer must trace the fault through every additional component, while a simpler design gives a shorter path from input to output.
- Approval and maintenance: every additional component is something a reviewer can question, which gives the customer's IT team a wider surface to object to.
Counting the Parts That Can Fail
Two designs both handle the same document feature. Design A is a workflow with two parts: an extraction step and a save step. Design B adds an agent that chooses whether to run the rule check, a framework layer between the code and the model, and a second agent that reviews the output. Which design has more places for a fault to hide?
- 1List the parts of Design A
Design A has two parts, so a fault can originate in either of the two steps.
- 2List the parts of Design B
Design B has five parts: the agent that chooses the check, the framework layer, the reviewing agent, and the two underlying steps.
- 3Compare the counts
Both designs may be built carefully, but Design B has more components where a problem can arise and more places to trace when an output is wrong.
Design B has more failure modes and more places to debug, even if each part is well built. This matches the source's point that a design with five moving parts has more ways to fail than one with two.
The Path-Known Test
The source does not say agents are always wrong. Its guidance is narrower: reach for an agent only when the path is genuinely unknowable in advance. The test is about the task, not about how impressive the agent sounds. If the designer can already write down the steps, a workflow is the right starting point. If the steps cannot be specified ahead of time because they depend on information the system only discovers as it runs, an agent becomes a reasonable choice.
Mistakes When Choosing a Design
Common mistake Choosing an agent because it sounds more capable
What it looks likeA team builds an agent for a document feature whose steps are fully known in advance.
Why it failsThe source ties the agent decision to whether the path is genuinely unknowable in advance, not to how advanced the design sounds.
Do this insteadWrite down the steps first. If they can be written down, start with a workflow.
Common mistake Assuming a task is unpredictable without checking
Why it failsMany tasks that feel open-ended turn out to follow a predictable sequence on inspection.
Do this insteadMake an honest check of the sequence before adding any agentic component.
Common mistake Adding a framework where direct API calls would work
What it looks likeAn application sends one request to a model and uses the response, but is wrapped in an orchestration layer.
Why it failsThe framework adds a layer between code and model without a capability the task needs.
Do this insteadStart with direct API calls and add a framework only if the task demands what it provides.
Common mistake Treating extra components as free, when each one adds failure modes and debugging work
Applying the Test to a New Task
A team wants a tool that takes a customer email, classifies it into one of four fixed categories, applies a routing rule for that category, and saves the record. Using the path-known test, decide whether this task calls for a workflow or an agent, and explain which step of the test your answer depends on.
Hints
- Ask whether every step can be written down before the system runs.
- Consider whether any step depends on information the system only discovers while running.
- If the answer is a workflow, check whether the design still needs an agent or framework layer.
Key Takeaways
- Agentic over-engineering means adding agents, multi-agent designs, or orchestration frameworks where a simpler design would suffice, and it can make a solution worse rather than better.
- The three forms are reaching for an agent instead of a workflow, a multi-agent design instead of a single agent, and an orchestration framework instead of direct API calls.
- Extra components bring more failure modes, more places to debug, and a wider surface for reviewers to object to.
- Reach for an agent only when the path is genuinely unknowable in advance. If the steps can be written down, a workflow is the right starting point.