Not everything needs an agent
In 1931, Rube Goldberg won a Pulitzer Prize for drawings of machines that accomplished simple tasks through spectacular chains of unnecessary steps. A self-wiping napkin apparatus involving a parrot, a lit candle, a swinging pendulum, and seven other components.

Introduction
The joke was not that the machine was badly designed. It was that it was brilliantly designed for the wrong problem. The napkin got wiped. The complexity was the real output. The AI industry spent most of 2024 in the same place.
The Problem That Didn’t Need an Agent
A client came to us with a document extraction task. Twelve fields. The same twelve fields, in the same positions, on every submission of the same form. Structured data, consistent source, zero variation.
We built an agent. Memory, tool use, a supervisor node, retry logic. It worked reliably in production, handled edge cases gracefully, and made a good demo. Eight months later we replaced it with a GPT-4o call, a Pydantic response model, and four lines of logic. Faster, cheaper, and when it failed, the failure was immediately obvious rather than buried three nodes into an execution graph.
The agent had been solving a problem that didn’t require one. We built it anyway because agent were what we were thinking about. The napkin got wiped. The complexity was the real output.
When the Costume Fits
Agents earn their complexity when the path through the problem is genuinely unknown in advance. When the right tool call depends on what a previous tool call returned. When a human given the same task would need to make judgment calls mid-process.
“Find the most recent filing for this entity, extract the relevant disclosures, cross-reference against our internal database, and flag anything that changed” —
the steps depend on what you find. The path branches at runtime. That’s an agent problem.
“Extract these twelve fields from this form” is not. If you can draw a complete flowchart of the task before you start, and the flowchart has no branches that depend on runtime outputs, you need a
pipeline.
The question is not “can an agent do this?” Everything can be framed as an agent problem. The question is whether the path actually changes.
Why We Build Agents Anyway
Part of it is the tooling. LangGraph and its relatives make it easy. The tutorials show agents. The demos are agents. When the primary abstraction is agents, everything looks like it needs one. (There’s also the pitch: “we built you an AI agent” lands differently than “we built you a function that calls an API,” and everyone in the room knows it.) The cost shows up months later. An agent that fails produces a state replay problem. A pipeline that fails produces a traceback. That difference matters at two in the morning when something breaks in production.
Most “agentic AI” projects are deterministic pipelines wearing a costume. The costume adds complexity, not capability.
Rube Goldberg’s machines worked. The parrot released the string, the pendulum swung, the napkin wiped. The complexity wasn’t a flaw. It was what made them drawings rather than engineering. When you’re building for a client, that distinction matters.
You might also like
Keep reading with more notes from the journal.

#AI #Data #Search #Engineering #TechLeadership
The million-token search engine that isn’t
A library with no card catalog has every book you could want and no way to find any of them. Bigger libraries don’t fix search. They make search worse. That is most of what is wrong with the current marketing of long context windows.

#PromptEngineering #DataModeling #Tech #In
Schema before prompt
A stage director can rehearse the play to perfection. The actors hit their marks. The lighting cues are timed to the breath. But if the prop master walks out with a sword when the script calls for a letter, the scene collapses, and the audience walks out blaming the actor.`

#Hiring #Teams #Tech #Leadership #Growth
They skipped the boring part
Last year, we hired a junior engineer with fifteen GitHub repositories, three of them with actual stars. He shipped fast, had opinions about architecture on day one, and could produce working code in the time it took me to finish my coffee. We were delighted.
