The first adapter had to earn the roadmap

Agent OS began as a small proof with a deliberately unexciting job.

It accepted a bounded piece of operational evidence, brought that evidence into an isolated capsule, created a proposal, required an explicit human decision and emitted a receipt. The actuator had no external effect. A later observation recorded the outcome separately, and the disposable projection could be deleted and rebuilt from the append-only event history.

That first slice answered a question I cared about: could I preserve the path from evidence to authority without asking a model conversation to remember or police the boundary?

The proof was local, inspectable and narrow. It also made the larger possibility quite hard to ignore. I already had useful systems for applications, writing, company operations, voice capture, private human context and software work. I had Todoist for organising my attention, Codex as an operator surface and several possible ways to run scheduled work. The interesting problem was how those pieces might become legible together without moving all of their records into a universal database or giving one agent ambient authority over the machine.

I began writing the map.

Ten stages before one adapter

The first roadmap grew to ten numbered stages. It covered domain handoffs, temporal history, a joined operator projection, personal training, external actuation, scheduled execution, remote checkpoints, higher-stakes domains, cross-domain synthesis and measured improvement.

Most of the individual safeguards were sensible. Domain records stayed with their owners. Consequential actions needed exact authority and later reconciliation. Generated views remained disposable. Credentials belonged to the smallest capable process. The planned temporal layer had to distinguish observed facts, things I had said and model inference.

Stage 1 also specified a handoff envelope in advance. It named stable identities, schema versions, source references, several kinds of time, content hashes, transformation lineage, sensitivity, purpose, retention, uncertainty, freshness, correlation, idempotency, actors and permitted consumers.

I could explain why each field might matter. I couldn’t point to a real adapter that needed the whole set, or to a screen where the result helped me decide anything. The roadmap was becoming precise about transport while the first useful journey had yet to happen.

Personal-training localisation had also acquired a numbered place in the critical path. That work matters to me and already has evidence of recurring value, though it doesn’t determine whether a career-pipeline observation can reach a read-only control view. The sequence made one worthwhile project look like a prerequisite for another.

This is an easy failure mode in systems design. Once a broad architecture has names, boundaries and a destination, filling in the route feels productive. Each addition resolves an imaginable future problem, and the document becomes more coherent as the distance from operating evidence increases.

The criticism that changed the build

An external review challenged the critical path directly. It asked why the first implementation work was a universal handoff contract when there was no adapter, why the first projection tried to join several domains before proving one useful view, and why personal training sat between infrastructure stages that didn’t depend on it.

I agreed with the criticism and changed the roadmap.

Personal training moved to an independent side track. It can proceed when the human and domain work justify it, with its own privacy and clinical boundaries, without holding up Agent OS.

The immediate build became one source and one view. Jobpipe would remain the owner of career-pipeline records. A narrow read-only adapter would consume only its existing public command output. Daily Control would render the small set of facts required for one practical decision.

The shared handoff would be promoted later, after a second and third adapter had argued with the first design. If several working adapters repeatedly needed the same temporal, provenance, sensitivity or freshness fields, those fields could become a versioned common boundary. Domain-specific meaning would stay where it belonged.

Several pages of apparent certainty disappeared through that change. I found the deletion reassuring because it reduced the number of decisions we were pretending to have earned.

A bound that can be revised

The review also surfaced an inherited time cap. It came from an older operating assumption and had followed the work into a different project as though the number still carried authority.

The replacement kept a limit and changed how that limit was earned.

The revised rule begins with a brief read-only inspection of the producer and rendering seams. Before implementation starts, the orchestrator names the operator outcome, the first review checkpoint and a provisional time or effort upper bound. At that checkpoint I can narrow the slice, continue under an explicitly revised bound, or stop and record the missing contract.

The important property is that the bound cannot extend itself. New evidence may justify a new number, though elapsed time alone doesn’t.

This gives the implementation enough room to discover a real seam while keeping uncertainty visible. It also avoids borrowing urgency from a stale plan and converting it into pressure to finish the wrong abstraction.

The first tenant is a career decision

The chosen slice asks:

Which market-access action deserves today’s block: advance an active application, handle a due follow-up, or refill the pipeline?

Jobpipe already owns the relevant source records and decision rules. Agent OS doesn’t need its private database. It needs a current, bounded observation through the public read-only interface: the active set, recent pipeline actuals, due follow-ups, weekly actuals, source freshness and any failure in collection or transformation.

The view should remain honest when the source is stale, unavailable or malformed. Repeating the same source snapshot should produce the same rendering. Jobpipe retains every mutation boundary, including application and outreach decisions.

At the handoff point covered by this article, that view was still a build target. Stage 1 hadn’t passed its exit gate, there was no completed adapter to claim, and nobody had yet used the projection to make the named decision. Those results belong to the review evidence and aren’t premises for this story.

This makes the first tenant deliberately ordinary. The control plane is being asked to help me choose what deserves attention in a workflow I already use. Its value can be assessed on the screen, in a real review, without granting it the ability to change an application or send anything.

One accountable orchestrator

I handed the first implementation wave to a separate orchestrator with one writable owner and a fixed human review stop.

The model routing reflects the kind of evidence each role needs to produce. Luna and Terra scouts receive bounded read-only questions about the producer, the renderer, contracts and likely failure seams. One Terra writer owns the implementation changes, so the checkout never becomes a negotiation between several agents editing the same files. A fresh Sol verifier reads the result adversarially after the writer has finished.

The orchestrator remains accountable for the whole slice. It decides which investigations can run independently, reconciles their findings, keeps agents inside their scopes and refuses to turn a scout’s suggestion into an implementation claim. The verifier is fresh because a long implementation context is useful for building and rather less useful for noticing which assumptions survived unchallenged.

Model names are secondary to the ownership pattern. Scouts gather evidence. One writer changes the system. A separate verifier tries to break the claim. The root carries the result to the checkpoint.

The stop matters as much as the routing. The first wave should end with something I can inspect: the seam that was found, the contract that real code required, the rendered decision surface, the tests and runtime evidence, the failures that remain visible and the next proposed bound. It has no authority to glide from a read-only career view into broader adapters, task creation, scheduling or publication.

Where this account stops

This account ends with the decision that launched the implementation wave and makes no retrospective success claim.

Agent OS has proved its small append-only authority path. The roadmap has been criticised and materially reduced. Personal training has its own track. The first slice has a source, a proposed view, a revisable bound, an accountable orchestrator and a human checkpoint.

The implementation results belong in the next piece of evidence. At review I want to see whether the Jobpipe seam changed the contract, whether the view preserved failure and freshness honestly, and whether it helped with the actual career decision. If those answers are weak, I will probably return to the roadmap and delete more before adding another stage.