• Enclave vs. the agent frameworks we audited — it’s a layer map, not a fight
  • The two layers
  • The map, side by side
  • How to read this (the honest caveat)
  • What enclave deliberately does NOT do
  • So: which do I use?

§Enclave vs. the agent frameworks we audited — it’s a layer map, not a fight

I spent two weeks auditing five agent frameworks for token cost — AutoGen, CrewAI, LangChain, LangGraph and smolagents. Every write-up ended with the same question in the comments: “so which one should I use — and where does enclave fit?”

The honest answer is that it’s the wrong question, because enclave and those frameworks aren’t the same kind of thing. They’re different layers of the stack. You don’t pick enclave instead of CrewAI. You can run a CrewAI crew inside an enclave pod. This post is the map.

§The two layers

The frameworks are orchestration DSLs. They’re how you wire agent logic — who talks to whom, what tools an agent can call, how a multi-step task is decomposed. AutoGen gives you multi-agent conversations; CrewAI gives you role-based crews; LangGraph gives you a state graph; smolagents gives you a tight code-writing ReAct loop. That’s real, valuable work, and enclave does none of it. Enclave has no crew abstraction, no conversation patterns, no graph builder. If you want agents that talk to each other, you reach for a framework.

Enclave is the runtime substrate. It’s where an agent process runs and what it’s allowed to touch — the container boundary, the network policy, the credential handling, the memory that survives a restart. It’s brain-agnostic (README.md:192 — BRAIN=claude | api | local | optimize, one env var), so the model underneath is yours to pick. It doesn’t care whether the logic inside is a CrewAI crew, a LangGraph, or a plain script.

Composable, not competing:

┌─────────────────────────────────────────────┐
│  YOUR AGENT LOGIC                            │
│  (AutoGen / CrewAI / LangGraph / smolagents  │   ← the framework: orchestration DSL
│   / a plain loop — your choice)              │
├─────────────────────────────────────────────┤
│  ENCLAVE RUNTIME                             │
│  container isolation · egress policy ·       │   ← the substrate: where it runs,
│  credential vault · memory vault · delegation│      what it can touch
├─────────────────────────────────────────────┤
│  Docker + your host                          │
└─────────────────────────────────────────────┘

§The map, side by side

§How to read this (the honest caveat)

This is not a benchmark leaderboard, and I won’t pretend it is. The frameworks and enclave live at different layers, so most cells above aren’t a “who wins” — they’re “whose job is this.” The “default cost failure” numbers from the audit series (AutoGen 5.5×→15.5×, CrewAI 6×, LangChain O(N²), LangGraph 7×, smolagents up to 9.5×) each come from that framework’s own worked scenario — different N, different turn counts — so they are not comparable across rows. You cannot read this table as “enclave is cheaper than CrewAI.” Enclave isn’t in that race; it’s the floor the race runs on.

What the map does tell you: the layer where you write agent logic and the layer where an agent runs and is contained are different concerns, and a lot of production pain comes from bolting containment onto a framework after the fact. Pick a framework for the logic. Pick a substrate for the isolation, the egress policy, and the credential boundary.

§What enclave deliberately does NOT do

Being category-honest cuts both ways:

• No orchestration DSL. No Crew, no StateGraph, no RoundRobinGroupChat. If you want structured multi-agent conversation, use AutoGen (or wire it yourself and run it in a pod).
• Egress is report-only by default. The container boundary is always on, but the network allowlist only logs until you set GUARD_EGRESS_ENFORCE=1 (README.md:16-20). Ship it on for anything real.
• Public alpha. Apache-2.0, used daily by its authors to run a live fleet, but the API and layout still move (README.md, “Status”).

§So: which do I use?

Both, usually. The question isn’t “enclave or a framework” — it’s:

1. What logic am I building? → a framework (or plain code). Whichever fits your agent’s shape.
2. Where does it run, and what can it reach? → enclave, if you want kernel-enforced isolation, an egress policy, and a credential + memory boundary you didn’t have to build.

The frameworks’ shared default cost bug (re-sending accumulated context — the whole reason this series exists) is still yours to fix at the framework layer; enclave doesn’t magic it away. But when you’ve fixed it and you want to actually run the thing with credentials and network access it shouldn’t fully have, that’s the substrate problem, and it’s the one enclave is for.

Enclave is open-source (Apache-2.0): github.com/wartzar-bee/enclave. The five-part cost-audit series that grounds the framework column is on dev.to/wartzarbee. Want the numbers for your own project? tokenscope reads your Claude Code logs and shows exactly where the tokens went (npx @wartzar-bee/tokenscope — read-only, nothing leaves your machine), and ci-guardrail fails a PR when a token-cost regression sneaks in. wartzar-bee builds tools for operating cost-efficient autonomous agents.