Skip to content

[repo-study-fable-advisor-orchestrated-execution] Run a CoS task as a strong architect model that delegates the typing to a cheap lane (epic) #5991

Description

@atomantic

Provenance: studied DannyMac180/fable-advisor (MIT, © 2026 Dan McAteer) on 2026-09-03. Clean-room: no code, prose, or config copied — only the technique is described, reimplemented against PortOS's own modules.

What the studied repo does

It is a Claude Code plugin that turns a session into a three-role pipeline instead of one model doing everything:

  • an architect on the most capable model that never types implementation code — it owns decomposition, writes a fully self-contained spec per unit of work, picks a reasoning effort per unit, and judges the evidence that comes back;
  • one or more implementer lanes on a cheaper (and deliberately different-vendor) model that receive the spec with none of the architect's conversation context and return a structured report with verification evidence;
  • an advisor on the strong model again, in a clean context, that reads the accumulated diff against the stated goal before anything is called done.

The economics are the point: judgment tokens are expensive and low-volume, implementation tokens are cheap and high-volume, and the premium is spent only where it changes the outcome.

Why PortOS should have this

A PortOS Chief of Staff task today resolves to exactly one provider and one model for the whole run. selectModelForTask (server/services/agentModelSelection.js) picks a tier once at spawn from complexity heuristics plus taskLearning history, resolveThinkingLevel (server/services/thinkingLevels.js) resolves a single run-level effort from task.metadata.thinkingLevel, and agentProviderResolution.js resolves one provider (with a fallback chain) for the run. There is no way to say "plan this on the strongest model, let a cheap model do the typing, then have the strong model check the result against what I actually asked for."

That costs the user real money on every heavy task: today a task that needs strong reasoning for ten minutes of planning pays the premium model's rate for the other fifty minutes of mechanical editing too. It also means every PortOS agent run is single-vendor — the model that wrote the code is the model family that reviews it, so shared blind spots survive.

The user-facing outcome

On the CoS task form and in AI Providers (/ai), the user can pick an orchestration profile for a task: which provider/model is the architect, which is the implementer lane, and which reviews the result. A task run in orchestrated mode shows, in /cos/agents, which lane produced each part of the work and what each lane cost. When the cheap lane is unavailable the run fails loudly rather than quietly re-spending on the architect's model. Before the run reports done, the finished diff is checked against the task's own stated objective.

Recommended defaults

  • Off by default. Orchestrated mode is opt-in per task and per app-task pin; the existing single-provider path stays the default so no existing task changes behavior.
  • No implicit lane substitution. If the implementer lane's provider is unavailable, the run stops with a named reason. The whole point of the profile is the cost/vendor split; silently swapping it away is worse than failing.
  • Effort is named per delegated step, not once per run — the architect picks the lowest adequate rung for each spec.
  • The reviewer sees the objective. A code-quality review that never saw what was asked cannot catch "shipped something else".

Phases (each independently shippable)

  1. [repo-study-fable-advisor-orchestration-profiles] Add an orchestrated CoS execution mode with per-role provider/model and per-step reasoning effort #5992 — orchestration profiles, the orchestrated execution mode, and the per-step spec+effort contract.
  2. [repo-study-fable-advisor-fail-closed-lane] Never let a delegated implementer lane silently fall back onto the architect's provider #5993 — fail-closed delegated lanes: a lane never silently becomes the architect's own provider.
  3. [repo-study-fable-advisor-goal-fidelity-review] Review a finished agent run's diff against the task's stated objective, not just for code quality #5994 — goal-fidelity review gate: the reviewer reads the diff against the task's stated objective and returns ship / fix-first / rethink.

Scope: large — one epic, three phases; phase 1 is the load-bearing one.

Decomposed into

The agent that ships the LAST open child should tick its box here and close this epic with a summarizing comment.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:cos-agentsChief-of-Staff autonomous agentsdecomposedEpic already split into per-slice child issueseffort:highDispatch reasoning effort: highepicUmbrella/tracking issue — shipped as per-slice children, never as one PRmodel:heavyDispatch capability: strongest available coding modelplanTracked by /do:replanplanner:opus-5Plan authored by the opus-5 modelrepo-studyProposed from a study of a captured reference repository

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions