Hey @RhettCreighton,

I’m not sure if there’s an ‘ideal known strategy’ for orchestrating this type of multi-agent workflow. After experiencing some rather negative issues with Claude Code—mainly running out of context and spinning out of control—I set up a process using Gemini to help coordinate and control the software engineering pipeline.

Specifically, I developed a system where Gemini and I collaboratively broke down the overall project into sets of development tasks for the Claude Code agent. For each task, Gemini generated a detailed task description, which I then manually copied and pasted into Claude through its desktop interface. Claude would then pass the instructions on to the Claude Code agent via MCP, enabling that agent to execute the coding work. This approach allowed for steady and reliable progress over several weeks.

Now, I’m looking to build on this idea further. Instead of managing information via files, I plan to integrate a graph database (SurrealDB) to structure and track the tasks and outputs. Initially, I designed a solution using Tauri, leveraging its JavaScript integration to call the functions of the current OpenAI Codex implementation in TypeScript. However, with the recent emergence of a pure Rust version of Codex, it’s now possible to develop a much more robust system entirely in Rust—removing the dependency on Tauri and JavaScript layers.

Do you think it’s worth making this an open prototyping project? I’d really appreciate your thoughts.

The pattern most people I know use today is exactly what you're describing — keep a planning.md (or an external scratchpad in Apple Notes / a side editor) with running progress notes and the next step, and re-paste the relevant lines back into the chat when context gets cleared. It works but it's friction-heavy: you have to remember to write to it, and you have to remember to paste from it.

I just filed #20138 proposing an in-app version of this for the desktop variant — a notes panel with a markdown surface that auto-injects into the agent's system context every turn from durable host state, so it survives compaction by construction. Two regions: shared (read/write by both the user and the agent — replaces the manual-paste loop) and private (UI-only, never sent to the model — your own scratchpad).

Cross-linking in case it's relevant to anyone here.

The AGENTS.md / codex.md file (mentioned above) is the key layer here. Beyond progress notes, it is worth distinguishing two types of persistent content:

Type 1: Project rules (behavioral) — conventions, anti-patterns, test setup. These do not change between sessions and should live permanently in AGENTS.md. They are "always-loaded" context that tells the AI how to behave in this project regardless of task.

Type 2: Task state (progress) — current task, what was done, what is next. This is the planning.md use case — reset and rebuild between sessions.

The confusion I see most often: teams put Type 2 content (session progress) in the same file as Type 1 content (rules), which causes both to degrade. Rules get stale as they accumulate task-specific notes; task state gets noisy as rules grow.

What works:

• AGENTS.md or CLAUDE.md — permanent project rules, 15-20 high-signal items, never session-specific
• PLANNING.md or TASK.md — current task state, active context, rewritten each session
• Handoff block in PLANNING.md: "Stopped here: [exact file:line]. Next: [action]. Blocker: [if any]" — 3 lines is enough for a cold resume

The codex.md approach mentioned above works well for the rules layer. For what goes in that file: https://gist.github.com/oliviacraft — free per-stack starters showing what rules produce the most reliable output.

One distinction that has helped me is separating session/transcript persistence from project-state persistence. Resuming a rollout restores the conversation, but it does not necessarily make the active objective, dependency graph, completed evidence, blockers, and next action explicit or easy to audit.

I have been testing an early local-first implementation of that approach in TaskState Vault. Its workflow is deliberately structured rather than transcript-based:

• stable project intent, with separately mutable task objectives;
• a dependency-aware task graph and execution queue;
• task/run records for state, evidence, artifacts, errors, and next action;
• account/project/task information kept in separate layers, with relevant long-lived information copied into the active task scope;
• a startup guide that Codex reads and a writeback step after managed work.

This is heavier than a single Planning.md, and it is still early, but the explicit checkpoints have been useful on multi-stage work because a new session can load "what matters now" instead of reconstructing it from the entire history. I would be interested in whether others find structured checkpoints more reliable than a free-form planning document, and which fields are actually worth keeping.

A pattern that has held up better for me than treating one Planning.md as memory is to keep three layers with different lifetimes:

1. AGENTS.md for stable project constraints and validation commands.
2. A short task handoff for the active objective, completed evidence, blocker, and exact next action. Rewrite this rather than appending forever.
3. The full session/tool history as an audit trail, not as the primary resume prompt.

On resume, load layers 1 and 2 first; consult layer 3 only when a decision or failure needs reconstruction. That keeps the restart context small while preserving traceability.

Better Agent implements the third layer as a local workspace with durable Claude, Codex, and Gemini sessions, including tool activity and recovery after browser or backend interruptions. It is source-available for non-commercial use, not OSI open source. The explicit handoff artifact is still valuable even when the transcript survives, because “what happened” and “what should happen next” are different data.

I maintain Better Agent, so this is an affiliated example. AI helped draft this comment.