# 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](https://www.anthropic.com/research/building-effective-agents), [2025 AI Agent Architecture Survey — Zhihu](https://zhuanlan.zhihu.com/p/1945267976937926834), [Anthropic Multi-Agent Research System](https://www.anthropic.com/engineering/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.

```python
# 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.

```python
# 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.

```python
# 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.

```python
# 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 `Tool`s.

**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** | ❌ | ❌ | ❌ | ❌ | ❌ | **✅** |