Read the real project
Architecture, tests, working practices, shared files, and your selected specifications become evidence for a proposed fleet.
A project-aware AI fleet
TORCH studies your repository and goals, then proposes the sessions your work needs. Choose Codex, Claude, Pi, or another local runtime for each role—and keep the team coordinated as the project changes.
From project brief to checked work
Start with the repository. The proposed fleet stays yours to shape.
Built around your repo
Codex · Claude · Pi
Choose per session
Local-first control
Owner-shaped fleet
TORCH does not start from a fixed roster. It studies the repository and specifications you choose, then proposes a team you can split, merge, rename, or reject before anything is installed.
Architecture, tests, working practices, shared files, and your selected specifications become evidence for a proposed fleet.
Roles get explicit scope, exclusions, neighbors, checks, and worktree boundaries. Each session can use the runtime and model that fit its job.
As coordination grows, TORCH can recommend a lead or new specialist when there is real integration work to own. You review the evidence and approve every organization change.
Each long-lived session can focus on a coherent part of the project, while durable messages and shared records connect it to the rest of the fleet. The aim is less context thrash—not a set of agents trapped in silos.
Lower cache and context costs are a hypothesis TORCH still needs to measure.
TORCH tracks what passed, what is still a live gate, and which exact change the evidence covers. A working local scenario is not the same as a qualified production fleet.
Point TORCH at a Git repository and, if useful, a product specification. It prepares an evidence brief for a fleet proposal; installing or starting the team waits for your review and approval.
torch bootstrap \
--repo /path/to/project \
--spec /path/to/product-spec.md \
--output fleet-design-brief.json \
--json