Agent Landscape #1: The 5 Things Every Production Agent Needs

The Problem

You can build a working AI agent in 50 lines of Python:

while True:
    response = llm.chat(messages, tools=tools)
    if response.tool_calls:
        for call in response.tool_calls:
            result = execute_tool(call)
            messages.append(result)
    else:
        break

This works in a demo. In production, it fails in five specific ways:

1. The loop has no memory of itself. Restart the process and all progress is lost.

2. The context window overflows. After 50 tool calls, the model forgets why it started.

3. Tools run in the same process. A hallucinated os.remove("/") executes with full permissions.

4. One agent can't do everything. Complex tasks need specialized sub-agents that coordinate.

5. The reasoning loop itself is fragile. No structured error handling, no retries, no multi-step planning.

Every team discovers these in production — usually in this order. After analyzing every relevant open-source project (totaling 3.0M+ GitHub stars across 11 categories), one pattern emerged: each project solves 1-2 of these problems excellently.

Component 1: Orchestration — The Reasoning Loop

The Problem

A raw LLM API call returns text. An agent needs to:

• Decide whether to call a tool or respond

• Parse tool arguments reliably (structured output, not regex)

• Handle tool failures (retry? skip? escalate?)

• Plan multi-step sequences (not just react to the last result)

• Know when to stop (avoid infinite loops)

Without orchestration, you get agents that hallucinate tool calls, loop forever, or crash on the first error.

What's Actually Needed

The key architectural decisions:

• How to represent control flow: Graph (LangGraph), roles (CrewAI), typed functions (PydanticAI), self-organizing (Hermes)

• How to enforce structured output: JSON schema (most), Pydantic models (PydanticAI), code-as-output (Smolagents)

• How to handle multi-agent: Shared memory (dangerous), message passing (AutoGen), delegation (DeerFlow/Hermes), handoff (Swarm)

How Projects Solve This

The gap: Every framework handles the "happy path" well. The difference shows in error recovery, loop control, and what happens when the LLM returns something unexpected. Most frameworks offer some error handling (PydanticAI retries on validation failure, CrewAI retries/delegates failed tasks, Smolagents feeds execution errors back to the LLM) — but LangGraph and AgentScope provide the most granular control: node-level error routing, configurable retry policies with backoff, and fallback edges.

Component 2: Durable State — Surviving Crashes

The Problem

Your agent has been working for 30 minutes. It's made 47 tool calls, gathered data from 12 APIs, and is about to execute the final step. Then:

• The process OOMs

• A deploy restarts the container

• The network partitions

All work is lost. The user starts over. Or worse: the agent partially executed something (sent half an email, created 3 of 5 resources) and now the system is in an inconsistent state.

What's Actually Needed

The critical subtlety for agents: LLM calls are non-deterministic. Traditional event sourcing replays by re-executing. Agent event sourcing must cache the LLM response — replaying the same prompt might produce a different plan.

How Projects Solve This

The gap: Agent-native event sourcing — durability that understands LLM calls are non-deterministic, context windows need compression on replay, and tool calls have schemas that can be validated on resume — remains an open problem.

Component 3: Memory — Beyond Context Window Overflow

The Problem

Context windows are finite. GPT-4o: 128k tokens. Claude: 200k tokens. Sounds like a lot — until your agent:

• Has a 10-turn conversation with tool results (easily 50k tokens)

• Needs to reference facts from 3 sessions ago

• Must remember user preferences across weeks of interaction

• Accumulates knowledge that should persist forever

When the window fills, the model either truncates (loses critical early context), summarizes (loses detail), or fails. Without memory management, agents degrade predictably: they forget their own instructions, repeat failed approaches, and lose user trust.

What's Actually Needed

The key question: who manages memory? Two schools:

• Passive: The system automatically manages memory (truncate, summarize, embed). Simple but loses nuance.

• Agent-managed: The agent explicitly reads/writes/forgets memory as tool calls. More powerful but adds complexity to every interaction.

How Projects Solve This

The gap: No project cleanly separates the three tiers while letting the agent control all of them. Letta comes closest but requires buying into their platform. Mem0 solves storage but not working-memory management.

Component 4: Sandboxed Execution — Isolating Dangerous Actions

The Problem

Agents call tools. Tools execute real actions: run code, call APIs, modify databases, send emails. The failure modes:

1. Hallucinated dangerous commands: rm -rf /, DROP TABLE users, kubectl delete namespace production

2. Data exfiltration: Agent sends sensitive data to an external endpoint

3. Resource exhaustion: Infinite loop burns $10k in compute before anyone notices

4. Privilege escalation: Tool inherits the agent's full permissions instead of scoped access

Most agent frameworks run tools in the same process as the agent — same permissions, same network access, same trust boundary. A hallucinated action executes with full authority.

What's Actually Needed

How Projects Solve This

The gap: Sandboxing projects don't integrate with agent frameworks. Framework projects don't provide sandboxing. You always glue them together yourself — and the integration surface (credential passing, result serialization, timeout handling) is where bugs hide.

Component 5: Multi-Agent Coordination — Agents Talking to Everything

The Problem

A single agent hits limits:

• Context window: One agent can't hold a 200-page codebase + conversation + tool results

• Specialization: A research agent needs different tools and prompts than a coding agent

• Parallelism: Sequential tool calls are slow; parallel sub-agents are fast

• Cost: Routing simple queries to GPT-4 wastes money; a triage agent can delegate to cheaper models

But coordination introduces new failures:

• How do agents discover each other's capabilities?

• How do you prevent infinite delegation loops?

• How do you share context without shared mutable state?

• Who handles failures in sub-agents?

What's Actually Needed

How Projects Solve This

The gap: Protocols define how agents communicate, but not how to handle failures, budgets, or trust between agents from different organizations. The "service mesh for agents" — discovery, load balancing, circuit breakers, mutual auth — doesn't exist yet.

The Integration Map

Who Covers What

No project spans all 5. Here's the honest coverage map:

The closest to "complete":

• OpenClaw (378k) — covers 4/5 for personal use, but not enterprise multi-tenant

• AgentScope (26k) — covers 4/5 with K8s deployment, but Alibaba ecosystem defaults

• Hermes (190k) — covers 4/5 with self-improvement, but pre-1.0 APIs

All three still lack full event-sourced durability.

The Full Landscape at a Glance

Total landscape: 60+ projects, 3.0M+ stars, 11 categories.

What This Means for Builders

If you're evaluating frameworks: Ask which of the 5 components they cover. Most cover 1-2. The "Who Covers What" table above is your starting point.

If you're building agents today: Pick orchestration first (Hermes for self-improving, LangGraph for flexible, AgentScope for all-in-one). Then add durability and sandboxing as first infrastructure investments. Accept 3-4 project integrations minimum.

If you're building agent infrastructure: The opportunity is a unified platform that co-designs all 5 layers — with pluggable backends for laptop, Docker, Kubernetes, and serverless. This is the "Kubernetes for agents" opportunity.

The Deeper Pattern

The hard problems in agent engineering are distributed systems problems applied to a new domain:

We've solved all of these before. The industry just hasn't applied them to agents in a unified way yet.

*Next: Agent Landscape #2: Orchestration — Pick Your Reasoning Loop