The Navigator

"I can go either way on the manager, but strongly suspect we need an agent for the navigator. My main concern right now is that you and the workers you create aren't impacting the roadmap, which means none of this is sustainable. Every time I ask for something the roadmap should change in a concrete way. Every decision should result in new or updated issues. Every worker should advance a requirement through its lifecycle. That's the overall approach for this project and it currently feels like an after thought." — @jwildfire, 2026-08-16

"The overall approach is that prime and I set the strategy (think ceo) and then the navigator translates it to actionable tasks (coo) and makes sure the workers are delivering." — @jwildfire, the same morning

The complaint is measurable, and it was measured before this page was written. Six pieces of work were filed and shipped overnight in the agent's own repository, all closed by morning, all carrying a release milestone. None is attached to a requirement — the link GitHub actually records is empty for every one of them, including the one that names its requirement in a sentence of prose. And the requirements were there the whole time: four of the six were Operations Dashboard work, and that requirement gained no child issue, no comment and no edit across the entire night. A fifth was the release-candidate naming rule, which belongs to the release-scaffolding requirement — a requirement that names that exact framework inside its own scope.

The night was not roadmap-free, and the difference is the whole diagnosis. Eight requirements were filed overnight: three new ones from the design agents, and five as follow-through on decisions you had just made. Every task issue carried a milestone. So the roadmap moved, repeatedly — but only in the lane where a decision page had already forced it. In the lane where you simply ask for something, it did not move at all. The fault is direction of flow: the roadmap records work afterwards instead of authorising it beforehand.

The cause is structural, not careless. Today an ask reaches the concierge, the concierge writes instructions for a worker, the worker files an issue describing the work it is already doing, and the worker ships. That issue is a receipt. Nothing in the chain opens a requirement, so nothing updates one — and the role doing the dispatching is the one built to answer you in seconds, which is the opposite of what writing a requirement needs. The intake problem is a role problem, not only an ordering problem. Your org chart names the person who should own it.

"I suspect that prime (and I) own goals and overall roadmap structure. Coo owns everything else. Requirements, tasks, lifecycle, milestones, etc. coo can propose structural changes, but we make the call on implementing or not." — @jwildfire, 2026-08-16

"I'm more interested in COO improving operations. Updating templates, tweaking dashboards, refining audit framework. That is its job. Splitting goals is strategy that ceo owns." — @jwildfire, 2026-08-16

Read together, those two draw the line the rest of this design hangs on. An ambiguous boundary here is how the Navigator ends up either paralysed or overreaching — and the second quotation rules out one direction firmly: the Navigator does not propose strategy. Splitting a goal, retiring one, deciding what the program is for — none of that is its business to raise. What it owns instead is bigger than bookkeeping: the machinery everyone works inside.

Concretely on the plan: creating a requirement, scoping it, splitting it, moving it to design, attaching a milestone, filing its tasks, closing it — all the Navigator's, no permission needed. Adding a goal, retiring one, changing what the lifecycle stages are, or changing the rule that a requirement covers exactly one release — all yours.

And concretely on the machinery, which is the larger half: sharpening an issue template, adding a check to the nightly audit, retiring a rule that turned out to be noise, reshaping a dashboard section, tightening the release-candidate contract, fixing a process that keeps producing the same mistake. The Navigator does that work continuously and ships it, the same way any other worker ships — a requirement above it, a task beneath it, a release it lands in. It is a builder, not an inspector. Enforcement is one of its instruments; improving the machine so enforcement is needed less often is the actual job.

"I said I want a feel for how we work together. Me, you, coo. I want ceo and coo to work very closely. If it proposes a change I want your recommendation on if we should implement it and how. Does the proposed change make sense? The coo reports directly to you. You report to me. I might talk to it directly sometimes if there are specific operational things I want done, but you are still my primary point of contact." — @jwildfire, 2026-08-16

So: the Navigator reports to the concierge, and the concierge reports to you. The concierge stays your primary point of contact, and you may talk to the Navigator directly whenever you want something operational done. Three consequences have to be designed rather than assumed.

The concierge is accountable for the Navigator's output, not a relay for it

When the Navigator proposes an operational change, you do not want it forwarded — you want a recommendation attached: does this make sense, should we do it, and how. That is a review with judgment in it, and a review is only cheap if the thing being reviewed arrives in a reviewable shape. So a proposal from the Navigator must carry five things, and a proposal missing them has failed its format regardless of how good the idea is:

• The problem, in one or two sentences, stated as something that happened rather than something that might.
• The evidence — what it observed, how many times, over what window.
• The options it considered and rejected, with why. This is the part that saves the concierge from redoing the analysis, and the part most likely to be skipped.
• The cost — what building it takes, and what it costs to run.
• The reversibility — what undoing it would involve if it turns out wrong.

A proposal that forces the concierge to reconstruct the reasoning has not saved anyone anything; it has moved the work.

Talking to the Navigator directly must not create a second queue

You should be able to give the Navigator an operational job straight, without routing it through the concierge — that is what working closely means. The risk is two records that disagree, and the concierge answering questions about a state it does not have.

The rule that prevents it is small: a direct task is handled exactly like any other — requirement first, delivery line at the end — and the Navigator tells the concierge in one line that it happened. One record, one queue, no divergence, and the concierge is never surprised by work it did not dispatch. It costs the Navigator a sentence.

Who reads what

That answers a question left open earlier in this page: the primary reader of the Navigator's decision record is the concierge, not you. Which means it should be written dense and complete — everything needed to audit a day's judgment in one pass — rather than trimmed for a phone. You see the critical items and the proposals; the concierge reads the rest and is answerable for having read it.

The failure mode to watch is the obvious one: a chain of three where the middle link filters everything becomes slower than the two-link version it replaced. The protection is that the direct channel to the Navigator stays genuinely open, and that the concierge's duty is to evaluate, not to gate — nothing waits on its review to happen except the proposals that were going to need your decision anyway.

A standing Claude session named 🧭🤖 obot-navigator, launched from the workspace root the same way the concierge is, and reachable the same ways — from the terminal, from the web, or from your phone.

# the launcher to be written today, mirroring scripts/obot-prime
obot.agent/scripts/obot-navigator

# which is exactly:
cd /Users/jwildfire/Documents/obot2
claude --bg --permission-mode auto --remote-control \
       -n "🧭🤖 obot-navigator" --model opus /s-navigator

Three properties matter and each is copied deliberately from the concierge's launcher, which already works:

• Launched from the workspace root, so it inherits the workspace instructions, the skills overlay and the session-hub cache. Not from inside a repo.
• Bridged to remote control, unlike the worker agents, which were deliberately unbridged yesterday. The Navigator is a role you talk to, and you are travelling — you should be able to reach it from a phone.
• A singleton. The launcher refuses to start a second one, exactly as the concierge's does: it scans the harness job records and exits if any live job's name starts with the Navigator's emoji. Two officers writing requirements for the same ask is the failure mode worth designing out on day one.

Its behaviour lives in a new skill, in the same three-piece shape every other role already uses. All three are required — the middle one is the piece that is easy to forget, and without it the skill simply does not load:

obot.agent/skills/navigator/SKILL.md          # the contract
.claude/skills/navigator -> ../../obot.agent/skills/navigator   # workspace overlay symlink
obot.agent/commands/s-navigator.md            # the /s-navigator entry point

Cold start — what it reads on wake

The Navigator must be able to start cold and know the state of the world in one read, because it will be restarted often in the first week. It reads, in this order:

• .claude/session-hub/navigator-state.md — what the mechanical sweep saw in the last five minutes: open release candidates, recorded decision answers, the config-ledger verdict, recent events. This file already exists and is already current.
• .claude/session-hub/prime-state.md — the concierge's durable state. Read-only, always. The Navigator never writes it.
• .claude/session-notes/{today}.md — the shared scratchpad every agent logs to.
• The open requirements under the goal it is working, from GitHub, bounded to that goal's children.

The first three are already assembled into a single bundle by the concierge's rehydrate tool, which the Navigator can reuse unchanged, read-only.

The Navigator already exists as a machine, and it is running right now. A script fires every five minutes under the system scheduler, checks seven repositories, writes a state file, and appends its events to the shared scratchpad. It has run 233 times, most recently minutes before this page was written, and its last exit was clean. It caught a stale claim on 2026-08-14 and it now carries the config-ledger integrity check as well.

That machine is not being replaced — it becomes the Navigator's eyes, and the new session becomes its judgment. Nothing about the split is philosophical; it follows from what each half can actually decide.

Two writers, two files — and the delivery record shows up for free

The sweep is and remains the sole writer of its state file; the session writes its own, .claude/session-hub/delivery.md, append-only, one line per closeout. That is not fussiness. The last two nights produced repeated cases of one process quietly overwriting another's file, and a shared file here would put the delivery record — the thing this whole role exists to produce — squarely in that class.

The nice part is that the two files rejoin themselves without any new plumbing. The sweep reads the delivery file and renders it as a ## Delivery heading inside its own state file; and the dashboard tab that shows you that state file already renders any heading it finds — it was deliberately built that way, so a new section appears without a line of code changing. So the day-one delivery record reaches your dashboard through machinery that already exists:

node obot.agent/tools/ops-dashboard/ops-dashboard.mjs --serve --open
# the /navigator tab, already live, renders whatever headings the state file carries

There is already a nightly roadmap audit: twenty-two rules, run at half past three every morning, reading the hub's issues and board, the pull requests across the seven portfolio repositories, the ideas queue and the design documents on disk. It is good machinery and the Navigator should lean on it rather than grow a second one. So it is worth being exact about what it did with last night's six real failures: it caught one and missed five.

The reason it is blind is worth sitting with, because it explains why a new rule alone would not have fixed this. A spoke-repo issue is visible to the audit only if a hub issue already lists it as a child — which is the very link that was missing. The check cannot see the failure, because the failure is the absence of the thing that would make it visible. Something has to look from the other end, which is precisely what widening the scope does.

The split between the two mechanisms follows straight from this list. Mechanical, and belonging in the sweep: a spoke issue closed or a pull request merged with no requirement above it; an answer you recorded still unapplied after an hour; the registry and the index disagreeing; an agent exiting having produced nothing. Judgment, and belonging to the session: whether a stale claim in a published page is actually wrong, and whether a given piece of work should have had a requirement at all.

One more consequence of the delegation grant lands here. Several checks worth having were never adopted because their false-positive rate was too high to put in front of you. With the Navigator reading them instead, that calculation changes — the audit can afford to be more sensitive than it could when you were the only reader, because a judge now sits between the rule and your attention.

1. Improve the machinery — the standing job

This is the one that runs when nothing else is happening, and it is the reason the role is worth a session rather than a script. The Navigator carries a live backlog of operational improvements and ships them the way any worker ships: a requirement above the work, a task beneath it, a release it lands in. Sharpening a template, adding or retiring an audit rule, reshaping a dashboard section, tightening a contract that keeps producing the same mistake.

It does not need to be told to do this, and that is the point — the other two jobs are reactive, and a role with only reactive jobs sits idle between your asks. The backlog is not hypothetical either: this morning's audit scorecard names four checks that should exist and do not, and last night produced six more improvements of exactly this kind without anyone holding the role.

2. Translate an ask into a requirement

You say something to the concierge that implies work. The concierge answers you immediately — that conversation is strategy and it goes through nobody — and then hands the ask, verbatim, to the Navigator with one line of context. The concierge does not write worker instructions any more.

The Navigator then, in order: reads the open requirements under the relevant goal; decides whether this is a new requirement or a named change to an existing one; writes it, with a milestone, linked to its goal; and only then writes the worker's instructions, derived from the requirement rather than from the conversation. It reports one line back to the concierge — the requirement's link and the worker's name — which the concierge relays to you.

The rule that makes this safe is that nothing in it is on your response path. If the Navigator is slow, you do not notice; only the worker's start moves, by a few minutes.

3. Judge delivery when a worker closes

The Navigator learns a worker finished from the harness's own job records — the per-job state file and event timeline the machine already keeps for every agent, at no cost and with no calls to GitHub. Three details are load-bearing, all measured rather than assumed:

• The closeout watermark is the moment a job first goes terminal — a single timestamp, written once and never revised. That is what the Navigator reads to know a worker closed, and it is why the check cannot double-count or miss.
• A job's recorded state is not proof it finished well. The worker that died at 06:12 yesterday has a state file that today reads done, with a normal-looking completion note. The death survives only in the append-only event log. So the Navigator reads the timeline, not just the state.
• The "blocked" signal only means death for a worker. For the concierge and your own sessions it is the ordinary waiting state — it appeared 47 times in 36 hours, every one a normal wait. For a background worker it appeared twice, both belonging to the one real death. Role-aware, it is precise; role-blind, it is noise.

One thing the ledger cannot be trusted for: the list of what a job produced. Nearly half of the jobs measured recorded no children at all, including one that merged three pull requests and filed two issues. The Navigator therefore judges against GitHub, not against the job's own account of itself. As of this morning the ledger holds one stalled corpse that nobody has noticed — still sitting there, never marked terminal.

On each closeout it asks the three questions in the table above and appends one line to the delivery file: the worker, what it produced, the requirement it moved, and a verdict — confirmed or drift.

When the roadmap did not move, the Navigator fixes the roadmap — and never the work. That distinction is the whole safety story. It may attach the issue to the requirement it belonged to, amend the requirement, or file the missing one, because those are the plan and the plan is its job. It may not touch a line of what the worker produced, merge anything, or publish anything. Every repair it makes to the plan is logged as a call you can read and reverse, so "it tidied up" never becomes "nobody knows what happened" — the failure this role exists to surface must not be absorbed by the role itself.

4. Report delivery

One section, appended through the day, answering the question you actually asked: what did this day of agents do to the roadmap. Confirmed movements, drift, and anything that closed producing none of the three outcomes a worker is allowed to finish into.

"I am fine delegating a lot of judgement calls to COO. It can escalate critical items to me." — @jwildfire, 2026-08-16

That sentence sets the default, and the default is the opposite of how the system behaves today. The Navigator decides; it does not queue. Almost everything the sweep and the closeout check surface should end with the Navigator resolving it — attaching the issue, amending the requirement, granting or refusing an exemption, judging that a deferral deserves a requirement of its own. Only a critical item reaches you. The present failure is precisely that everything funnels into your queue, and a role that merely adds a better-organised queue has not helped.

Three consequences worth stating before you agree to it

"Critical" already has a bar — it should not get a second one. The Operations Dashboard shipped one last night: a pin capped at three items, earned only by a blocking reference confirmed still open on GitHub or by a computed condition, never by an agent's opinion. On its first night nothing earned it. That is exactly the right threshold to inherit as the escalation line, and inheriting it means there is one definition of urgent rather than two that drift apart. You have said you will be annoyed by anything marked critical that is not, and that if something needs your attention it probably is not a good rule in the first place.

It changes what is worth detecting, in your favour. A check too noisy to put in front of you can be perfectly good when the Navigator is the one reading it, because the Navigator can absorb an ambiguous signal and judge it. So the audit can afford to be more sensitive than it could when you were the only reader — rules previously rejected for false positives are worth revisiting now that a judge sits between them and you. That widens what the system can catch without widening what you have to read.

Where its calls get written down

Two levels, because not everything deserves the same weight:

• Every judgment gets a line in the delivery record — what it decided, on what, and why, in one sentence. No identifier, no ceremony. This is most of them.
• A call that changes the plan gets a permanent identifier — filing a requirement, amending one, granting an exemption, closing something as out of scope. These are the reversible-by-you set, and they get short permanent ids in the same lowercase style the config items already use, allocated the same way and never reused.

You review them in batch, not one at a time — a single "calls made for you" section in the day's delivery record, read once, most days in under a minute. Escalation is the exception, batch review is the norm.

When you disagree after the fact, reversal is cheap by construction. The Navigator only ever changes the plan, never the work, so undoing a call means reopening or editing an issue — seconds, no code involved, and both the original call and the reversal stay on the record against the same identifier. That property is the reason the "never touches the work" line has to stay absolute even as the judgment grant widens.

The Navigator may not merge, may not publish, may not correct another agent's work, and may not edit the concierge's state. Those are absolute, and they are what makes the judgment grant above safe to give: the wider its discretion over the plan, the harder the line around the work has to be. A role that can both decide freely and reach into what was built is one that can quietly rewrite history; a role that decides freely but only ever moves issues around is one whose every mistake is visible and undoable in seconds.

Getting this wrong just moves the bottleneck, so it is worth being exact. The concierge has been doing the translating, badly, and that is what produced the five receipts.

The one rule that must not bend: the concierge never waits on the Navigator before replying to you. It replies, then hands off. If that inverts, the Navigator becomes the latency problem you already cut the concierge off for.

The concierge's new job at intake is a routing call

On every ask, one question: is this about the shape of the plan, or about something inside it? Shape — a new goal, a change to what the lifecycle is — stays with the concierge and you. Everything else goes to the Navigator. That is a decision small enough to make in a second, which is the point: it does not reintroduce slow thinking on your response path.

A real ask from last night, before and after

You wrote, at around ten in the evening: "New rule for release candidate names: {package} Vx.x.x-RCx. No other summary allowed … always link to news.md in all RC PRs."

Note what the second column does not contain: a new requirement written to describe work already done. The Navigator recognised an existing one and amended it, which is the judgment the whole role turns on and the thing no rule could have produced.

The four checks are named by this morning's scorecard and are all mechanical: an issue closed or a pull request merged with no requirement above it (gated on work done, not on filing); an answer you recorded still unapplied after an hour; the registry and the published index disagreeing; an agent exiting having produced nothing. All four run across the seven project repositories, not just the hub — that is the scope change you called for this morning, and it is what makes last night's failure visible to a machine at all. It is textbook work for this role: it improves the machinery rather than policing it, it closes the holes from last night permanently, and it lands in an afternoon.

You asked for a feel for how the two of you work together, and that means watching it do something rather than watching it report. By tonight there is a shipped change with a requirement above it, a task beneath it, and a delivery record saying so — which is the whole thesis of this page demonstrated on itself.

Waits until it has earned it: counting exemptions and reporting the rate; a delivery view in the dashboard rather than a rendered file; folding the stall alarm in; letting the sweep wake it automatically on a detection; and any of the more sensitive audit rules that were previously rejected as too noisy for you.

Four things you settled this morning are built into the design above rather than re-asked here: that the Navigator is an agent; that its job is improving operations rather than clerking the roadmap; that it owns requirements, tasks, lifecycle and milestones while you own goals and strategy; and that it may decide within its domain and escalate only critical items. What is left is where the edges sit.

• Say yes to the day-one scope and the boundary, and the Navigator starts this afternoon. A launcher copied from the concierge's, a skill file and its overlay link, the four audit checks, and a delivery file the dashboard already knows how to render. By tonight there is something shipped with a requirement above it — which is the point, since you asked for a feel for how the two of you work together rather than a report about it.
• Ratify where structure ends and the concierge can stop filing requirements and dispatching operations work immediately, which removes the mechanism that produced last night's untracked issues. This one needs no code at all.
• Settle the escalation line and the record of delegated calls and the delegation grant becomes safe to use at full width — without them it is either unused or unaccountable, and both waste it.
• Fold the supervisor in and one of the two things currently blocking scheduled overnight runs disappears rather than being built.
• Adopt the closeout mapping and the existing closeout requirement gets its missing half as an amendment rather than as new scope — which is the rule this page argues for, applied to this page's own follow-through.
• Decide nothing today and the safe partial is the last call alone: linking last night's work costs a quarter of an hour and is correct under every other outcome.

Deliberately not here: whether the standing sessions survive their own memory being compacted. That is the concierge's problem, it has its own requirement, and folding it in would make this page about two things.