Agents are a product category. They are not a default architecture.
That distinction gets lost every time a demo shows a model calling tools in a loop and calling it a product. The loop is impressive. It is also usually the wrong place to start.
I have shipped AI systems that look "agentic" from the outside: DocPilot reads a GitHub repo and generates structured API docs; an outbound recruiting engine discovers companies, ranks applicants, and queues personalized campaigns on a cron. Neither is an agent. Both are pipelines with LLM judgment bolted onto known steps. That is the pattern I keep returning to, and the one most AI products should start with.
What people mean when they say "agent"
Strip the marketing and an agent is roughly this:
- A goal in natural language
- A set of tools
- A model that picks the next tool call
- A loop until the model decides it is done
That shape is powerful when the path is genuinely unknown. It is expensive and hard to debug when the path is already known and you just handed the model permission to rediscover it every run.
Most product work is the second case. You already know the steps. Discovery, enrichment, ranking, delivery. Classify files, extract handlers, generate docs. Ingest a ticket, draft a reply, route to a human. The uncertainty is not "what should we do next?" It is "given this input, what is the right structured judgment at this step?" Confusing the two is how you end up with an agent that sometimes emails the wrong founder and still returns ok: true.
The products I shipped did not need a loop
DocPilot: classification, then generation
DocPilot's first instinct was the agent-shaped one: give the model the repo and ask it to figure out the docs. It worked on my test project. It hallucinated endpoints on everyone else's.
The fix was not a better agent prompt. It was splitting the pipeline: classify which files look like routes, extract those files deterministically, then generate. The model never "explores." It answers a narrow question with a schema, then another narrow question with a schema.
That is not an agent. It is ETL with an LLM in two slots. And it is more reliable because every failure has a stage: bad classification, bad extraction, bad generation. You can log which one broke. An open-ended tool loop collapses those failures into "the agent did something weird."
Recruiting outreach: orchestration, not autonomy
The outbound engine looks autonomous from the outside. Cron fires. Companies get discovered. Applicants get ranked. Emails get queued. Nobody clicks through each step.
Under the hood it is a control loop I wrote, not one the model invented. Discover -> enrich -> fan out ranking -> pick winners -> queue campaigns. The LLM ranks one applicant against one company and returns a score with a reason. It does not decide whether enrichment should happen, whether to skip a thin company profile, or whether to send the email. Those decisions live in code, including the degradation rules that keep a green cron from shipping a bad lead.
If I had made that an agent, told it to "go find good matches and outreach them," I would own every creative interpretation of that sentence in production. Instead I own a pipeline whose branches I can read.
What agents actually cost you
The demo cost is tokens. The product cost is control.
Unbounded work. A workflow has a known number of steps. An agent has a budget you hope it respects. One extra tool call is cute in a playground. Two hundred ranking calls that each spawn "just one more lookup" are a bill and a latency cliff.
Opaque failures. When a pipeline misclassifies a route file, you see it in the classification log. When an agent skips enrichment, invents a company detail, and still drafts a confident email, the failure mode looks like success until a human reads the output. I have already written about that class of bug in cron pipelines. Agents make it the default.
Hard regression testing. You can snapshot structured outputs for a fixed input. You cannot usefully snapshot "whatever the agent decided to do this time" without freezing temperature, tools, and luck. Products need regressions. Demos need vibes.
Permission surface. Every tool you give an agent is a capability it can misuse. Workflows call tools at known points with known arguments. That is not less AI. It is AI with a smaller blast radius.
Product ambiguity disguised as architecture. "We'll make it an agent" often means "we have not specified the workflow yet." That can be fine for research. It is a weak foundation for something users pay for and ops has to trust.
When you do need an agent
Sometimes the path really is unknown.
You need an agent-shaped loop when:
- The environment is open and the next action cannot be enumerated ahead of time (a coding agent in an unfamiliar repo, a research assistant across messy sources)
- Tool choice is the product, not a side effect (the user is watching the model work and intervening)
- Long-horizon tasks where intermediate state genuinely cannot be reduced to a fixed DAG without lying to yourself
Even then, the agents that work in production tend to be narrower than the demos. Constrained tools. Hard stop conditions. Human approval before irreversible actions. Structured checkpoints between free-form reasoning. In other words: they borrow the discipline of workflows instead of replacing it.
If your "agent" always follows the same four steps and the same three tools, you do not have an agent. You have a workflow with extra indirection. Delete the loop and write the steps.
A better default
Start with the core loop as a pipeline.
- Write the steps as if no LLM existed.
- Mark the steps that require judgment rather than rules.
- Put a structured model call only on those steps.
- Keep sequencing, retries, budgets, and side effects in code.
- Add an open-ended agent loop only when you can name the uncertainty that a fixed graph cannot express.
That order matters. Most teams invert it: start with an agent framework, then discover they needed a cron, a schema, and a skip condition.
The question is not "can an agent do this?" Plenty of agents can do things pipelines already do. The question is:
Do I need the model to choose the next action, or do I already know the next action and only need the model to judge this input?
If you already know the next action, start with a workflow. Only introduce an agent when choosing the next action is itself the problem you're solving. You need a workflow with LLM judgment where judgment earns its keep. That is less exciting in a launch video. It is how the AI products I trust in production are actually built.
Related: Two-Step LLM Pipelines · Orchestrating Parallel LLM Workloads · Graceful Degradation in Cron Pipelines · DocPilot case study