Loading…
a327ex.com

Delegation: driving other agents from a Claude session

Status: Phase 0 (raw CLI calls, no tooling). Decisions dated 2026-09-05. Read this before delegating anything. The /delegate skill is the shim.

Why

Who does what

Agent How it runs Use for Never for
Fable (this session) directly decisions, briefs, review, feel-adjacent changes, small edits typing-heavy work that a complete brief could hand off
Astra (Codex CLI, gpt-6-astra high) codex exec headless implementation under a complete brief: ports, framework syncs, content batches under an agreed spec, harnesses, mechanical refactors design, exploration, anything with unstated conventions
Grok (grok CLI, grok-4.6-build; 4.7 when it lands) grok -p headless research reports, exploratory analyses, content fan-outs (lists, variants) implementation in the engine or games until proven
Opus 5 (Agent tool, model: opus) subagent implementation that needs Claude-side context (memory, CLAUDE.md gotchas), or when Codex/Grok windows are exhausted replacing Fable's decisions
Gemini (API key, credit) python script over the Files API video analysis only (trailers, gameplay recordings, turntables, competitor footage) anything else
Sonnet/Haiku (Explore) subagent mechanical searches, as today

Astra's profile, from the owner's observation: precision-hungry, not exploratory, wrong when left to decide. That is a bad collaborator and a good implementer, provided the brief removes every decision. Give it exact paths, function names, acceptance checks and stop conditions.

Its standing ~/.codex/AGENTS.md says the opposite ("implement reversible first versions without a brief, make coherent choices"). The brief's preamble overrides that per run; do not edit AGENTS.md for this.

Deferred by the owner (2026-09-05): Grok as a routine adversarial reviewer of briefs. Revisit after Grok 4.7.

Gemini first-use notes: ~/.gemini/settings.json sets general.defaultApprovalMode: "yolo", which the CLI rejects at startup (valid: default, auto_edit, plan; yolo is a CLI flag only). For video, do not go through the CLI: write a small script against the Files API with the key, upload the video, prompt, print. Scope and script land in the session that first needs them.

The packet

One directory per run, in the private Anchor repo, never inside a game repo (briefs can carry NDA content):

~/a327ex/Anchor/workflow/delegate/runs/<yyyymmdd>-<slug>/
  brief.md        what Fable wrote; the contract
  report.md       the implementer's final message (Codex -o / Grok json text)
  events.jsonl    Codex --json events, or the Grok json response
  run.json        {agent, model, cwd, started, finished, session_id, brief, note}

brief.md sections, in order:

  1. Preamble (verbatim, adjust the project path):

    You are implementing under an agreed brief written by Fable (Claude), who is directing this work for the owner. Make no design decisions: where the brief is silent, ambiguous, or wrong, stop and report instead of choosing. Read <project>/.claude/CLAUDE.md for project facts (paths, docs, commands, gotchas); its process rules about briefs and asking the owner bind Fable, not you. Do not commit, push, run the game interactively, or touch files outside the scope below. End with the report in the format given.

  2. Task in two or three sentences.
  3. Approach / Interfaces / Functions / Decisions, as in a normal brief (CLAUDE.md, Code Changes). Decisions are closed: say so.
  4. Scope: the files it may touch, and the files it must not.
  5. Stop conditions: the specific situations where it must stop and report (a signature that does not match the brief, a test that fails for a reason outside the scope, a missing asset, any choice the brief did not make).
  6. Verification: the exact commands to run and what passing looks like.
  7. Report format: what changed (file, function, one line each), what was verified and how, anything stopped on, nothing else.

Commands (verified 2026-09-05)

Run these in the background (run_in_background) and keep working; the completion notification arrives when the run ends.

Codex / Astra:

R=~/a327ex/Anchor/workflow/delegate/runs/<yyyymmdd>-<slug>
codex exec -C <project> --approve-for-me --json -o $R/report.md "$(cat $R/brief.md)" > $R/events.jsonl
# follow-up in the same session, keeping its context:
codex exec resume --last -C <project> -o $R/report-2.md "<follow-up>"

--approve-for-me is the workspace-write sandbox with automatic approval review. Never --dangerously-bypass-approvals-and-sandbox. --ephemeral saves no transcript: probes only, never real runs. The rollout lands in ~/.codex/sessions/ and is what Phase 1 publishes.

Grok:

grok -p "$(cat $R/brief.md)" --cwd <project> --output-format json --always-approve --max-turns 60 > $R/report.json
# follow-up:
grok -c --cwd <project> -p "<follow-up>" --output-format json

The json carries text, sessionId, usage, modelUsage; copy sessionId into run.json. Sessions land in ~/.grok/sessions/.

Review protocol (Fable)

  1. Read report.md, then git -C <project> diff --stat, then the diff of the files the brief named. Do not read the transcript; that is what the report is for.
  2. Run the verification commands yourself. The report is a claim.
  3. Wrong or partial: one follow-up to the same session (resume), not a fresh run. Wrong twice: take it over (Opus subagent or directly) and say so in the reply so the log records it.
  4. Hand over to the owner with test instructions, as always. Feel is his.
  5. Until Phase 1 weaves runs automatically, name the run directory in the hand-over reply so the session log carries the pointer.

Publication (agreed design, not built: Phase 1)

Owner decision, 2026-09-05: a delegated run appears in Fable's log as an artifact-style card. Clicking it opens a page structured like a log but unlisted: reachable only through that card, absent from /logs, the sidebar, search, the catalog and the sitemap. It is not a public log of its own. On that page the prompter avatar is Fable's, not the owner's, since Fable drove the run; model attribution shows Astra or Grok as normal.

Sketch for the session that builds it (brief-first, Anchor workflow code):

Phase 0 checklist for a new session

  1. The owner names the task. Write the brief and iterate it with him as usual.
  2. Create the run dir, write brief.md, launch in the background.
  3. Review per the protocol. Hand over. Name the run dir in the reply.
  4. After two or three runs: decide whether Astra's output under a tight brief is good enough that the review loop beats doing it directly. That answer decides whether Phase 1 gets built.