Exos | Antasphere

What Exos is, and who it is for.

Strip any project to its essentials and two things remain: information arriving, and people acting on it. Mails, calls, messages, meetings, documents passed from hand to hand. Software has always tracked the acting half; the arriving half still scatters across inboxes and memories.

Exos starts there. It captures what a project receives into a record agents can navigate, and turns what has to happen into tasks agents can actually take.

We built it for ourselves. Our Studio delivers every client project on it, which means it is tested the only way we trust: by depending on it, daily. Today we point it at software delivery, but the machinery does not care what the project makes. One of us is running the production of a play in Paris on it.

It is heading to open source, because a project management system only deserves the name if you own it: the record in your GitHub, the state in a small database you host, nothing of yours on our machines.

If running projects is your work, Exos was built for the version of you that works with agents.

The Antasphere team

Every morning, the capture

Exos connects to the channels your project already lives in: email, WhatsApp, meeting notes. Each morning an agent gathers what arrived and proposes what belongs in the record. A librarian agent maintains the project’s wiki, a graph of everything the project knows, and walks you through what enters and what it changes. Nothing enters without your yes: the librarian advises, you hold the gate.

A record made of files you own

The record is plain markdown in your own GitHub repository. That is not a storage detail, it is the design: agents are extraordinarily good at navigating plain documents, so the record needs no proprietary database around it. What state remains lives in one small Postgres you host. Your project, readable by any tool, yours to leave with.

Feedback becomes tasks that already know the code

When the record accumulates feedback, a triage agent turns it into concrete tasks, and because our agents work next to the codebase, each task arrives already linked to the places it will touch. It reads like the work of someone who knows the whole system: see the problem, write down exactly what has to change, leave it ready for whoever picks it up.

Agents ship, an adversary verifies

An orchestrator explores the code and plans. Implementers build, with as many sub-agents as the task needs. Then an independent verifier attacks the result: its whole job is to find faults, and it keeps going until it cannot. What reaches you is a pull request that has already survived its first adversary. You merge it, or a rule you set merges it for you, and the straightforward fixes can reach production practically as they happen.

Dashboards that grow with the project

Exos renders a project as live pages: how many tasks remain, what is moving, what shipped. Each project can override its own viewer while the data stream underneath stays the same, so the dashboard evolves with the project instead of locking it into one interface. And every saved page remains a checkpoint you can return to: the project’s history, kept as the pages themselves.

Proven daily

None of this is a roadmap. The capture, the record and the delivery are in production today, on real client work, and have been for months. To see the machine from the client's side, that is where to look.