# You probably do not need the framework. > A state graph, a vector database, and an orchestration framework for a job a 60-line script does better. How to size the agent stack to the actual problem. Canonical URL: https://techtideai.io/blog/the-agent-stack-most-teams-overbuild Markdown URL: https://techtideai.io/blog/the-agent-stack-most-teams-overbuild.md Publisher: TechTide AI, Columbus, Ohio (https://techtideai.io) Author: Alex Cinovoj, Founder & CTO, TechTide AI · CTO & Co-Founder, CPG Playbook Type: Field Note Published: 2026-03-11 Reading time: 9 min Topics: AI agent stack, LangGraph alternative, agent framework, AI architecture Site index: https://techtideai.io/llms.txt Offer summary: https://techtideai.io/offers.md --- ANALYSIS / 9 MIN READ ## You probably do not need the framework. By [Alex Cinovoj](https://alexcinovoj.com/), Founder & CTO, [TechTide AI](https://techtideai.io/about) · CTO & Co-Founder, CPG Playbook Published March 11, 2026 Last month I reviewed a customer support agent with fourteen nodes in a state graph, a vector database holding four hundred documents, and a supervisor agent whose only job was to route between two workers. The task was answering refund status questions. A junior engineer could write the same logic in sixty lines with a single loop and two typed tools. This is the most common architecture mistake I see in 2026: teams reach for the framework before they have written down the problem. The fix is not "never use a framework." The fix is sizing the stack to the job in front of you, and adding complexity only when a specific, named requirement forces it. ## Key takeaways - Most agent projects should start as a single loop with typed tools, not a state graph, vector database, or orchestration framework. - Add a vector database, orchestration framework, message queue, or state graph only when a specific, named requirement forces it. - Overbuilt agent stacks rarely fail loudly, they fail by becoming impossible to change when requirements shift. - Complexity is earned when you have multiple independent agents, a large changing corpus, or an asynchronous boundary measured in hours. - Before building, describe the task in five sentences without the words orchestrate, graph, or framework, and build the loop if you can. ## The default reflex is backwards Choosing the stack before the task, such as LangGraph, a vector database, a message queue for agent-to-agent handoffs. Then they go looking for a problem that justifies the stack. That ordering is backwards. It produces architecture that looks impressive in a diagram and breaks in ways nobody can trace, because the failure could be in the graph, the retriever, the queue, or the model, and there is no way to know without instrumenting all four. The right ordering starts with the task. Write down, in plain language, what decision the model needs to make and what data it needs to make it. Most of the time the answer is: one decision, using data from one or two tool calls. That is a loop, not a graph. This matters more than it sounds like it should, because teams that get the ordering right ship in weeks and teams that get it backwards spend months debugging state transitions that have nothing to do with the model's actual reasoning. If this is what is holding your product back, [send the project brief](https://techtideai.io/contact). I look at what exists, keep what works, and agree the journey that has to work before any build starts. ## What a 60-line agent actually looks like Here is the shape of the agent that replaced the fourteen-node graph. It is not clever. That is the point. 1. **Receive the request.** Parse it into a typed struct: customer ID, order ID if present, and the raw question text. 2. **Call the model once** with the struct and a system prompt describing two tools: `lookup_order` and `check_refund_policy`. 3. **Execute whichever tool the model calls**, validate the output against a schema, and feed the result back to the model. 4. **Let the model produce a final answer**, validated against a response schema before it reaches the customer. 5. **Log the full trace**: prompt, tool calls, arguments, results, latency, and cost, to your existing observability stack. That is the entire system. No graph library, no vector database, no supervisor agent. When the volume of tools grew past a handful and the team needed a second agent to handle escalations with genuinely independent state, that is when a coordination layer became worth the complexity, not before. Further reading - [The only three orchestration patterns that survive contact with production.](https://techtideai.io/blog/agent-orchestration-patterns-that-survive) Also on agents and delivery · 10 min - [Gartner's 2025 agentic AI cancellation forecast: questions to review.](https://techtideai.io/blog/why-agentic-projects-get-cancelled) Also on agents and delivery · 10 min ## The 2026 take on this, and where it is wrong The popular argument this year is that agent frameworks are now mature enough that reaching for one by default is the responsible choice, the same way reaching for a web framework instead of hand-rolled routing is responsible. I understand the appeal, but the analogy is incomplete in a way that matters. Web frameworks solve a stable, well-understood problem: routing, sessions, templating. Agent frameworks are trying to solve state management for a category of software that is still changing shape month to month, because the underlying models keep changing what they are good at. A graph structure you build around GPT-4-era tool calling behavior does not map cleanly onto a model that can now hold a much longer plan in context without external state at all. Teams that adopted heavy frameworks in 2024 are now unwinding graph logic that the current generation of models makes unnecessary. The framework is not wrong to exist. It is wrong as a default. Use it when you can point to the specific coordination problem, like fan-out to five independent workers with different failure recovery needs, that a simple loop genuinely cannot solve. If you cannot point to that problem, you are paying complexity tax for a diagram, not a capability. For a broader framing of when true multi-agent coordination is warranted versus a single well-scoped agent, see our [AI agents vs agentic AI](https://techtideai.io/ai-agents-vs-agentic-ai) breakdown. ## A sizing checklist before you add a component Run this checklist before you add any piece of infrastructure to an agent project: - **Vector database:** Do you have more than roughly 10,000 documents, do they change weekly or faster, and does relevance depend on semantic meaning rather than keyword match? If not, a filtered SQL query or keyword index is cheaper and easier to debug. - **Orchestration framework:** Do you have two or more agents that need to run concurrently with independent state and their own retry logic? If it is one agent calling tools in sequence, you need a loop. - **Message queue for agent handoff:** Is the handoff asynchronous across a boundary that can be down for minutes, like a human review queue? If the handoff happens within one request-response cycle, a function call is enough. - **State graph:** Can you draw the actual decision tree on one whiteboard with fewer than six branches? If yes, a switch statement replaces the graph library with far less debugging surface. - **Separate retrieval service:** Does retrieval need to scale independently of the agent's request volume? If both scale together, keep retrieval in-process. Every "no" on this list is a component you can cut. Remove a component only after checking that its removal preserves required behavior. ## Why overbuilt stacks fail quietly Overbuilt agent stacks rarely fail loudly. They fail by becoming impossible to change. A support agent built as a fourteen-node graph took the team three weeks to add a single new tool, because the new capability had to be wired into the routing logic at four different nodes, and testing had to cover interactions between the new node and every existing branch. The sixty-line version took an afternoon: add a tool definition, add a case, add an eval, ship. This is the real cost of oversized architecture. It is not that it does not work on day one. Demos of complex agent graphs work fine, because the demo only exercises the happy path. It is that six months in, when requirements shift the way they always do, the team spends more time fighting the architecture than serving customers. Gartner's research on agentic project cancellations points at exactly this pattern: projects rarely die because the model was wrong, they die because nobody could safely change the system anymore. ## When complexity is actually earned None of this is an argument against frameworks, vector databases, or graphs in general. It is an argument against defaulting to them. Complexity is earned in a few specific situations: - You have multiple genuinely independent agents, each with its own retry and rollback logic, that need to run in parallel and recover independently from failure. - Your retrieval corpus is large, changes constantly, and needs semantic ranking that a keyword search cannot approximate. - Your workflow spans an asynchronous boundary measured in hours, such as waiting on a human approval or an external system callback, where a durable queue prevents lost work. - You have outgrown a single loop's ability to express the decision tree without unreadable nested conditionals. If your project matches one of these, add the component and instrument it the same way you instrumented the loop: typed inputs and outputs, a log of every transition, and an eval that would catch a regression. Complexity added deliberately, with a name attached to the reason, ages fine. Complexity added by default does not. ## How to migrate down from an overbuilt stack If you are already running an overbuilt agent and want to simplify it without a rewrite, here is the sequence that works on engagements: 1. **Map the actual paths taken.** Instrument the existing graph for two weeks and log which nodes actually fire in production. Most graphs use a fraction of their branches; the rest are dead code from an earlier requirement. 2. **Collapse dead branches first.** Delete nodes that never fire, with the eval suite as your safety net. This alone often cuts graph size in half with zero behavior change. 3. **Replace the remaining graph with a loop** for any path that is now linear, keeping the graph only around genuine branch points that survived step one. 4. **Re-run the eval suite** after each collapse and compare cost, latency, and pass rate against the baseline before merging. This is close to the sequence we run inside a [scoped MCP server build](https://techtideai.io/critical-system-implementation), where the goal is always the smallest stack that passes the eval suite reliably, not the most sophisticated one on paper. ## The one-line test to run before you build Before your next agent project kicks off, apply one test: can you describe the entire task, end to end, in five sentences without using the words "orchestrate," "graph," or "framework"? If you can, build the loop. If you genuinely cannot, write down the specific coordination problem that forces the extra component, and only then add it. This single habit, applied consistently, is the difference between an agent stack your team can change in an afternoon and one that takes three weeks and a design review to touch. If you want a second set of eyes on whether your current stack is sized to your actual problem, that is exactly the question a [production readiness review](https://techtideai.io/how-to-move-ai-pilot-to-production) answers. ## Frequently asked - No, not for most workflows. A single loop that calls a model, executes a typed tool, and checks the result against a schema handles the majority of production agent tasks. Frameworks earn their keep once you have multiple agents coordinating with independent state, not before. About the author ## Alex Cinovoj AI & Infra Engineer. Building AI that survives outside the demo. Founder & CTO, TechTide AI · CTO & Co-Founder, CPG Playbook I spent 13 years in US enterprise IT, the last 2 focused entirely on AI implementation. I run [TechTide AI](https://techtideai.io/), an implementation studio that takes stalled AI pilots into production. I write about the work in progress at [alexcinovoj.com](https://alexcinovoj.com/) and on [Substack](https://alexcinovoj.substack.com/). Logs over vibes. Production over theater. [alexcinovoj.com →](https://alexcinovoj.com/)[More on the studio](https://techtideai.io/about) Related field notes - ANALYSIS · 10 min · Agents, Orchestration ### [The harness matters more than the model now.](https://techtideai.io/blog/long-running-agent-harness) Frontier models converged. What separates working agents in 2026 is the harness: state, retries, checkpoints, budgets, and recovery. What to build first. - EXPLAINER · 9 min · Agents, Orchestration ### [MCP vs A2A: two protocols, two different jobs.](https://techtideai.io/blog/mcp-vs-a2a) MCP connects a model to your tools. A2A connects agents to each other. Picking the wrong one adds a distributed system you do not need. How to choose. [All field notes →](https://techtideai.io/blog) ## Have a stalled build that needs to work? [Send the project brief→](https://techtideai.io/contact)