Boundary
The system boundary shifts from "one host around tools" to one longer-lived assistant spanning channels, memory, scheduling, routing, approvals, and governance.
What this adds
See how the pieces collapse into a platform.
By this point you have built toy versions of the major layers: model access, CLI tools, structured outputs, protocol boundaries, skills, hooks, loops, durable state, coordination, hosts, and evals.
This stretch goal keeps the same educational posture as the earlier labs: it is meant to expose structure, not imitate production scale. The new artifact works, but it stays intentionally small enough to read in one sitting.
Done when
You can send messages through more than one channel, store durable notes, route one request through the earlier JSON-wrapper tool, queue one digest job, and inspect the saved state and logs afterward.
Real-world analogs
OpenClaw and Hermes Agent are good comparison targets because both sit above the basic host layer and pull in persistence, routing, and multi-surface control.
Toy platform structure
What the gateway is actually doing
| Piece | In the toy lab | Why it maps to OpenClaw or Hermes-style systems |
|---|---|---|
| Gateway | gateway.py is the entrypoint that receives messages and dispatches actions. |
Persistent assistant platforms centralize routing, state changes, and user-facing control in a gateway or host layer. |
| Channels | The toy platform exposes cli, companion, and a tiny ops worker channel in durable state. |
Late-stage assistants usually span more than one surface: terminal, chat, messaging, app, or companion endpoints. |
| Skills and toolsets | skills.json defines remember, search, delegated search, schedule, and help behaviors. Search routes into the lab 02 JSON wrapper. |
Real platforms usually combine checked-in procedures, toolsets, and tool-routing layers rather than calling shell commands ad hoc. |
| Delegation | delegate search creates a worker record, runs the search through a named docs worker, and writes activity to the ops channel. |
Persistent assistant platforms often route work through named workers or subagents instead of keeping every action in one foreground thread. |
| Durable memory | state.json stores notes, searches, channels, and pending schedules. |
Persistent assistants need recoverable state that survives past one prompt or one terminal session. |
| Scheduling | schedule digest queues one job and tick executes it. |
Scheduling and background work are part of what makes these systems feel like assistants instead of one-shot hosts. |
| Policy and observability | Search requires approval, and message/event history is written to JSONL logs. | These platforms typically include approvals, policy boundaries, and traces because actions outlive one interactive call. |
Read it against the earlier labs
This lab works best after the capstone. Each feature should feel like a composition of prior labs rather than a brand-new concept.
Read next
Continue with persistent assistant platforms and the memory and coordination catalog section.
If you want the security complement to this platform shape, add the localhost broker side path.