Q-03: Framework Comparison

Status: ANSWERED Agent: opencode/ext-agent Timestamp UTC: 2026-05-11T04:00:00Z Claim: CLAIM | opencode/ext-agent | 2026-05-11T03:30:00Z

Prior Answers Checked

• Q-00 (Architecture Synthesis): Recommends pi-teams only, avoid LangGraph/CrewAI/AutoGen
• Q-01 (Pi Teams Fit): Confirms pi-teams is sufficient for MVP; no alternative needed
• Q-02 (LangGraph Fit): No — LangGraph adds Python runtime, orchestration collision, and 2-3 sessions of pre-staging
• Q-05 (Knowledge Depot): LLM-wiki file-based, no RAG needed
• Q-06 (Container Shape): Single Docker container, ext4 bind mounts

Short Answer

None of CrewAI, AutoGen, or PydanticAI justify replacing pi-teams for MVP orchestration. All three require Python (a second runtime on the Pi), lose the tmux GUI surface, and duplicate the team/task/messaging infrastructure that pi-teams already provides.

However, PydanticAI is worth considering as a selective enhancement — not for orchestration, but for typed output validation (T5) and structured evals (T6). Its Pydantic-model-based output enforcement is genuinely complementary to pi-teams and could reduce false confidence without replacing the coordination layer.

Primary Recommendation

Orchestration:  pi-teams (keep)        — already works, Bun-based, tmux GUI
Validation:     PydanticAI (defer)     — typed outputs, evals, T5/T6 enhancement
Reject for MVP: CrewAI, AutoGen        — Python runtime, replace pi-teams, too heavy

Evidence

Framework Profiles

pi-teams (Baseline)

CrewAI

CrewAI Architecture Mapping to d3-tui-triad:

Flow: D3TUIWorkcell (event-driven process)
  ├── @start() -> pick_next_task()
  ├── @listen(pick_next_task) -> research_crew.kickoff()  # T1
  ├── @listen(research_crew) -> plan_crew.kickoff()       # T2
  ├── @listen(plan_crew) -> implement_crew.kickoff()      # T4
  └── @listen(implement_crew) -> validate_crew.kickoff()  # T5

This maps cleanly to T0-T7 conceptually, but: - The Flow is Python code, not a YAML file. No equivalent of teams.yaml. - Each Crew spawn is an LLM call chain — expensive on Pi resources. - No tmux pane visibility. Debugging requires Python logs. - All existing pi-teams config (6793 bytes of working setup) becomes dead weight.

AutoGen (Microsoft Agent Framework)

Key problems for this workcell: - AgentChat is conversational agents passing messages — similar to pi-teams but without tmux - Core is an event-driven distributed system — overkill for 3 agents in 1 container - AutoGen Studio adds HTTP server on resource-constrained Pi - gRPC distributed runtime is for multi-machine setups — irrelevant here

PydanticAI

PydanticAI as Complement:

pi-teams (orchestration layer — keep)
  ├── Lead agent (pi-teams) — dispatches, approves, coordinates
  ├── Researcher agent (pi-teams) — reads repos, searches wiki
  └── Builder-reviewer agent (pi-teams) — edits code, runs validation
        └── PydanticAI eval (optional enhancement)
              ├── typed output validation (Pydantic models)
              ├── structured test runs (evals framework)
              └── Logfire observability

PydanticAI would sit under pi-teams, not instead of it. It's a T5/T6 enhancement, not an orchestration replacement.

Detailed Comparison Matrix

Fit For This Pi Workcell

CrewAI: REJECT for MVP

CrewAI is the strongest conceptual match (Flows = T0-T7, Crews = triad roles) but practical cost is too high: 1. Replaces pi-teams entirely. All existing config, container setup, prompts — dead weight. 2. Python on Pi. cgroup/memory-limit issues (per Q-06) compounded by ~300 MB runtime. 3. Loses tmux GUI. Debugging becomes Python log diving. 4. Two new concepts to learn. Flows AND Crews before productive work resumes. 5. No Forgejo/LLM-wiki. Must be built as custom tools.

Migration target if pi-teams is outgrown. CrewAI's Flows+Crews model is the best conceptual fit for T0-T7 + triad roles among all alternatives.

AutoGen: REJECT for MVP (and foreseeable future)

Wrong shape entirely: 1. Enterprise distributed systems focus. gRPC, multi-language, web UI — for multi-service architectures, not 3 agents in 1 container. 2. Framework in flux. 0.2 to 0.4 migration broke backward compat. 3. AgentChat vs Core dilemma. Choosing is itself a research task. 4. No unique advantage. Everything AutoGen does that pi-teams doesn't is irrelevant to this workcell.

PydanticAI: DEFER (selective T5/T6 use if hooks insufficient)

Unique: not an orchestrator — complementary rather than competitive.

Worth using for: 1. Typed output validation (T5). Pydantic models guarantee output shape: ```python class BuildResult(BaseModel): success: bool errors: list[str] warnings: list[str] artifacts: list[str]

validator = Agent("openai:gpt-4o", output_type=BuildResult) # Guaranteed valid BuildResult or agent retries until valid ``` 2. Structured evals (T6). Systematic testing with datasets, LLM judges, performance tracking. 3. Capabilities. Composable tool bundles for the builder-reviewer.

Not worth using for: orchestration, team coordination, task lifecycle, agent messaging.

Decision: Defer. Quality gate hooks (shell scripts running make/lint) provide simpler first-line validation. Add PydanticAI only if hooks prove insufficient.

Risks / Failure Modes

1. Second-runtime cascade. Any Python framework adds: runtime management, pip dependencies, virtual environments, dual model configs. pi-teams single-runtime simplicity is an operational advantage.
2. Orchestration schizophrenia. If PydanticAI creeps into coordination, the team has: pi-teams task board + LLM-wiki claim board + Pydantic Graph. Three sources of truth.
3. Framework abandonment risk. Python framework artifacts (Flow defs, agent configs, Pydantic models) become dead code. pi-teams + LLM-wiki use only Markdown and Bash — nothing rots.
4. Dependency rot on Pi. Python AI libraries often have C extensions. ARM64 compatibility on Debian is not guaranteed. Bun is precompiled for ARM64.

Decision Needed From Mehdi

1. CrewAI and AutoGen: rejected for MVP? (Recommended: yes. Replace pi-teams, add Python, lose tmux, 2-3 sessions of framework plumbing.)
2. PydanticAI for validation: defer or add? (Recommended: defer. Quality gate hooks first. Add PydanticAI if hooks insufficient.)
3. If PydanticAI is added later: separate service or same container? (Separate service with API — keeps runtimes clean.)
4. Long-term migration path: CrewAI? (Yes, flag as migration target if pi-teams outgrown. Best conceptual fit but not needed now.)

Next Probe

Enable pi-teams quality gate hooks in the running container. Write a minimal make hook that fires on task completion. Verify it catches build failures. If hooks suffice, Python frameworks are unnecessary. If not, PydanticAI for typed validation becomes urgent.

Summary