Adaptive coaching, run by thirty-one agents.
A member brings their own source material: documents, papers, a video channel. The platform builds a prerequisite-aware programme from it, writes and reviews every task, grades answers deterministically, and adjusts pace and approach to the evidence of how that one person is actually doing.
A real system, described without its names.
What it does.
The work is split across narrow specialists rather than one large prompt. One agent maps the prerequisites in the member's material and lays out a programme. Authors write tasks grounded in that material, and an independent curator reviews every task before it reaches the member. Watchers follow engagement and understanding as answers arrive. A coach stages the next activity from what the watchers recorded. A live voice channel is one more process in the same tree.
Every model call and every domain decision is a durable fact on one event journal. A grade, a lesson or a pacing change can be traced to the events that produced it, and rebuilt from them without calling a model again. The nine-panel cockpit follows that journal directly; the dashboard captures on the home page were taken from this system, with its names changed.
Where a request-and-response stack breaks.
- 01Fan-out with an order
One answer is graded deterministically, then read by five or more watching agents, none of which may alter the grade. Replay must reproduce the same result, every time.
- 02Read models that race
What to do next depends on read models written by other, unordered consumers of the same event. The staging worker snoozes and re-checks rather than acting on a stale read.
- 03Isolation by construction
Every live artifact, a voice call, a feed line, a durable job, is scoped to one member and one sitting, or it leaks across sessions. There is no tenancy layer to hide behind.
- 04A model that can run away
Token ceilings and hourly spend caps per agent role, so a reasoning model that overruns degrades to a deterministic fallback instead of an outage or a silent bill.
The same problems, on two runtimes.
Python is a fine language and a poor runtime for this shape of work. Each point below names the piece of infrastructure a Python stack would add, and the runtime property that makes it unnecessary here.
PythonWhat you would have to build
- Thirty-one readers per answer
In Python that is a worker pool behind Celery and Redis: each worker an interpreter of tens of megabytes, held to one core by the GIL, scheduled cooperatively, so one slow model call stalls its neighbours in the same loop. On the Erlang VM each agent is a process of a few kilobytes, preemptively scheduled across every core, and one that crashes is restarted by its supervisor while the rest do not notice.
- Replay that proves the grade
To show that a grade was never altered you need an append-only log and a pure decide-and-evolve pair. A Python stack keeps state in rows that any consumer can update; replaying a run means calling the model again, which is neither exact nor free.
- Snooze is not a retry
The staging worker needs snooze, uniqueness and backoff as queue primitives, with every transition recorded. Celery gives you retries; the rest you build, and its bugs are yours.
- Nine live panels
In Python a live cockpit is a WebSocket layer, a pub-sub broker and a JavaScript front end kept in sync by hand. LiveView renders the read model in the same VM that writes it.
- A spend cap per role
An hourly ceiling per agent role needs a meter that sees every model call as it happens. Across a fleet of Python workers there is no such vantage point; the meter is a log you aggregate later, after the bill.
Z8What the runtime already does
- Durable agents
Thirteen event-sourced aggregates and thirty-one LLM agents share one runtime; the pure decide-and-evolve pair is what makes deterministic grading and exact replay possible.
- Jobs on named queues
Thirty workers on four queues, ingestion, authoring, observation and staging, with retries, snooze, a rescue after a timeout and a dead-letter queue, each transition an event.
- Reactors and read models
Twenty-four reactors act on facts; fifteen projections shape them for the cockpit and the coach, with lag and dead-letter depth visible on the dashboard.
- Budget per role
The budget plugin enforces token ceilings and hourly spend per agent role; a diminishing-returns stop ends runs that stop paying for themselves.
- Four providers, one interface
OpenAI, Anthropic, Google and OpenRouter behind one model layer, with retrieval grounded in the member's own material.
- The cockpit
Six LiveView pages, the main one following the event store in-process through the runtime's live-follow API.
One log, everything around it.
Where it stands.
In production
In production on a single node. The dashboard captures on the home page come from it. Multi-tenancy is plumbed and unused: one member owns their own data, and every artifact is scoped to one sitting by construction.
Counts on this page are taken from the code as it stood in September 2026: modules, workers, event types and tests, not usage or revenue, which we do not publish.
Does your system have this shape?
Many agents on one problem, work that must survive a deploy, a person in the loop, and a trail someone will inspect. Tell us what you are building.
henry@z8.run