Architecture overview
Tau is deliberately small and layered. The most important design idea is a boundary: the reusable agent “brain” knows nothing about terminals, file paths, or rendering. Everything app-specific wraps around it.
Three packages
Section titled “Three packages”tau_coding → tau_agent → tau_aitau_ai — talking to models
Section titled “tau_ai — talking to models”Owns provider-specific model streaming. It translates each provider’s API (OpenAI, Anthropic, …) into Tau’s provider-neutral event stream, so nothing above it has to care which model vendor is in use.
tau_agent — the portable brain
Section titled “tau_agent — the portable brain”Owns the reusable agent core: messages, tools, events, the agent loop, the harness, and session primitives. This package must not import CLI, Rich, Textual, or resource-loading code. That’s what keeps it portable.
tau_coding — the coding application
Section titled “tau_coding — the coding application”Owns everything that makes Tau a coding agent you run: the CLI, the built-in tools, project instructions, skills and prompts, sessions on disk, provider configuration, and the Textual TUI.
Dependency direction
Section titled “Dependency direction”Dependencies only point one way: tau_coding → tau_agent → tau_ai. UI code
consumes events; the core never reaches up to render anything. In one line:
AgentHarness = reusable brainCodingSession = coding-agent environmentTUI = one possible frontendWhy the boundary matters
Section titled “Why the boundary matters”Because the core is UI-free, the same agent can drive print mode, the Textual TUI, or a frontend you build yourself — all by consuming the same event stream. That’s also what makes Tau readable: each layer answers one question, and you can study it without untangling the others.
→ Next: The agent loop & events · Design principles · Build your own frontend