PulseFlow Tecnologia
← Insights
·7 min read·technical-guide·ai-stack·mcp·langgraph
PulseFlow Tecnologia

How to assemble a minimal agent stack for production

Not every agent needs the full six layers that make up the 2026 stack - models, protocols and tools, memory, frameworks, evaluation, and guardrails. O'Reilly's report proposes a practical way to decide what's actually necessary: ask what kind of agent you're building before choosing any piece of the stack.

Question 1: how much state do you need to manage

That's the question separating a weekend project from a system that will require months of engineering. A stateless agent that just calls tools is a completely different engineering problem from a multi-session agent that learns over time - and the layers where state management is hardest (memory, frameworks) are where most teams get stuck.

Stack 1: stateless tool-calling agent

For a use case like answering questions from a knowledge base, the minimal stack is: a provider SDK (OpenAI, Google, or Microsoft, depending on the ecosystem already in use) + MCP for tool connectivity + PostgreSQL with pgvector, now the de facto standard for vector search without requiring a dedicated vector database. That combination is, per the report itself, a "weekend project" - it doesn't need a dedicated orchestration framework or long-term memory.

Stack 2: multi-step workflow

A case like end-to-end refund processing already requires more: LangGraph (or an equivalent graph-based orchestration framework) + MCP + eval infrastructure built before deployment, not after. The critical point here is exactly that - compiling evaluations before going to production, not as a reaction to a problem discovered later.

Stack 3: learning agent

When the requirement is remembering preferences across sessions, the stack shifts category: memory-first architecture, with a dedicated vector database and eval infrastructure specific to measuring whether memory is helping or hurting. The central challenge stops being technical and becomes a product decision: what should the agent remember, and when should that memory expire.

Stack 4: multi-agent system

When agents delegate tasks to other agents, the full six-layer stack comes into play - and eval infrastructure needs to cover every handoff between agents, not just the overall system's final response. This is the only scenario where the full stack actually pays off; applying it to a simpler use case is over-engineering.

What LangChain's data confirms about this sizing

The State of AI Agents survey shows the most common use cases today - research and summarization (58%), personal productivity (53.5%), customer support (45.8%) - fit mostly into Stacks 1 and 2, not the more complex ones. That's consistent with the O'Reilly report's argument: most teams don't need the full stack, they need to correctly identify which of the four profiles their use case fits.

The warning that avoids over-engineering

Assembling the multi-agent-system stack for a use case that's actually a stateless tool caller isn't technical rigor - it's wasted engineering time and unnecessary maintenance complexity. The right starting point isn't "which stack is most complete," it's "what's the smallest stack my use case actually requires."

Sources