“Agent” has become a convenient word for almost any software that includes a language model. A model writes an answer: agent. A pipeline calls two prompts: agent. A feature can search a database: agent. The word signals ambition, but it can hide the architectural decision that matters most: who controls the next step?
We do not think more autonomy is automatically more progress. At BorealBit, we build software around narrow, concrete problems. That leads us to a quieter position: begin with the smallest architecture that can solve the task reliably, and add autonomy only when the shape of the problem requires it.
This is not an argument against agents. It is an argument for giving them a precise job.
Workflow and agent are different promises
Anthropic’s Building effective agents gives us a useful distinction. In a workflow, models and tools follow control paths defined by code. In an agent, the model dynamically chooses its process and tool use. Both belong to the broader family of agentic systems, but they make different promises about predictability, cost, and control.
The article describes an augmented LLM as the basic building block: a model combined with capabilities such as retrieval, tools, and memory. It then presents five workflow patterns before describing the more autonomous agent loop.
| Pattern | Who controls the path? | Best fit |
|---|---|---|
| Prompt chaining | Code defines a fixed sequence of model calls | A task splits cleanly into ordered steps, with optional gates between them |
| Routing | A classifier selects a predefined specialist path | Inputs fall into distinct, reliably identifiable categories |
| Parallelization | Code runs known subtasks or repeated attempts together | Independent work can run faster in parallel, or several views improve confidence |
| Orchestrator–workers | A model defines subtasks inside a bounded orchestration pattern | The required subtasks vary by request, but delegation and synthesis remain explicit |
| Evaluator–optimizer | Code runs a generation-and-feedback loop | A clear rubric exists and critique produces measurable improvement |
| Agent | The model repeatedly chooses actions and tools from environmental feedback | The path and number of steps cannot be known in advance |
Prompt chaining can turn an outline into a checked draft and then into a finished document. Routing can send different request categories to prompts and tools designed for them; the router does not itself need to be an LLM if ordinary classification works. Parallelization can divide independent concerns or run several attempts for comparison.
Orchestrator–workers is often mistaken for proof that any multi-model system is an agent. Anthropic classifies it as a workflow. Its internal subtasks are dynamic, but the outer topology—delegate, collect, synthesize—is still deliberately bounded. Evaluator–optimizer is also not unlimited self-reflection. It works when the evaluation criteria are clear, useful feedback is possible, and the loop has a stopping rule.
An agent crosses a different boundary. It uses tool results or other facts from its environment to decide what to do next, potentially across many turns. That flexibility is valuable when a fixed route would be artificial or brittle. It also creates more places for cost, latency, and error to accumulate.
Let uncertainty determine autonomy
We find it more useful to classify uncertainty than to ask whether a product should “have an agent.”
If the output format varies but the steps are known, a workflow is usually enough. If the input category is uncertain, routing may be enough. If the task decomposition varies while the outer process remains stable, an orchestrator can assign workers. Full agent autonomy becomes relevant when the next useful action depends on facts that only emerge during execution.
This distinction protects deterministic software from being replaced without a reason. Validation rules, local calculations, file transformations, permissions, and state transitions often benefit from remaining ordinary code. A model may help a person interpret an ambiguous request, but that does not mean it should own every operation that follows.
The point is not architectural purity. A useful product can combine all three. The point is to keep each responsibility at the level where it can be understood and tested.
The counterargument: models are getting better
There is a fair objection to this conservative approach. Models are improving quickly. Scaffolding that compensates for one generation’s limitations can become unnecessary with the next. Anthropic now notes that parts of its December 2024 tooling discussion have changed, and its later article on Managed Agents argues that assumptions embedded in a harness can go stale as model capability improves.
We agree with that warning. A complicated workflow can freeze yesterday’s limitations into tomorrow’s product. Excessive routing, hand-written recovery logic, and overlapping specialist prompts can constrain a model that no longer needs them.
But stronger models do not remove product responsibility. They may reduce the amount of orchestration required; they do not remove the need to define acceptable outcomes, protect user data, limit irreversible actions, expose failures, or decide when a human must remain in control. The durable approach is not to preserve every workaround. It is to keep the interfaces and success criteria stable while allowing the implementation beneath them to simplify.
Autonomy needs ground truth
An agent saying “done” is not evidence that a task is done. The system needs facts outside the model’s own prose: a test passed, a file exists, a schema validates, a cited source supports a claim, a constraint remains satisfied, or a user confirms the result.
Anthropic describes this as gaining ground truth from the environment at each step. Its later guide to evaluating AI agents makes an equally important distinction between a transcript and an outcome. The transcript is the path an agent took. The outcome is the final state in the environment. Different valid paths may produce the same correct state, while a confident-looking transcript may produce nothing useful at all.
This changes how we think about an AI feature. Verification is not a cleanup step added after the agent. It is part of the product surface. Before granting autonomy, we should be able to answer:
- What observable state means the task succeeded?
- Which tool result or external check can verify that state?
- What happens when the evidence is missing or contradictory?
- Which actions are reversible, and which require confirmation?
- What stops the loop when progress has stalled?
Some tasks do not offer adequate ground truth. A fluent answer can still be useful, but its uncertainty should remain visible and its authority limited. This matters especially around personal, health-related, or otherwise sensitive information. Software can help people record, organize, and reflect without pretending that model-generated interpretation is a verified diagnosis or decision.
Human checkpoints are part of the architecture
Human oversight is sometimes presented as a temporary limitation that disappears when models improve. We see it differently. A checkpoint defines where judgment, consent, or accountability belongs.
Low-risk, reversible actions can often proceed automatically. A proposed public change, an external message, a purchase, deletion, or a conclusion with material consequences may deserve explicit review. The important design work is to place that checkpoint before the consequential action, while the user still has enough context to make a real choice.
A good checkpoint should not ask someone to approve an opaque result. It should show the intended action, relevant evidence, meaningful alternatives, and what will happen next. Likewise, transparency does not require exposing a model’s private chain of thought. A product can show its plan, actions, sources, progress, and uncertainty in a form designed for the person using it.
Tools are an agent’s product interface
Agents act through tools, so tool design becomes product design. Anthropic’s guide to writing effective tools treats a tool as a contract between deterministic software and a non-deterministic agent. That contract must be easier to understand than a raw collection of API endpoints.
More tools do not necessarily create a more capable agent. Overlapping tools introduce ambiguous choices. Vague parameters invite incorrect calls. Large responses consume the context needed for reasoning. A smaller set of clearly named, narrowly scoped tools can give the model more room to choose well.
The same principle applies to context. Anthropic’s context engineering guidance recommends the smallest set of high-signal information that supports the desired behavior. Agents can retrieve details just in time instead of carrying every document, tool definition, and prior result through every turn.
For us, this reinforces a broader standard: capability should be legible. We should be able to explain what a tool can change, what it returns, how it fails, and how its behavior is evaluated.
Our working rules
When we consider an AI capability, we use a simple sequence of questions:
- Can deterministic code solve the core problem more reliably?
- If language understanding is needed, can one well-scoped model call solve it?
- If multiple calls help, is the control path known well enough to use a workflow?
- If autonomy is necessary, what environmental evidence will guide and verify it?
- Where do permissions, stopping conditions, and human judgment belong?
- Do evaluations show that each additional layer improves the outcome enough to justify its cost?
These are working principles, not a claim that every BorealBit product already contains an agent. In many products, the responsible answer may remain “no agent needed.” In others, a bounded workflow may provide the right amount of intelligence without transferring control of the entire task to a model.
Agentic systems will become more capable, and the implementation patterns will continue to change. Our standard should be more stable: choose the least complicated system that can be made useful, observable, and trustworthy. Autonomy should be earned by the problem and supported by evidence—not added because the label is fashionable.