The Agent I Built and Didn’t Need

I spent two weeks building an autonomous agent to classify and route support tickets. The LLM decided at each step: which category, which team, which priority, which response template. It was sophisticated. It was elegant. And it was completely unnecessary.

Know what worked better? Three LLM calls inside a traditional code pipeline: one to classify, one to extract data, one to generate the response. All connected by if/else. No decision loop. No “autonomy.” No surprises.

The result: 3x faster, 5x cheaper, and zero unexpected behaviors. The agent was more impressive. The workflow was more useful.

That experience taught me the lesson Anthropic published in its official agents guide and that in 2026 has become consensus among senior engineers: don’t build agents when workflows suffice.

The Difference That Seems Subtle (And Isn’t)

The fundamental difference between workflow and agent is who decides the next step.

Workflow: pre-defined steps. You, the developer, dictate the rules and the path information must follow. AI can be used within steps (classify text, generate response, extract data), but it doesn’t decide the flow. Ticket arrives → AI classifies → system routes to the right team. Each step was programmed by you. Predictable. Auditable. Cheap.

Agent: dynamic decisions. You give the model tools and it decides, at each turn, what to do next. The LLM receives the problem, decides to pull account data, analyzes history, decides whether to issue a refund or escalate to a human. The model chooses the path in real time.

Lyzr (agent orchestration platform used by Accenture, JPMorgan Chase, PepsiCo) summarizes the evolution: “In 2024-2025, the enterprise conversation was about agents — what they can do, how to build them, which framework to use. In 2026, the conversation shifted to orchestration.” It’s not about the individual agent. It’s about how multiple components — some agents, many workflows — work together.

The Biggest Engineering Mistake

The most common mistake I see (and committed): jumping straight to complex agents because they’re the buzzword.

The pressure is real. Every keynote is about “autonomous agents.” Every benchmark measures agentic performance. Every investor asks “do you have agents?” And the result: teams spend months building sophisticated agents for tasks a 50-line Python pipeline would solve.

The reality is that most solutions launched as “agents” are actually workflows in disguise. Forcing an LLM to make structured decisions that could be solved with if/else is an engineering failure that makes the application inconsistent, slow, and unnecessarily expensive.

Gartner predicts 40%+ of agentic AI projects will be scrapped by 2027 — not due to model quality, but escalating costs, unclear business value, and inadequate risk controls. Many of these projects simply shouldn’t have been agents.

DevTools Academy is direct: orchestration platforms “don’t magically make agents more capable. They give teams a way to run them with fewer loose ends.” The magic isn’t in the agent. It’s in the infrastructure around it — and frequently, that infrastructure is a workflow.

When You Actually Need an Agent

The golden rule: predictability. You should only adopt an agent architecture when it’s genuinely impossible to predict the next steps in advance.

The perfect example is a web research agent: it searches Google, reads a page’s content, and based on what it found (something you couldn’t predict), decides what the next search term should be. Each step depends on the previous result in unpredictable ways. That’s where agents shine.

Other legitimate agent use cases: autonomous navigation in unknown environments (robotics), multi-step negotiation with external parties (where the other side’s response is unpredictable), data exploration where the goal is vague (“tell me something interesting about this dataset”), and open-ended coding problem-solving (where the agent needs to test, fail, and iterate).

If your system doesn’t require that chaotic flexibility, stick with the workflow.

The 5 Real Orchestration Patterns of 2026

Lyzr cataloged the patterns companies actually use in production (not the ones in papers):

1. Sequential (Pipeline). Agent A completes, hands off to B, which hands off to C. Linear, predictable, deterministic. The simplest pattern. For document pipelines, multi-step approvals, data enrichment. It’s basically a workflow with LLM calls.

2. Hierarchical. A coordinator agent delegates to specialized agents. The coordinator decides who does what, but specialized agents execute defined tasks. Scalable — can manage hundreds of agents organized into “departments.”

3. Parallel (Fan-out/Fan-in). Multiple specialized agents process in parallel, and an aggregator combines results. For tasks that can be decomposed and executed independently.

4. Deliberation. Agents debate iteratively until convergence. For complex decisions that benefit from multiple perspectives.

5. Federated. Independent systems from different organizations collaborate without sharing private data. The newest 2026 pattern.

Notice: patterns 1 and 3 are essentially workflows with LLMs inside. Only patterns 4 and 5 require real dynamic decision-making. Most production projects live in patterns 1-3.

My Decision Framework

After making plenty of mistakes, I adopted a simple framework:

Step 1: Map the entire process. Before writing any code, map every step of the flow end to end. Use sticky notes, whiteboard, paper — doesn’t matter.

Step 2: Mark the decision points. At each step, ask: “Is the next step predictable or does it depend on context I can’t anticipate?”

Step 3: Use workflow for everything predictable. Classification? Workflow. Data extraction? Workflow. Routing? Workflow. Template-based response generation? Workflow.

Step 4: Use agents ONLY at genuinely unpredictable points. Open web research? Agent. Ambiguous problem diagnosis? Agent. Dynamic negotiation? Agent.

Step 5: Treat agents as components within the workflow. An agent is a specialized component inside a larger workflow — not the application’s entire structure. The workflow is the rail. The agent is the car that explores terrain when the rail ends.

Conclusion: Start with the Rails

Be pragmatic. Senior engineers’ recommendation is always to start with a rigid, well-defined workflow. If, and only if, you find a point in the flow where the next step depends on unpredictable contextual analysis, add an agent there.

Agents are powerful. But power without control is what took down Amazon’s AWS for 13 hours, deleted Grigorev’s data, and caused 6.3 million lost orders. Workflows are less impressive. But they’re predictable, cheap, auditable, and don’t make catastrophic decisions at 3 AM.

The right question isn’t “how do I build an agent?” It’s: “do I actually need one?”

Most of the time, the answer is no. And that’s fine.

Share if this clarified your architecture:

I spent two weeks building a sophisticated agent. A 50-line pipeline did the same job. Faster, cheaper, no surprises. Sometimes, boring code is the right code.

Read Also