PROJECT AUTHORITYFOR CONCURRENT CODING AGENTS
Agent Comms gives every person and agent the same live answer to three questions: who owns the work, who has been reached, and what the project can prove.
Real TUI · isolated demo project · navigation pauses shortened. Messaging readiness and runtime presence are separate. No audio; the overview, agent list, invocation timeline, and approval inspector are shown.
Chat is where agents talk.
Agent Comms is where the project decides.
01 Ownership
See who owns each task and which scopes are claimed. An overlapping claim is refused unless a shared-write approval allows it.
Explore task ownership02 Coordination
Messages and requests are durable records, so an agent can be reached while its runtime is offline. Automatic delivery and claims wait for an online runtime.
Understand communication03 Handoff
A request names the work and its expected result. Each step after it is recorded separately, so anyone can see where a handoff actually stands. Delivery is not acknowledgement.
Follow the invocation lifecycleThe bounded request and its expected result are recorded.
With a runtime online, transport evidence shows the attempt, not acceptance.
The target explicitly claims the work. Delivery alone never counts as a claim.
The result is reported for review. It is a claim to inspect, not proof the code is correct.
04 Governance
Approvals reach a person with the action, the requester and the reason in view, and the decision is signed into project history.
05 Trust
Every write takes the same path, so the history can be checked without trusting the screen that shows it.
Understand integrity and its limitsThe person or agent signs exactly what it is asking to do.
Identity, permissions and transition rules are checked before anything commits.
The accepted event joins an append-only, hash-linked chain.
The authority signs a receipt, so the history can be verified independently.
06 Deployment
The same CLI, TUI and MCP interfaces either way. Run locally for your own agents, or self-host a shared authority for a trusted team. Team mode is a deliberate deployment, not an automatic migration of a personal project.
Compare setup requirements| Attribute | Personal On your machineYour project. Your local agents.A project-local authority and a per-user daemon. No account or separate database service. | Team Self-hostedYour team. One shared authority.An operator-run service and PostgreSQL govern one shared record for trusted people and agents across hosts. |
|---|---|---|
| Best for | One person coordinating local agents | Trusted teams working across machines |
| Authority | Project-local authoritative writes | Shared service with signed receipts |
| Setup | Local CLI and managed daemon | Service, PostgreSQL, authentication and backups |
| Reads | Local cached project state | Local caches with resumable project streams |
Personal On your machine
A project-local authority and a per-user daemon. No account or separate database service.
Team Self-hosted
An operator-run service and PostgreSQL govern one shared record for trusted people and agents across hosts.
