Open source agent stacks split into seven layers in 2026

O’Reilly’s 2026 guide breaks agent tooling into seven production layers.

Open source agent stacks in 2026 are no longer one big framework problem. Paolo Perrone’s O’Reilly Radar piece, published July 14, 2026, argues that teams should choose tools by layer, because the thing that fails first in production is rarely the same thing that impressed everyone in the demo.

The article’s core warning is simple: benchmark wins can hide ugly tradeoffs. One memory framework may crush LoCoMo, the long-conversation memory benchmark, while running 340x heavier per conversation than the runner-up. That kind of gap changes architecture decisions fast.

The seven-layer split is the real story

Perrone’s main point is that the agent stack has matured into seven layers: orchestration, memory, tool interface, browser or computer-use tools, coding agents, evals and observability, and inference. That split matters because each layer has a different bottleneck, and each bottleneck punishes a different kind of mistake.

He frames the choice around four constraints: latency budget, audit trail, model portability, and language stack. That is a much better filter than asking which project has the flashiest demo video or the most active Discord.

The article also draws a hard line between open source and open core. If production features like multitenant auth, replication, SSO, or audit logs live only in the hosted product, the repo is not the whole answer for a production team.

• Latency budget decides how much time and token spend each turn can consume.
• Audit trail matters when every action needs to be traceable for compliance.
• Model portability matters when you do not want the agent locked to one provider.
• Language stack matters because Python and TypeScript teams do not want the same tooling.

Orchestration is where production pain starts

At the orchestration layer, the article puts LangGraph in the default slot for Python production work. The reason is not hype. It is state management: durable execution, checkpointing with PostgresSaver, time-travel debugging, and a model that maps cleanly onto audit-heavy systems.

The author points out that companies such as Klarna, Uber, LinkedIn, JPMorgan, and Replit appear in the framework’s verified enterprise list. That matters because production adoption is often the strongest signal that a framework has survived contact with real systems.

Perrone is also blunt about the tradeoff: LangGraph is verbose. A simple two-agent flow still needs a state schema, nodes, edges, and compilation. If your workflow is just “call three tools sequentially,” that overhead can feel like using a freight train to move a backpack.

“The best way to zero in on the constraint your system will hit first under load: latency budget, audit trail, model portability, or language stack.”

Paolo Perrone, O’Reilly Radar, July 14, 2026

That quote is the article in one sentence. It turns agent selection from a feature checklist into an engineering constraint exercise.

The lighter tools win when the problem is smaller

The article does not crown one framework for everything. It gives each tool a job, and the jobs are different enough that the comparisons matter. CrewAI gets the nod for lowest setup overhead. You define roles such as researcher, writer, and reviewer, then let the crew run with minimal ceremony.

That simplicity comes with a cost. CrewAI does not resume crashed runs from the point of failure, error handling sits at the crew level rather than the node level, and the system does not keep an inspectable state schema that records what happened and when. For prototypes, that may be fine. For systems that need postmortems, it becomes a problem.

Pydantic AI takes a different route. It treats every output as a typed Pydantic model, which makes validation and serialization much cleaner for single-loop agents that feed downstream services. The tradeoff is weaker multi-agent support than LangGraph or CrewAI.

• LangGraph: best for durable Python production flows
• CrewAI: best for quick role-based prototypes
• Pydantic AI: best for typed single-agent outputs
• Mastra: best for TypeScript teams building inside Next.js

For TypeScript shops, Mastra gets a strong mention because it bundles agents, workflows, RAG, and evals into one package. The article notes that the project comes from the ex-Gatsby founders and fits naturally into existing Next.js apps without adding a Python sidecar.

The comparison is practical rather than ideological. If your team is already all-in on TypeScript, forcing a Python stack just to satisfy a tooling trend makes little sense. If your team needs stateful retries, traceability, and a larger enterprise footprint, the Python path still looks better.

Benchmark numbers matter less than failure modes

The most useful part of the piece is how it treats benchmark numbers. A win on a leaderboard can still hide a cost that kills you later. The article’s 340x memory gap is the clearest example, but the same logic applies across the stack: browser tools fail on canvas-heavy sites, eval suites rot when they live in a Notion page, and inference choices can lock you into one vendor.

That is why the piece keeps returning to production failure modes. The question is not “which project is best?” It is “which project fails in the least damaging way for my system?”

That framing also explains why the article treats the open source toolkit as a collection of tradeoffs rather than a winner-take-all market. Some layers reward durability. Some reward speed of setup. Some reward typed outputs. Some reward ecosystem depth. Teams that ignore those differences end up rewriting schemas in week three.

What teams should do next

If you are building an agent in 2026, the article’s advice is to pick the first layer that will break under load and start there. For regulated workflows, that is often orchestration. For content or support bots, it may be memory or browser tooling. For product teams shipping inside a web app, it may be the language stack.

The bigger takeaway is that the open source agent world has become more mature and more fragmented at the same time. That is good news for teams that know their constraints, and bad news for anyone hoping one framework will solve every problem.

My read is that the next wave of adoption will reward boring reliability over demo polish. The teams that win will be the ones that can answer a simple question before they write code: which layer am I optimizing, and what am I willing to give up to make it work in production?