Explanation
Why Switchboard is shaped the way it is: constraints, rejected alternatives, and the decision record behind each choice.
The contract is elsewhere: docs/reference/specs/.
The system
- Architecture — the request path and where the parts run.
- How model calls use capacity — the queues, permit lifetimes, follow-ups and benchmark proof.
- How a request flows — text, model turns and code checks.
- Data model — threads, runs, pipelines and their durable records.
- What an agent is — the eight work profiles and when to add one.
- Worker topology — the bot plus three Workers.
- One definition, every surface — one command becomes chat, CLI, HTTP and MCP.
- Runs: live and recorded — live progress and finished history.
- A thread outlives its runs — the shared conversation and agent working logs.
- How agents keep context — research, phase notes, focused child context and recall.
- Why config is layered — six layers, effort included.
Trust
- Security model — what a compromise of each piece yields.
- Execution and trust — where
bashruns.
Running it
- Capacity and sizing — why the containers are the size they are.
- Known limits — off, narrow, or not yet proven.
The project
- How Switchboard improves itself — friction → pattern → issue.
- How we work — spec, test, PR, agent review, release.
- Design decisions — the records.