Open any startup's landing page right now and you'll see the same thing: "Powered by AI Agents." Pitch decks that used to say "machine learning" now say "agentic." Y Combinator's latest batch has more agent-wrapper companies than SaaS companies. Everyone is building agents.
Most of them shouldn't.
Not because agents are bad — they're the most important shift in software development since cloud computing. But the instinct to make everything an agent is the same instinct that made everything a microservice in 2016, everything a blockchain in 2018, and everything a "no-code" solution in 2021. The technology is real. The application discipline is missing.
After spending the last year building agent-first systems and studying how teams at OpenAI, Affirm, Wix, and others are deploying agents in production, I've developed a simple framework for when agents are the right call — and when they're expensive overkill disguised as innovation.
The Spectrum of Agent Justification
Not all tasks benefit from agents equally. There's a clear spectrum, and where your use case falls on it determines whether you should be building an agent or just writing a script.
Tier 1: Obviously Agent-Appropriate
Tasks that require multi-step reasoning with branching logic. The agent needs to observe, decide, act, observe again, and course-correct. Examples: code generation in unfamiliar codebases, research synthesis across multiple sources, customer support escalation where context accumulation matters.
The Wix AirBot system is the canonical example. Their agents maintain a live index of 4,200 internal flows, answer developer questions about system behavior, and resolve issues that would otherwise require a human to read logs, trace code paths, and cross-reference documentation. The branching logic is genuine — each answer depends on accumulated context from previous interactions in the session. At $0.30 per interaction and 675 engineering hours saved per month, the economics are unambiguous.
Tier 2: Agent-Optional
Tasks that could be solved with agents but also have straightforward deterministic solutions. The agent adds flexibility at the cost of reliability and observability. Examples: data pipeline orchestration (a DAG runner works fine), content generation with templates (a templating engine is faster and more predictable), API integration (a well-written client library beats an agent fumbling through OpenAPI specs).
The trap here is that the agent demo always looks impressive. You show your agent "figure out how to call this API" and it works in the demo. In production, the agent hallucinates a parameter name, sends malformed requests, and you spend three days debugging why the agent works 90% of the time and catastrophically fails 10% of the time. A 50-line client wrapper would have worked 100% of the time.
Tier 3: Agent-Harmful
Tasks where agents make things actively worse. Anything requiring guaranteed consistency, low latency, or regulatory compliance where non-determinism is a bug, not a feature. Financial calculations. Access control checks. Data validation. Audit logging.
I've seen teams wrap a simple CRUD API in an "agent" that "understands the data model." The agent occasionally misinterprets a field name and returns wrong data. The team then builds an elaborate verification layer — which is just a deterministic system that should have been the implementation in the first place. They've built a Rube Goldberg machine where the agent is the marble that occasionally takes the wrong ramp.
The Real Cost of an Agent
When you decide to build an agent, you're not just paying for the LLM API calls. You're signing up for a stack of hidden costs that most teams discover in production:
- Harness engineering overhead. Every agent needs an environment designed for it — constraints, context, verification, correction loops. For the OpenAI team, the harness took more engineering effort than the product code the agents generated. The ratio varies, but the direction doesn't: harness investment always exceeds what you'd spend on the equivalent deterministic system.
- Observability debt. Agents make decisions you can't easily inspect. When a deterministic service fails, you look at the logs and trace the code path. When an agent fails, you need to reconstruct its reasoning chain — assuming you even logged it. Most teams don't, until the first production incident.
- Testing complexity. Unit tests for deterministic code are straightforward: input goes in, output comes out, assert. Testing agents requires handling non-deterministic outputs, mocking LLM responses, and building evaluation suites that measure behavior over distributions rather than exact matches. This is a fundamentally harder testing paradigm.
- Failure mode multiplication. A deterministic system has the failure modes you designed for. An agent has those plus every failure mode the LLM introduces — hallucinations, context window exhaustion, instruction misinterpretation, tool use errors. You're running two systems in parallel, and both can fail independently.
The Affirm engineering team ran headfirst into this. After their January 2026 mandate to go agent-first across 800+ engineers, they discovered that agent-generated tests often confirmed agent-generated bugs. The misunderstanding was in the prompt, not the code, and both implementation and test faithfully reproduced the misunderstanding. They now cross-reference PR diffs against acceptance criteria using multiple independent models — a verification layer that costs real money and adds real latency.
The Decision Framework
Before building an agent for any task, run it through these four questions:
- Does the task require branching logic that can't be expressed as a decision tree? If you can flowchart it, automate it. Agents are for ambiguity, not complexity.
- Is the cost of non-determinism acceptable? If a wrong answer 2% of the time is fine (content suggestions, search ranking), agents are viable. If it's catastrophic (financial transactions, access control), use deterministic code.
- Can you afford the harness? The minimum viable harness — AGENTS.md, three lint rules, CI pipeline, structured docs, plan template — is maybe a week of engineering time. A production-grade harness is months. Can your use case justify that investment?
- Is the agent adding knowledge or just adding steps? If the agent is doing something a well-written function could do but "more flexibly," you're paying for flexibility you don't need. If the agent is applying world knowledge or reasoning about unfamiliar contexts, that's genuine value.
If you answered yes to all four, build the agent. If you answered no to any of them, think harder about whether you're solving a real problem or riding a hype cycle.
The Product Discipline Gap
Here's the uncomfortable truth about the current agent moment: the engineering challenges are significant but tractable. The real gap is product discipline.
Every framework comparison — Claude Agent SDK vs. OpenAI Agents SDK vs. Google ADK vs. LangGraph vs. CrewAI — is a valid engineering conversation. But the question that matters more is: should this be an agent at all?
The teams succeeding with agents — OpenAI's million-line experiment, Wix's AirBot, Affirm's 58% PR increase — all share one trait: they started with a genuine problem that required non-deterministic reasoning, then built the agent to solve it. The teams struggling started with "we should use agents" and then went looking for problems to apply them to.
This is the same pattern that killed most microservices architectures. The companies that succeeded with microservices (Netflix, Amazon) had genuine scaling problems that monoliths couldn't solve. The companies that struggled adopted microservices because the blog posts said to, then spent years dealing with distributed system complexity they didn't need.
What I'm Betting On
My prediction: in 18 months, the agent landscape will look very different from today. The protocol layer is already consolidating — ACP merged into A2A under the Linux Foundation, MCP crossed 200 server implementations. The framework layer will consolidate next. Of the eight major agent SDKs competing today, three or four will have meaningful market share and the rest will be maintenance mode or abandoned.
But the teams that win won't be the ones who picked the "right" framework. They'll be the ones who were ruthlessly disciplined about when to use agents and when to write deterministic code. The best agent systems I've seen are mostly deterministic with carefully chosen agent-shaped holes where non-deterministic reasoning genuinely adds value.
The technology is extraordinary. The discipline to use it well is rare. Build agents where they matter. Write code where they don't. And for the love of all that is holy, stop wrapping your CRUD API in a chatbot and calling it innovation.
Related: What Is Harness Engineering? — the deeper dive into building environments where agents succeed.