You probably do not need the framework.

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. I look at what exists, keep what works, and agree the journey that has to work before any build starts.

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.

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 breakdown.

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.

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.

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.

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, where the goal is always the smallest stack that passes the eval suite reliably, not the most sophisticated one on paper.

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 answers.