What Is Zozo?

TL;DR

Zozo turns software ideas and GitHub Issues into Pull Requests: the Runtime edits and tests the code, then the Dispatcher pushes the committed changes and opens the Pull Request. Start with an Intake Session when an idea needs refinement, or label a complete Issueready-for-agent. Your dedicated hosted Stack keeps working when you close your laptop and protects your Credentials.

Zozo is a Harness for sustained software work with coding agents. You bring an idea or a ready GitHub Issue. Zozo prepares an isolated checkout, runs the coding agent, streams progress to the Dashboard, and returns a Pull Request for review or Landing.

Zozo works with vendor coding-agent Runtimes such as Claude Code and Codex. You connect your own Credential, choose which Provider a Project uses, and keep the Runtime's built-in agent loop and tools. Zozo adds durable orchestration around that loop.

From Idea to Pull Request

Most work follows the same path:

1. Bring an idea. Start an Intake Session when the idea still has open questions, or write a complete GitHub Issue yourself.
2. Make the work ready. Intake asks focused questions and produces a structured Issue Plan. When you confirm it, the DispatcherPublishes the plan as GitHub Issues. A hand-written Issue can join the Frontier directly with the ready-for-agent label.
3. Dispatch the Issue.Auto-dispatch watches your active Projects and selects eligible Issues when capacity is available. The Dispatcher creates a Managed Worktree, an isolated checkout and branch for the attempt, then opens a Thread and starts a Run.
4. Implement and verify the change. The Provider launches its Runtime in the Managed Worktree. The coding agent reads the Issue and repository, edits the files, runs the project's build and tests, and commits the completed implementation.
5. Follow the work live. Every Run appends Events to the Thread's journal. The Dashboard renders those Events as the work happens.
6. Open and land the Pull Request. The Dispatcher verifies that the attempt produced committed changes, pushes the branch, and opens a Pull Request that closes the Issue. The Project's merge policy leaves it open for your review or sends it through Landing, which verifies the tested commit against the Pull Request's target branch before merging.

If a load-bearing decision is absent from the Issue, documentation, and codebase, the attempt enters Clarification. It asks you on the same Thread, preserves the existing work and context, and continues after you confirm the answer.

See The Core Loop for both routes into the workflow and the complete implementation path.

What Zozo Adds

A vendor Runtime already knows how to reason, use tools, and edit code. Zozo turns that capability into a hosted service for dependable Project work:

• Work that outlives your laptop. Your dedicated Stack runs remotely, so the Dispatcher keeps selecting eligible Issues after you close the Dashboard or put your laptop away. Come back later to the durable Thread history and the Pull Requests it produced.
• Durable state. Threads and their append-only Event journals remain the source of truth. A vendor Runtime's native session is a disposable cache.
• Visible progress. The Dashboard renders each Run from the same journal used for streaming, recovery, and history.
• Project automation. The Dispatcher watches your repositories, selects eligible Issues, creates isolated Managed Worktrees, starts the coding Runs, and opens the resulting Pull Requests.
• Human checkpoints. Intake refines an idea before implementation, and Clarification asks for a consequential missing decision during an active attempt.
• Credentials that go straight to your Stack. Your browser sends each Credential directly to your dedicated Stack, where it stays in a secured store outside the Event journal. The shared Control Plane receives status and usage, but never the Credential value. See Data & Privacy for the full boundary.
• Isolated execution. Each Run executes inside a disposable Cell, an isolated environment for the Runtime process. The Permission Policy controls what the agent may do. The Server, which exposes the Harness over HTTP, stays on loopback behind the authenticated Dispatcher.
• Managed updates. Zozo applies hosted releases in health-gated waves. Your Stack waits for active work to finish, takes a local backup, applies the update, verifies its health, and automatically reverts a failed update.
• Explicit control. Provider choice, Credentials, Permission Policy, General Concurrency, and merge behavior stay visible and configurable.

Choose Your Next Step

• To see the product workflow end to end, read The Core Loop.
• To set up an invited hosted account and dispatch your first Issue, follow Quickstart.
• To understand Providers, Runtimes, Threads, Runs, and Events, read Core Concepts.
• To learn how Zozo selects eligible work, read How Dispatch Decides.
• To add a repository and choose its operating pace, follow Watch a Project.
• To understand the shared Control Plane and your dedicated Stack, read Two Surfaces.