products in public.

4 min read

The biggest lie of our industry: “You need an agent.”

I use more than 50 agents every day to build systems whose workflows should run on deterministic logic.

AgentsAutomationEngineering

Conceptual falling curve: as a process becomes more clearly defined, the value of agent autonomy decreases.

I use more than 50 agents every day.

They help me write, research, develop software, explore ideas, and create images and videos. They have changed how much I can build.

And a lot of what I ask them to build should eventually run without one.

My goal is usually to turn their work into deterministic logic: explicit rules, defined transitions, and workflows whose behavior I can understand before they execute.

That is why I think one of the biggest lies in our industry is the suggestion that every workflow needs an agent.

When I am creating something, I want room to explore. When a business process is running, I want its rules to hold.

Writing this article is an open task. Developing a product involves investigation, experiments, and decisions I cannot fully specify upfront. An agent is useful because the path emerges during the work.

Moving a lead between two predefined Salesforce stages is a different task. The condition is known. The destination is known. The permitted action is known.

Why should a language model reconsider that transition every time?

Why should I pay for inference to execute a rule I already understand?

Consider a contact form. Validate the input, map the fields, check for an existing contact, write the record to HubSpot, and notify the responsible person. Each step can have an explicit contract.

I want the hundredth execution to obey the same rules as the first. Different inputs can produce different outcomes, but the logic deciding those outcomes should remain defined.

Business processes change. Their rules should change deliberately, through a reviewed update, rather than drift during execution.

The distinction is well established. Anthropic describes workflows as systems with predefined code paths, while agents dynamically direct their own process and tool use. Its recommendation is to start with the simplest architecture that solves the problem. Anthropic, 2024

That distinction became easy to lose in the excitement around agentic automation.

My criticism of the hype around agents in automation is the assumption that autonomy automatically improves automation.

A demo where a model chooses tools looks impressive. The production question is whether those choices improve the outcome enough to justify the additional variability, cost, and maintenance.

Agents should operate within deterministic guardrails that define their permitted inputs, outputs, and actions.

For me, that is where the overhype sits: treating an agent as the default architecture before establishing whether the process needs runtime judgment.

There are plenty of places where AI belongs inside a workflow.

An LLM can classify an incoming email, extract information from an unfamiliar document, or draft a response. A small agent can investigate an unusual support case when the next useful action depends on what it discovers.

I want those capabilities at the points where interpretation adds value.

The surrounding workflow should define the permitted outputs, validate what it receives, and specify what happens when the result is unusable or uncertain. A valid category label does not prove that the classification is correct; some cases still need review.

Adding an AI module also does not require giving a model control over the entire process.

Evals are essential when that control is useful. They tell us how a system behaves across representative tasks and repeated attempts. They help detect regressions and expose weak spots.

They do not guarantee the next execution. Anthropic’s guidance on agent evaluations describes tasks that succeed in one run and fail in another. Anthropic, 2026

Prompt caching can reduce repeated input processing, but it does not turn a model’s decision into a deterministic rule. Tool permissions, stopping conditions, recovery behavior, and monitoring still need engineering. Anthropic’s prompt caching documentation

Deterministic code needs engineering too. It can contain bugs, receive bad data, or encounter an unavailable API. What it gives me is an explicit mechanism I can inspect, test, and repair. They can do this again with an agent.

The curve captures my preference: as the path becomes clearer, the value of letting a model choose that path usually falls. It is a conceptual model, not a measured law.

Agents have an enormous future. Open-ended business tasks will keep benefiting from them, alongside creative work and software development.

I use them every day because they help me discover what to build and how to build it.

And whenever that work produces a process with clear rules, I want those rules in code.

Use agents to build. Use code to run.