lambdagent/docs/paradigm-comparison.md

Five Architecture Paradigms vs λA Programming Paradigm

Date: 2026-04-04 Context: The AI agent framework landscape in 2025-2026 is shaped by three major shifts: MCP tool-calling standardization, A2A protocol emergence, and Context Engineering. Mainstream frameworks are classified into five architecture paradigms. This document shows that all five are special cases of λA.

Sources: Building Effective Agents — Anthropic, 2025 AI Agent Architecture Survey — Zhihu, Anthropic Multi-Agent Research System

---

1. Overview

The five paradigms classify frameworks by implementation approach — what technology you use to build agents. The λA paradigm classifies agents by computational semantics — what agents are mathematically. This is the fundamental distinction.

Paradigm	Representative	λA Corresponding Constructs	Formal Semantics?	Type Checking?	Termination Guarantee?
Graph State Machine	LangGraph	Route(c, {lᵢ:aᵢ}) + Loop(b, c, n)	❌	❌	❌
Role-Driven	CrewAI	GroupChat(agents, scheduler) + Handoff	❌	❌	❌
Event-Driven	LlamaIndex, AgentScope	Channel(name, cap) + Send/Receive	❌	❌	❌
SDK Wrapper	OpenAI SDK, PydanticAI	Lam(n, π, θ) + Tool(n, f)	❌	PydanticAI partial	❌
Low-Code Platform	Dify	from_config(YAML) compiler	❌	❌	❌
λA Paradigm	lambdagentpaas	All 11 constructs	✅ 23 rules	✅ 15 rules	✅ Theorem 5.4

---

2. Paradigm-by-Paradigm Analysis

2.1 Graph State Machine (LangGraph)

Core idea: An agent is a directed graph. Nodes are LLM/Tool calls, edges are conditional transitions.

# LangGraph
graph = StateGraph(AgentState)
graph.add_node("think", think_node)
graph.add_node("search", search_node)
graph.add_node("answer", answer_node)
graph.add_edge("think", "search", condition=needs_search)
graph.add_edge("think", "answer", condition=has_answer)
graph.add_edge("search", "think")  # cycle back

λA equivalent:

Route(classifier, {
    "search" → Tool("search", web_search) >> Lam("think", prompt),
    "answer" → Lam("answer", prompt)
})

Graph state machine = Route (multi-way dispatch) + Loop (bounded fixpoint) + Compose (edges).

What λA adds:

Issue	LangGraph	λA
Will a cycle deadlock?	Unknown until runtime	Compile-time: fix_n guarantees termination in ≤n steps (Theorem 5.4)
Are node types compatible?	Runtime crash	Compile-time: T-Route requires all branches return same type
Are two graphs semantically equivalent?	Cannot determine	6 algebraic laws (route distribution, etc.)
Is refactoring safe?	Trial and error	Semantic-preserving transformations

LangGraph's advantage: Visual intuition — draw a graph, get a program. λA's Route >> Loop is less visual.

Conclusion: Graph state machine is a special case of λA (Route + Loop), lacking type safety and termination guarantees.

---

2.2 Role-Driven (CrewAI)

Core idea: Define roles (Role/Goal/Backstory), form teams, collaborate by process.

# CrewAI
researcher = Agent(role="Researcher", goal="Find facts", backstory="...")
writer = Agent(role="Writer", goal="Write report", backstory="...")
crew = Crew(agents=[researcher, writer], process=Process.sequential)

λA equivalent:

# sequential = Compose (pipeline)
researcher >> writer

# hierarchical = Route (manager dispatches)
Route(manager_classifier, {
    "research" → researcher,
    "writing"  → writer
})

# collaborative = GroupChat (π-calculus N-agent discussion)
GroupChat([researcher, writer, reviewer], max_rounds=10)

What λA adds:

Issue	CrewAI	λA
Data type compatibility between roles?	Runtime crash (crewAIInc/crewAI#737)	T-Compose compile-time check
Does max_iter actually stop?	Not always (crewAIInc/crewAI#3847)	fix_n theorem guarantees termination
Will parallel roles overwrite each other?	Yes, no check	Store independence compile-time check
Max cost per run?	Unknown	Graded types (p, t, l, m)

CrewAI's advantage: Natural-language role definition; business stakeholders can understand it. λA's Lam("researcher", systemPrompt) is less readable than Agent(role="Researcher", goal="...").

Conclusion: Role-driven is syntactic sugar over λA's multi-agent extensions (GroupChat/Handoff), lacking formal guarantees.

---

2.3 Event-Driven (LlamaIndex Workflows / AgentScope)

Core idea: Agents publish events; other agents subscribe and respond. Loose coupling.

# LlamaIndex Workflows
@step
async def research(self, ev: ResearchEvent) -> AnalysisEvent:
    result = await llm.complete(ev.query)
    return AnalysisEvent(data=result)

@step
async def analyze(self, ev: AnalysisEvent) -> ReportEvent:
    ...

λA equivalent:

# Event = Channel (π-calculus name passing)
research_ch = Channel("research_results", capacity=5)
analysis_ch = Channel("analysis_results", capacity=5)

# Agent publishes to channel = Send
Send(researcher, research_ch)

# Agent subscribes to channel = Receive
Receive(research_ch, handler=analyzer)

λA's Channel + Send + Receive are π-calculus communication primitives — the formal foundation of event-driven architecture.

What λA adds:

Issue	LlamaIndex Workflows	λA
Event type compatibility?	Python type hints (optional)	Typed channels: Channel<Str, Json>
Deadlock possible?	Unknown until runtime	Channel capacity + bounded fixpoint → analyzable
Does event order affect results?	Uncertain	Pair confluence theorem: order-independent when stores are independent

Event-driven advantage: Natively async, loosely coupled, suits large-scale distributed systems. λA's Channels are currently in-process, not yet distributed.

Conclusion: Event-driven is the engineering realization of λA's π-calculus extension. λA provides formal communication semantics.

---

2.4 SDK Wrapper (OpenAI Agents SDK / PydanticAI)

Core idea: Thinnest possible wrapper — call LLM API directly, add tool calling and type validation.

# OpenAI Agents SDK
agent = Agent(name="researcher", instructions="...", tools=[web_search])
result = Runner.run(agent, "Find recent AI papers")

# PydanticAI — with type validation
@agent.tool
def search(query: str) -> SearchResult:  # ← typed!
    ...

λA equivalent:

# Atomic form = Lam + Tool
Lam("researcher", "You are a research assistant")
Tool("search", web_search)  # Type: Str →^io SearchResult

This is λA's atomic layer — a single Lam and several Tools.

PydanticAI's interesting property: It emphasizes type safety — tool inputs and outputs have Pydantic schema validation. This aligns with λA Paper III's T-Tool rule.

What λA adds:

Issue	OpenAI SDK	PydanticAI	λA
Single tool type validation	❌	✅ (Pydantic)	✅ (Json(S))
Cross-step type checking	❌	❌	✅ (T-Compose)
Cost prediction	❌	❌	✅ (graded types)
Composition semantics	None	None	✅ (6 algebraic laws)

Key difference: PydanticAI validates individual tool I/O but does not validate composition boundaries. λA's T-Compose verifies f >> g — that output(f) <: input(g). PydanticAI cannot do this.

SDK advantage: Minimal learning curve, official maintenance, good ecosystem.

Conclusion: SDK wrapper is λA's atomic layer (Lam + Tool). PydanticAI's type validation is a subset of λA's type system.

---

2.5 Low-Code Platform (Dify)

Core idea: Visual drag-and-drop to build agent workflows.

[Input] → [LLM Node] → [Condition Branch] → [Tool Node] → [Output]
                              ↓
                        [Another LLM Node]

λA equivalent:

Dify's visual workflow = YAML config, and from_config compiler translates YAML to λA terms:

Dify canvas workflow
    ↓ export
YAML/JSON config
    ↓ from_config()
λA term (Compose, Route, Loop, ...)
    ↓ type_check() + lint() + compute_grade()
Type errors / dead loop risks / cost prediction

What λA adds:

Issue	Dify	λA
Will the workflow run successfully?	Only after deployment	Compile-time type checking
Will a cycle deadlock?	Only at runtime	Lint L004 + termination theorem
Cost per run?	Check bill after running	Compile-time cost prediction
Are two workflows equivalent?	Cannot determine	Algebraic laws

Dify's advantage: Non-technical users can use it. λA's YAML config is also declarative but less visual than drag-and-drop.

Conclusion: Low-code platforms generate configs that are λA's compilation input. lambdagentpaas can serve as Dify's backend static analysis engine.

---

3. Unification: Five Paradigms as Five Special Cases of λA

                        λA (11 constructs + type system + effect algebra)
                       /        |          |          |          \
                      /         |          |          |           \
           Compose+Route    GroupChat    Channel    Lam+Tool    from_config
           +Loop+If         +Handoff    +Send/Recv  (atomic)     (YAML)
              |                |           |           |            |
              ↓                ↓           ↓           ↓            ↓
         Graph State       Role-       Event-       SDK          Low-Code
         Machine           Driven      Driven       Wrapper      Platform
         LangGraph         CrewAI      LlamaIndex   OpenAI SDK   Dify

Each paradigm uses only a subset of λA's 11 constructs:

Paradigm	λA Constructs Used	Not Used
Graph State Machine	Route, Loop, Compose, Tool	Guard, Memory, Pair, Channel
Role-Driven	GroupChat, Handoff, Compose	Guard, Channel, Route (explicit)
Event-Driven	Channel, Send, Receive, Pair	Route, Loop (explicit), Guard
SDK Wrapper	Lam, Tool	Nearly all composition constructs
Low-Code	YAML → from_config (indirectly all)	No direct manipulation

λA's unification: You don't need to choose "graph state machine OR role-driven." In λA, you compose 11 construct primitives to express exactly the pattern you need. A single agent can simultaneously use Route (graph-style dispatch) + GroupChat (role-style collaboration) + Channel (event-style communication) — because they are all composable Terms in λA.

---

4. Three Major Industry Shifts vs λA

Shift	Industry Status	λA Response
MCP tool-calling standardization	Frameworks adopting MCP	lambdagentpaas has mcp_client.py for consuming MCP tools, and exposes its own capabilities as MCP Server (integration-strategy.md)
A2A protocol emergence	Cross-framework agent discovery	lambdagentpaas has a2a.py (AgentCard) with λA type signature embedded in x-lambdagent extension field
Context Engineering	Context management becomes core competency	λA's Memory construct + mem e σ operational semantics + effect system's state(s) precisely tracks context access

---

5. The Four-Step Decision Tree vs λA's Answer

The industry suggests choosing a framework by: team tech stack → core use case → cloud platform → model preference.

λA's answer: you don't need to choose a framework.

Traditional:
  "I use Python → LangGraph or CrewAI?"
  "I need multi-agent → CrewAI or AutoGen?"
  "I deploy on AWS → which framework?"

λA approach:
  1. Write agents in any framework you prefer
  2. Add lambdagent-guard as a safety layer
  3. Get: type safety + cost prediction + termination guarantee + parallel safety

  The framework is an implementation detail.
  λA is the safety guarantee.
  Like writing code in any language but using git for version control.

---

6. Detailed Construct Mapping

6.1 Anthropic's Six Composable Patterns → λA

Anthropic's "Building Effective Agents" guide defines six patterns. Each maps directly to λA constructs:

Anthropic Pattern	Description	λA Term	λA Type Rule
Prompt Chaining	Sequential LLM calls with gates	f >> g >> h (Compose)	T-Compose: output(f) <: input(g)
Routing	Classify input → specialized handler	Route(c, {lᵢ: aᵢ})	T-Route: all branches return same type
Parallelization	Independent subtasks run concurrently	Pair(f, g) / AsyncPar(f, g, h)	T-Pair: effects use ∥ (max latency)
Orchestrator-Workers	Central LLM delegates dynamically	Handoff(selector, registry)	T-Route + dynamic dispatch
Evaluator-Optimizer	Generate → evaluate → refine loop	Loop(body >> Guard(eval, P), c, n)	T-Loop: A →^{εⁿ} A + T-Guard: {x:B\|P(x)}
Autonomous Agents	Tool-using loop with environment feedback	fix_n(λself.λx. case (lam p θ) x [tools])	Full ReAct = Y combinator + case dispatch

Key insight: Anthropic's six patterns are exactly the operational patterns that arise from composing λA's 11 constructs. λA provides the formal semantics that Anthropic's guide describes informally.

6.2 Additional λA Constructs Not Covered by Any Paradigm

λA Construct	What It Does	Which Paradigm Covers It?
Guard(a, P, k)	Output validation with retry	None — frameworks rely on ad-hoc try/catch
Memory(a, s)	Persistent state with typed store	Partial — frameworks have memory but untyped
fix_n bounded fixpoint	Guaranteed termination	None — all frameworks use while loops
Effect annotations ε	Track llm/io/state effects	None — no framework distinguishes pure from effectful agents
Graded types (p,t,l,m)	Static cost prediction	None — all frameworks only report cost after execution
Algebraic laws	Safe refactoring rules	None — no framework has equational theory

These six capabilities are unique to λA and not available in any of the five paradigms.

---

7. Practical Implications

For Framework Users

You don't need to abandon your framework. Use lambdagentpaas as a safety layer on top:

Your LangGraph code    → lambdagent-guard → Type errors caught before $$ spent
Your CrewAI config     → lambdagent lint  → Dead loops detected at compile time
Your AutoGen groupchat → lambdagent-guard → Empty-message loops auto-terminated
Your Dify workflow     → lambdagent lint  → Cost prediction before deployment
Your OpenAI SDK agent  → lambdagent MCP   → IDE shows inline warnings

For Framework Designers

If you're building a new agent framework, consider adopting λA's formal foundations:

1. Type your composition boundaries — when f >> g, check output(f) <: input(g)
2. Use bounded fixpoints — Loop(body, cond, maxSteps) instead of while True
3. Check store independence — before running agents in parallel, verify they don't write to the same keys
4. Annotate effects — distinguish pure, llm(model), io, state(key) at the type level
5. Compute cost grades — (probability, tokens, latency, cost) as static upper bounds

For Researchers

The five paradigms are empirical classifications. λA provides a formal unification:

We prove that the five mainstream agent architecture paradigms — graph state machine, role-driven, event-driven, SDK wrapper, and low-code platform — are respectively special cases of Route+Loop, GroupChat+Handoff, Channel+Send/Receive, Lam+Tool, and from_config in the λA calculus. λA, as a unified formal foundation, not only covers all five paradigms but also provides three static guarantees none of them offer: type safety (T-Compose), cost upper bounds (graded types), and termination (bounded fixpoint theorem).

---

8. Summary Table: What Each Paradigm Can and Cannot Do

Capability	Graph SM	Role	Event	SDK	Low-Code	λA
Define single agent	✅	✅	✅	✅	✅	✅
Sequential pipeline	✅	✅	✅	❌	✅	✅
Conditional routing	✅	❌	❌	❌	✅	✅
Parallel execution	✅	✅	✅	❌	✅	✅
Multi-agent discussion	❌	✅	✅	❌	❌	✅
Event-based communication	❌	❌	✅	❌	❌	✅
Dynamic delegation	✅	✅	❌	❌	❌	✅
Output validation + retry	❌	❌	❌	Partial	❌	✅
Compile-time type check	❌	❌	❌	Partial	❌	✅
Termination guarantee	❌	❌	❌	❌	❌	✅
Static cost prediction	❌	❌	❌	❌	❌	✅
Parallel safety proof	❌	❌	❌	❌	❌	✅
Effect isolation (test/prod)	❌	❌	❌	❌	❌	✅
Algebraic optimization	❌	❌	❌	❌	❌	✅
Formal equivalence check	❌	❌	❌	❌	❌	✅