Three open projects people lump together as "AI coding agents" — but they sit at different layers of the stack: a methodology + engine, a toolkit, and a cloud platform. Side-by-side evaluation plus how they fit together.
Local-first Rust Multi-provider QRPBA
An autonomous pipelined builder that runs the
Query → Research → Plan → Build → Audit stages over a
TASKS.md queue, with per-stage model routing across provider CLIs
(Claude / Codex / Copilot), a pattern-and-skill learning store, and a
fresh-context Doubt audit. Runs as a TUI, headless, a build
service, or a GitHub Actions agent.
/Users/Shared/homelab/context-foundry
MIT TypeScript ~53k stars Multi-provider
A self-extensible agent harness — a monorepo of building
blocks: pi-ai (unified multi-provider LLM API), pi-agent-core
(tool-calling runtime + state), pi-coding-agent (interactive CLI),
pi-tui (terminal UI), plus a Slack bot and vLLM pods. Interactive-first,
hackable, with a large community and heavy supply-chain hardening.
MIT TypeScript ~5.5k stars Vercel
A template/platform for cloud agents:
Web → Agent workflow → Sandbox VM. Its headline rule is
"the agent is not the sandbox" — the agent runs outside an
ephemeral Vercel Sandbox and drives it through tools. Ships a web UI, Better Auth,
a GitHub App (clone / branch / commit / push / PR), durable Workflow-SDK runs, and
hibernate/resume sandboxes.
| Feature | Context Foundry | pi | open-agents |
|---|---|---|---|
| Category | Autonomous build pipeline (engine + methodology) | Agent harness / toolkit (libraries + CLI) | Cloud-agent platform / template |
| One-line purpose | Drive a project through a structured, audited build loop | Give you primitives to build or embed an agent | Host an agent as a background cloud service |
| Primary mode | Autonomous (unattended task queue) | Interactive (you drive the CLI) | Background / async (kick off → get a PR) |
| Where it runs | Your machine, an Actions runner, or foundry serve |
Wherever you run the CLI / embed the libs | Vercel: durable workflow + ephemeral Sandbox VM |
| Agent vs. sandbox | Agent runs where the code is (CLI orchestration) | agent == local FS (edits the dir it runs in) |
agent ≠ sandbox — drives the VM via tools |
| Work intake | TASKS.md queue; Discovery appends new tasks |
Interactive prompts / Slack (pi-chat) |
Web chat / prompt → a workflow run |
| Prescribed stages | Explicit QRPBA stages with skip/defer indicators | None — you compose the loop | None — chat-driven agent turns |
| Per-stage model routing | Yes — e.g. Opus on Plan, Codex on Build | N/A — one agent; pick a model | N/A — may select the run's model |
| Audit / review | First-class Doubt: fresh-context auditor + HIGH/MEDIUM gate | None built-in (it's a runtime) | Human reviews the diff / PR |
| Memory / learning | Skill + pattern store fed back into Plan | None — shares sessions as OSS training data | None — snapshots/resume the sandbox, not learning |
| Model access | Spawns provider CLIs + a GhCopilot HTTP provider | pi-ai — unified provider HTTP API |
AI SDK / provider |
| Multi-provider | Yes (CLI routing per stage) | Yes (first-class, core selling point) | Provider-configurable |
| Repo / PR integration | feat()/WIP() commits; Actions fork opens PRs |
You wire it (or via pi-chat) |
Built-in GitHub App: clone, branch, commit, push, PR |
| Sandbox / isolation | Git worktrees, sandbox modes, per-run .buildloop/ |
N/A (runs in place) | Ephemeral VM with hibernate/resume + base snapshots |
| Frontend / UI | Rust TUI + dashboard + headless JSON stream | CLI, TUI library, Slack | Web app (chat, streaming, read-only session sharing) |
| Self-hosted? | Yes — your machine / infra | Yes — it's libraries + a CLI | Yes — deploy to your own Vercel |
| Language | Rust | TypeScript | TypeScript |
| License | See LICENSE in repo |
MIT | MIT |
| Community / scale | Small (homelab project) | Large (~53k stars, Discord, HF session datasets) | Growing (~5.5k stars, Vercel-backed) |
| Distinctive trait | QRPBA + adversarial audit + cross-project learning | Unified LLM API, self-extensible, supply-chain rigor | "Agent is not the sandbox" + durable workflows + managed sandboxes |
| Cost | Free + whatever provider API you use | Free + provider API | Free + Vercel compute + provider API |
They occupy different layers, so they stack rather than compete. pi is the brain + hands (an agent runtime, a unified LLM API, and tools). open-agents is the operating environment (a web frontend, auth, durable orchestration, an ephemeral sandbox with hibernate/resume, and the GitHub-App PR flow). open-agents needs some agent to run inside its workflow layer; pi is exactly that kind of agent.
They overlap in one band — the agent runtime + model access — so if you combined them you'd pick one brain, not run two. Everywhere else they're complementary: open-agents gives pi the cloud platform pi lacks; pi gives open-agents a hackable, multi-provider agent it can host instead of its default one.
agent == local — it edits the filesystem it runs
on. To run pi faithfully inside open-agents you keep pi-agent-core in the
workflow layer but rebind pi's tools from the local FS to the Vercel Sandbox API.
The simpler alternative — drop the pi CLI inside the sandbox — works but forfeits
open-agents' main benefit: an agent whose lifecycle is independent of the sandbox.
Context Foundry is the opinionated, autonomous cousin. Two things set it apart
from both: it prescribes a methodology (QRPBA with a real audit gate and learning),
and it brings its own execution — a GitHub Actions runner or foundry serve
— so it doesn't need open-agents' sandbox, and it orchestrates provider CLIs
rather than embedding a library like pi-agent-core. In stack terms: open-agents is a
platform, pi is a toolkit, Context Foundry is a methodology with its own engine. You could
imagine QRPBA running as the "agent" inside open-agents, or rebuilt on pi's runtime — but
today it's self-contained, which is the lighter path for GitHub-native adoption.
CLAUDE.md/SPEC.md/TASKS.md, pi's AGENTS.md, open-agents' GitHub-App config).