What is civitas

Latin has two words for a city. The urbs is its walls and buildings. The civitas is its citizens: the community that governs itself and builds things together. Civitas is the second kind of city, for AI coding agents. It is one system, made of separate packages, in which agents are dispatched to work, run in their own sessions, talk to each other and to you, and leave every repository in a settled state.

Civitas is a design, not a package. Nothing installs “civitas”. It is the set of layers, vocabulary, and rules that the packages follow so they fit together. spikyuni is the organization those packages are moving to.

The agent plugins are moving to uni-* names under the spikyuni organization (decision 0006, decision 0008). This site uses the new names. Each package still ships under its old name today; Components lists both.

The problem

One agent in one terminal works well. The trouble starts when you want several:

• Work spans more than one session. A change in one repository turns out to need a change in another. Today you find the other pane, or start a session there, and carry the context across by hand.
• Reports go to the wrong place. When agents spawn other agents, the result has to come back to someone who can act on it, even if the session that started the work has gone.
• Conversations vanish. What agents decided, asked, and answered lives in transcripts that end with the session.
• Repositories drift. A fix lands in the code while the specification, docs, and tickets around it still describe the old behaviour.

The shape of the answer

Four concerns, each in its own layer, each usable on its own:

Layer	Answers	Packages
Fleet	Who does the work, and who owns which part of it	uni-fleet
Runtime	Starting, stopping, and waking agent sessions	uni-legion, uni-mux
Communication	Where agents and people talk, durably	cynapse
Process	How a change reaches a settled, consistent repository	uni-truss, uni-sdd

Systems of record stay where they are. Issues stay in GitHub, tasks in Asana or Linear. Civitas refers to them and writes back what their readers need to see, and never copies them.

Layers sets out who owns what and which way the dependencies point.

Civitas and truss

Truss is a separate design idea: the convergence layer, the lattice that holds a repository in its settled state across every change. Civitas places it in the process layer, and leaves its model to truss. Truss keeps its own repository, cyber-truss, moving to uni-truss, and its own documentation at cyberuni.github.io/cyber-truss.

What it is not

• Not an MCP server and not a daemon. State lives on the filesystem and in local stores. Agents act through command-line tools and skills.
• Not tied to one harness. Claude Code, Cursor, and Codex all take part.
• Not one package. Each layer ships separately, so you can take the runtime without the fleet, or the communication channels without the runtime. See Using parts on their own.

Where it came from

The packages were built in cyberuni, where the first four (cyber-mux, cyber-truss, cyberlegion, cyberfleet) were called the Agentic Development Life Cycle stack. The whole system was first named cyber-arcology, after the single structure that holds a city. It was renamed cyber-civitas because what holds it together is the community, not the building.

Decision 0006 retired cyber-civitas and cyber-arcology as brands: the agent plugins take the uni- prefix and move to the cyberuni-agent organization. Decision 0008 moved that organization to spikyuni. The design keeps the name civitas. The repositories still live in cyberuni until each one moves.