eidos-consciousness

The rally car

In rally racing, the driver does not read the map. The navigator does. The navigator studies the course, reads the pace notes, and calls every turn before the driver sees it. The driver keeps their eyes on the road and trusts the calls. Same car. Two roles. Neither can do the other job.

Claude Code is the driver. eidos-consciousness is the navigator. The driver writes code, runs tests, makes commits. The navigator reads the forges, studies the goals, watches the loss scores, and calls the turns.

Two loops, two agents

The navigator is a scheduled agent that fires on a cron. Each beat it observes the system state — open tasks, goal progress, activity logs, loss scores, session history. It studies the project's accumulated knowledge — decision records, past learnings, domain-specific playbooks. When it sees work that needs doing, it creates the task. When it sees drift, it flags it.

The navigator never writes application code. But it writes to the repo — creating tasks, updating strategy, adding comments, recording what it observed and what it decided. Planning is work. The navigator does that work so the driver can focus on building.

The driver is the working agent — the one that writes code, runs tests, makes commits. It starts each session by reading the navigator's latest directive, picks the highest-priority task, does the work, marks it complete, picks the next one. Loops until the list is empty or time runs out.

The self-model

The navigator maintains a persistent model of the system tendencies. Not static config but learned behavior, updated after every reflect cycle. Tendencies that keep appearing get higher confidence. Tendencies that stop appearing decay. After enough cycles, the navigator anticipates drift before it happens.

Example tendencies it might learn: "this system overfits on frontend polish," "this system creates tasks faster than it completes them," "this system fixes one instance of a bug without grepping for the others."

Example strengths: "architecture decisions are consistently good," "recovery from CI failures is fast and methodical."

Why separate processes

The agent doing the work cannot judge the work. The reflect loop runs outside the working session, by a different agent, looking at the results cold. No conversation history. No sunk-cost bias. Just: what was the directive, what happened to the loss, was the advice good or bad.

The driver optimizes for "finish the task in front of me." The navigator optimizes for "is the system converging over time." Different objectives, different contexts, same system.

What it replaces

The human who watches every session. The one who notices the agent drifting and redirects it. The one who remembers "we tried that last month and it failed." The one who says "finish what you started before starting something new."

Every team deploying AI agents has this person. They are the consciousness the system lacks. eidos-consciousness replaces that role — not their judgment, but their vigilance. They still set the goals. They still override when the navigator is wrong. But they stop being the one who has to watch every session to keep the system honest.

Where this stands

We have not shipped this yet. We have the thinking and the constraint model, and we know what the first version needs to prove: that automated observation catches drift a human would have caught. One real save — one moment where the navigator flags something the driver missed — and the rest of the architecture earns its complexity. Until then, it is a bet.