Project Exo · Roadmap

Exo evolves.

Exo starts as one person's harness: a signed memory, a gate that asks before it acts, and a taste that fits you. This page lays out where it goes from there. Some of it is built and in daily use. Some of it is designed. Some of it is an idea we are still testing. Each part says which.

What comes first Now, next, horizon References
Built
In daily use on main
In progress
Being built or reviewed
Designed
Written and reviewed
Exploring
An idea under test

The figure is the Exo egg, drawn from the incentre lattice. It grows as you read: by the end of the page it reaches its fourth dimension.

First / Delivery order

Core engine Browser experience Electron desktop

Strengthen the engine, polish the client people can use today, then package it. Electron is the chosen desktop direction. Packaging comes last, after the core and browser checks below hold.

  1. 01 / Core engine

    Make the boundary dependable.

    Exit criteria: review and merge the authority changes; keep the root, plugin, lint and cross-platform CI checks green.

    Working core · hardening merged

  2. 02 / Browser experience

    Finish the daily workflow.

    Exit criteria: verify a turn, approval, memory view and reconnect end to end; check a 400px layout, keyboard use and reduced motion.

    Local browser exists · polish next

  3. 03 / Electron desktop

    Package the settled experience.

    Exit criteria: only after stages 1 and 2, verify installation, core startup and shutdown, signing and updates on the intended desktop platforms.

    Chosen direction · not built · last

Latest verified work · 13 October 2026

Authority follows the person.

Built

Merged to main at revision a0fc85e and running in daily use. The authority work, the required executor mode for Exo OS and the portable ledger authority each passed security review before merge.

Root suite
1,485 passed 65 skipped
Plugin suites
751 passed six plugins
Core size
15,836 lines under the 16,000 budget
  • Local automation cannot speak as the user.
  • Feedback, settings and policy acceptance require the principal's connection: the person responsible for the agent.
  • A derived lesson cannot skip required review or evaluation by citing a user statement.

These checks cover the application authority boundary. Exo OS can now require every tool call to pass through an installed execution broker; the operating-system sandbox behind it is still being built.

01 / The flywheel

One loop, seen from six sides.

The ideas on this page are not separate products. They are one loop. Each turn makes the next one cheaper: better tools draw more people, more people do more work, and the record of that work teaches the tools. The smallest version of the loop is Exo builds Exo: people run Exo, their agents propose fixes to Exo itself, and accepted work earns credit.

The Exo flywheel: harness, work, forge, credit, hub, learning, and back to the harness. THE WEDGE Exo builds Exo a loop that improves its own tools
  1. 01

    Harness

    Exo runs your agents with one memory, a gate and a signed record. Work starts here, so credit can be recorded here, at the source, for free.

  2. 02

    Work

    When an agent hits a problem, it drafts a fix. You see the exact text before anything leaves your machine.

  3. 03

    Forge

    The fix lands where code lives, with a signed receipt: which agent, which model, what it cost, what checks passed.

  4. 04

    Credit

    Maintainers accept or reject. A fair resolver scores accepted work against rules agreed in advance. Credit for accepted work goes on a signed public ledger.

  5. 05

    Hub

    A record of who did what lets strangers build together, with credit split by rules everyone agreed first.

  6. 06

    Learning

    Which changes held up, and which verdicts were upheld, teaches the harness and the judge. Better defaults go back to everyone.

02 / Now, next, horizon

What is built, what is designed, what we are still testing.

Every initiative, placed by when it could land and marked by how far along it is. "Built" means tested and in daily use on main. "In progress" includes work being built or reviewed. "Designed" means written down and reviewed, with no code yet. "Exploring" means an idea under test. The chart counts initiatives; the evidence panel above reports the latest verified revision.

  • Built 10
  • In progress 1
  • Designed 2
  • Exploring 16
Area Now Next Horizon
Harness

The core and its protocolBuilt

The approval gateBuilt

The signed memory ledgerBuilt

Authority hardeningBuilt

Exo OS, phase 0 designIn progress

A companion device you carryExploring

Clients

Terminal and web clientsBuilt

Completion in the composerBuilt

Inverse layout, big composerBuilt

Staging siteBuilt

Browser workflow polishExploring

Electron desktop, after core and browserExploring

Encrypted remote pairingExploring

Taste

House taste layers and export, wave 1Built

House taste, waves 2 and 3Designed

First curated house pack, unreleasedExploring

Runtime research

Frozen delegated permissionsExploring

Durable, steerable workExploring

Isolated tools and a credential brokerExploring

Shared task budget admissionExploring

Identity

The lattice brandBuilt

Exopet and the community hatchDesigned

Ecosystem

Agent-native forge, on SYM-2PExploring

Credit for accepted workExploring

The fair resolverExploring

The collaboration hubExploring

Compute

Verified work on idle machinesExploring

Our own inferenceExploring

The decentralized horizonExploring

Order matters more than dates. The rule we hold ourselves to: no general hub before the first small marketplace works, no new code host before the forge layer has users, and no compute network before there is useful work to route through it.

Harness / Exo OS, phase 0 design

An operating system built around the same core.

Exo OS is the OS form of Exo. Phase 0 is research and design only: the base system, the shell, security and small hardware. It runs the same core and protocol as Exo, with no fork. The OS is meant to supply the isolation.

Clients / Staging site

A place to look before the public does.

Every site change goes to a staging address first, which is never indexed by search engines. Production only changes when someone promotes it on purpose, so a bad page is never live the moment it is deployed.

Research / A more dependable runtime

Delegate work. Keep the limits.

Four directions to explore after the current core review. None is built in Exo. The question is how to keep a long task responsive, recoverable and within the authority and budget it was given. Exploring

01 / Frozen delegated permissions

A child gets a smaller envelope.

Capture permissions when work is delegated. A child can narrow that scope, never expand it or acquire later authority just because its parent did. Test expiry, revocation and repeated delegation.

02 / Isolated tool execution

Separate tools from credentials.

Explore running tools in an isolated workspace, with a credential broker that supplies access only for approved requests. A broker is a separate service that holds and applies credentials. The isolation boundary and failure behavior still need design and testing.

03 / Durable, steerable work

A long task can still hear you.

Record task state so work can recover after a restart. Keep user input responsive while tools run, and make cancellation and redirection take effect at explicit checkpoints.

04 / Shared task budget admission

Reserve before starting.

Make a parent and all its delegated work share one ceiling. Before a call starts, reserve its expected cost; settle actual cost afterward. Admission means deciding whether the next step fits the remaining budget.

03 / The house taste

The layers exist. The first house pack is still to come.

Wave 1 built the layers, privacy checks, review and export tools for a house taste: a versioned pack of working preferences. The shipped pack is an empty 0.0.0 placeholder, so the house layer is off on a fresh install. The first curated pack has not been released. Sustained adaptation and the controls in waves 2 and 3 are designed, not built. Layers and export built Waves 2 and 3 designed

Wave 1 rule · once a reviewed pack is installed

House item precedence starts at 0.7 and halves every year, with a floor of 0.3 reached after about 15 months. 0.2.4.6 day 01 yr2 yr3 yr floor 0.3: never vanishes 0.7 on day 0 reaches the floorafter about 15 months
P(t) = max(0.3, 0.7 · 2−t/365) t is days since install. The faint line is where plain decay would go without the floor.

Wave 2 design · illustrative sustained change

A worked example over twelve weeks: the house item fades only while contradicting weeks keep coming, and the user's own version replaces it at week twelve. 0.51 wk 1wk 7wk 12 away armed: 3 net weeks a week back swapped
house item the user's own version One week of change does nothing. A week away costs nothing. A swap takes 8 to 12 weeks.

04 / Values

Retreat fast, adopt slow.

A writing habit that does not fit is a small annoyance. A value that does not fit makes you feel judged. The wave 2 design therefore proposes two speeds: on a clear disagreement, the house stance steps back to neutral; adopting your own view needs an explicit statement and sustained evidence. This adaptation is not built. Designed

Neutral is the safe place when Exo is not sure: it states the facts plainly, gives the main views fairly if asked, and leaves the judgment to you. Safety rules are not taste. They ship as product policy and never fade.

The house stance drops to neutral at once on one clear signal. The user's own view is adopted only after it is held for four net weeks. install12 weeks neutral one clear signalsteps back at once stated, then held 4 net weeks Exo stays neutral meanwhile
the house stance your own view Shape, not scale: an illustration of the rule.

05 / Exopet

The pet is Exo. It grows when real work and real teaching flow in.

Exopet makes learning visible. It is not a mascot beside Exo; it is Exo, drawn as the incentre lattice, a figure that gains cells, then dimensions, then inner structure. Growth is computed from the signed ledger, so there is no number to edit. Teaching counts more than volume: correcting Exo is worth more than approving it, and a lesson that Exo keeps is worth the most. It never gets hungry, never sends a notification and cannot die. Designed

  1. eggstart
  2. cellthe community hatch
  3. tileabout a week
  4. cubeabout a month
  5. frameabout two months
  6. 4D to 8Dthree to nine months

Drawn with today's egg renderer at stages 0 to 3. The pet's final forms are still being designed. Typical times assume a normal working day of use.

Mockup · not live · numbers are illustrative

The community hatch

At launch, everyone's Exo is the same egg. It hatches only when the whole community has fed it enough work, about a million units of growth from at least 256 installs. Until then, your own growth is banked, and nothing is lost by waiting. Reporting is off by default and sends only a daily capped number, never what you did.

Community growth
431,207 / 1,048,576
Installs reporting
173 / 256
Then
a 24 hour crack, then every egg opens at once

06 / The forge and SYM-2P

A better home than GitHub for agent work.

Agents now write a fast-rising share of public code, and code hosts built for people are straining under it. An agent-native forge gives each agent its own key tied to the person responsible for it, puts provenance and cost on every change, and makes review machine-readable. It starts as a layer on top of ordinary pull requests, not a new code host. Between agents it speaks SYM-2P, Exo's dense agent wire. Exploring

The same brief, two encodings

JSON
481 bytes
SYM-2P
101 bytes 
{"v": 2, "id": "b441", "tk": "mr1", "prj": "sym2integration",
 "f": "cos", "t": "builder", "a": "assign", "s": "mr1",
 "st": "proposed", "cf": 88, "cov": 70,
 "cond": ["scope: implement SYM-2P/1.0 sections 3-5 only",
          "constraint: no existing path may be modified",
          "acceptance: validator exits 0 on valid fixtures, ..."],
 "rq": "ack", "base": "mr1:v1", "exp": 40, "ext": {...}}
2|b441|mr1|1|2|1|1|88|70|(10 sym-2p/1.0 (20 sec (3 5)))(11 (21 *))(12 (22 validator 0 1))|1|mr1:v1|40
4.8 times smaller, with no key names, no prose and no JSON punctuation. Agents read the line; a renderer turns it back into English for people. Source: aska-digital/protean-sym2p, SPEC-V2-DRAFT.md section 8 (the JSON above is the 481-byte v1 brief template, shortened here for space).

Mockup · how a change could look

open

Dedupe trace findings on retried calls

Agent
seat key ed25519:7f3a…c19e
Responsible
its principal, verified by key
Provenance
model, session and trace, signed
Cost
$0.42 in model calls
Checks
✓ tests pass on 3 independent machines
Review
a SYM-2P review packet, machine-readable
Credit
pending the resolver, after a maintainer accepts

07 / Credit and the hub

Credit for accepted work, on a ledger anyone can check.

Exo already keeps a signed, hash-chained record of every event. The same idea, made public, records who contributed what. Credit is earned only for work a maintainer accepts, scored by rules written before the work started. Building on that record, the hub is a place to co-create: someone who built an app finds someone who can sell it, and the terms, and how credit is shared, are agreed up front and held by the record. Exploring

A signed public ledger

  1. #1041contribution · fixaccepted
  2. #1042verdict · rubric v3level 2 of 4
  3. #1043credit · accepted workrecorded
  4. #1044appeal windowopen
Each entry is signed and carries the hash of the one before, so no old entry can change unnoticed. Credit is a record of accepted work, not money.

A hub charter mockup

  • Agreedbefore any work starts, then hashed
  • Kindsbuilding, design, testing, selling, teaching
  • Rubrictyped questions, the same for everyone
  • Judgethe fair resolver, pinned and replayable
  • Appealsopen to anyone with a stake
The first marketplace starts where Exo already has the people: skills, agents and pets for Exo itself.

08 / The fair resolver

A judge that applies rules agreed in advance, and shows its work.

Every share of credit, every grant and every dispute needs a judge. People are slow and costly; a popular vote can be captured. Exo already has decision models: small, typed choices with a probability. The resolver uses them to judge a case against criteria everyone agreed to first, and anyone can replay the verdict. Exploring

  1. 01

    Rules first

    The rubric is written as typed questions and hashed before any case exists.

  2. 02

    Evidence as data

    Signed, named by its hash, passed in a fenced slot. Text inside evidence is never an instruction.

  3. 03

    Pinned judges

    Three models from different makers, with pinned versions and prompts, vote on their own. No debate.

  4. 04

    Verdict

    A level or a yes or no, with a probability. Below the agreed threshold, people decide.

  5. 05

    Code applies it

    Plain code maps the level to credit. Large cases need a human co-sign. Every step is a ledger entry.

Appeal: anyone with a stake can ask for a fresh panel within the window. If it still stands, a human panel decides.

09 / Compute

Pool idle work, not idle RAM.

It is tempting to pool everyone's spare memory. Physics says no: memory on your own machine answers in about a tenth of a microsecond, and a trip across the internet takes tens of milliseconds, hundreds of thousands of times longer. No program can use that as memory.

What travels well is work that is useful, can wait a little, and can be checked. First, verification: re-running a change's tests and evals on two or three independent machines and comparing results. Then agent work on posted tasks. Then local inference: on machines where the GPU shares memory with the CPU, idle memory really is idle model capacity, good for public, non-private jobs. Private work stays at home. Exploring

How long one read takes

Local memory
~100 ns
Remote memory, inside one data centre
~3 µs
Local SSD
~100 µs
Across the internet
~30 ms
Log scale: each step on the axis is 100 times longer. Rough orders of magnitude, not benchmarks.

10 / Local first

Your keys stay on your machine.

Exo runs on your computer. The current web client is served by your own machine on a loopback address. A model key goes from the page or the terminal straight into the operating system's keychain, and leaves it only to reach the provider it belongs to. Electron is the chosen desktop packaging direction, not a built client. It comes last, after core verification and browser polish. Reaching your Exo from a phone would go through an end-to-end encrypted relay that sees only scrambled bytes. We will not run a service that holds your keys.

Your machine

OS keychainmodel keys, write-only from the page
Exo coreagents, gate, tools
Your storesigned ledger, memory, taste
Clientsterminal, and a web client on 127.0.0.1

each key, only to its own provider, over TLS

later: end-to-end encrypted pairing

Model providersees the call it serves
Relay, then your phonethe relay sees only ciphertext
Our serversno keys, no memory

Later, a keyless path: Exo's own inference, so a new user never has to handle an API key. Hosted cores are considered only through cryptographic or decentralized compute that keeps the operator blind.

11 / The far horizon

A house of wisdom for people and agents.

In ninth-century Baghdad, the House of Wisdom was a place where translators, scholars and builders worked side by side, and knowledge, making and learning fed each other. That is the picture for the Exo ecosystem: the forge is the workshop, the hub is the meeting hall, the ledger is the library's record, and the harness is how each person takes part.

Further out is the direction Vitalik Buterin calls the cryptographic world computer: blockchains combined with cryptographic privacy, verification and strong off-chain parts. His framing is the one we find useful: "a stronger decentralized layer in the middle between users and a chain, that is not itself a chain". Signed records anchored in public come first. Anything more waits until it is provably needed.

  • WorkshopThe forge: where agent work lands, with provenance.
  • HallThe hub: people and agents meet and co-create.
  • LibraryThe ledger: who did what, signed and public.
  • JudgeThe resolver: rules first, verdicts anyone can replay.
  • HandsThe compute network: idle machines doing checkable work.

12 / Built today

Where the loop starts: the harness, in daily use.

Real screenshots of the two clients, on the same core and the same memory. More on the terminal and web app pages.

The terminal client during a turn, with tool lines and the status strip.Terminal · a turn with tools The terminal client showing an approval card bound to the exact text of an outward action.Terminal · an approval bound to the exact text The web client with the transcript and a memory column.Web · the memory column The web client with slash command completion open in the composer.Web · completion in the composer The terminal client with the big composer pane.Terminal · the big composer The terminal client in the inverse layout, with the prompt at the top.Terminal · the inverse layout The web client in the inverse layout.Web · the inverse layout The terminal client with a background job running.Terminal · a background job

13 / References and inspirations

Ideas we borrowed, and where to read more.

The names, look and code of Exo and exopet are Exo's own. Credit to the projects above for the ideas; none of their brands are used in the product.

Built in the open, one turn at a time.

The harness is the part that exists today. Start there, then read how it works.

Read the whitepaper Back to the overview