Explanation
Why OpenSwitchboard 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 parts, in three diagrams.
- How a request flows — one pipeline for every entry point.
- The agents and their toolsets — five agents and what each may reach.
- Worker topology — the bot plus three Workers.
- One definition, every surface — one command becomes chat, CLI, HTTP and MCP.
- Runs: live, then remembered — a run's two lives.
- 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 OpenSwitchboard improves itself — friction → pattern → issue.
- How we work — spec, test, PR, agent review, release.
- Design decisions — the records.