Recently I am doing a very specific thing: using the source code of pi agent and a set of small exercises. I hope that Codex will be responsible for reading the history, sorting out the stage, design exercises and final review; Cursor will stay at the project site and be responsible for explaining the source code, running tests, and accompanying me to complete every small step of implementation. It's clear what each side is good at, but the real trouble is switching. If every time you switch from Codex to Cursor, you have to manually copy the previous conversation, re-explain the learning objectives, and remind it not to do the questions in advance, this workflow will quickly become cumbersome. The chat history is long and scattered, and the window the model sees is unstable. After repeating it several times, people's attention begins to be consumed on the "handover background". So I added an automatic memory bus to pi-agent-practice. It does not introduce a database, nor does it forcibly tie the two products together. It only uses a set of readable files, a bridge script, Continue extension and project rules to allow two Agents to collaborate around the same work status. This mechanism is already running locally. The current stage is to read pi-mono's runLoop(), and the Cursor only explains the source code and asks questions; after I finish answering the three comprehension questions, the Codex will review the evidence and advance to the next stage card. The entire process does not require copying prompt words back and forth. Chat records are not suitable for serving as execution contracts. Cross-agent collaboration is most likely to fall into a misunderstanding: understanding "memory sharing" as copying the entire conversation. Full chats are mixed with a lot of temporary information: troubleshooting procedures, wrong guesses, broken paths, small talk that is not relevant to the current stage. Throwing them all to another agent only adds context noise. What's even more dangerous is that a suggestion in an old conversation may conflict with a new decision the user just made. I finally adopted a very simple priority: the latest user instructions are the highest, followed by the current stage cards, then project rules and earlier chat history. This means that the shared layer only holds two types of content. - What you are currently doing, which step you have taken, and when you must stop. - Long-term stable learning preferences, model strategies, safety boundaries and acceptance habits. The former is written into handoff/CURRENT_STAGE.md, and the latter is written into handoff/SHARED_MEMORY.md. Temporary session content will not directly enter long-term memory, and API keys, tokens, and personal memory originals are also explicitly excluded. The changes brought about by this step are obvious. Cursor doesn't need to "remember" Codex's chat, it just needs to get the latest stage card before each job. Codex also does not need to read the complete session of Cursor, but only needs to review the previous round of structured reports and corresponding code evidence. A stage card compresses the work into the smallest verifiable unit. CURRENT_STAGE.md is the most important file in the entire mechanism. It is like a small execution contract, including: - stage_id and current state; - The goal of this stage and the source code that must be read; - The clear task of the Cursor; - Stop condition; - An acceptance gate that can be proven by tests, symbolic references, or event traces; - The direction of the next stage after passing the review. This card currently requires Cursor to use GPT-5.6 Luna, read-only analysis runLoop(): explain the state transitions between assistant response, tool calls, tool results and the next round, indicate where tool-call id and result order are preserved, and ask me three more comprehension questions. The card is also written very clearly: do not change the code, do not cancel test.skip, and do not implement challenge 1 in advance. Many Agent workflows get out of control, and the reasons are not mysterious. Task boundaries only exist in the human mind, and the model sees an open goal. The stage card puts the goal, evidence and stopping conditions in the same place. The model's degrees of freedom still exist, but the degrees of freedom are limited to the current learning action. This also corresponds to the four principles I have been practicing: Stop Fighting the Model, Preserve Meaning, Design for Recovery, Evaluate, Don’t Assert. The real entry point is to continue adding project rules. Sharing files solves the problem of "where to put the truth." Next, we need to let Cursor read them stably. I initially added the custom model directly to Cursor's built-in Chat, but encountered two types of restrictions: the usage threshold of free accounts, and the verification of custom names in the built-in model directory. brad-gpt-5.6-sol can be recognized normally by the local sub2api, but the Cursor built-in Chat will directly report AI Model Not Found. The final solution was Continue. It supports OpenAI-compatible endpoint, which can forward model requests to native services while continuing to use Cursor's code editing interface. Model configuration on macOS is placed in ~/.continue/config.yaml: name: Brad Agent Practice version:
- 0.0 schema: v1 allowAnonymousTelemetry: false models: - name: Brad Luna - Read provider: openai model: brad-gpt-5.6-luna apiBase: http://127.0.0.1:18080/v1 apiKey: ${{ secrets.SUB2API_API_KEY }} roles: [chat, edit, apply] capabilities: [tool_use] data: [] The model id and base URL here are both from my local sub2api. Readers need to replace it with the value that their service actually exposes. The bridge script writes the shared state into the location that Continue will actually read. The Continue document allows adding stable constraints to the Agent through Rules, but the combination of extended version, host, and rule directory will affect the actual loading results. My first version only generated .continue/rules, and no stage files appeared in the actual measured Prompt. So the bridge script was changed to double writing: - Generate .continue/rules/00-automatic-handoff.md, retaining the standard rule entry; - Also update the managed blocks with start and end tags in the project AGENTS.md. async function codexSync() { await Promise.all([ syncContinueRule(), syncAgentsHandoff(), ]); await saveState(updateCurrentOwner); await appendEvent({ type: "codex_sync" }); } Each synchronization only needs to run: node scripts/handoff-bridge.mjs codex-sync script reads CURRENT_STAGE.md and SHARED_MEMORY.md, atomically replaces the same managed block in AGENTS.md, and then updates state.json and events.jsonl. It will not continue to add duplicate text, and it will still maintain an authoritative version after re-running. This link has been verified through the Continue dialog box in Cursor: The interface displays two project rules. After sending "Only return the current stage_id", the model accurately returns phase-01-runloop-mental-model. Subsequently issuing Reply exactly CONTINUE_CURSOR_OK, Continue returns the exact text, and the local sub2api log shows /v1/responses, brad-gpt-5.6-luna, and HTTP
- Put Continue on the right side and keep the code evidence in view. In the default layout, Continue will occupy the left sidebar, switch back and forth between the file tree and the dialog box. A more convenient way is to enable the Secondary Side Bar: Open the command palette and run View: Toggle Secondary Side Bar Visibility. Right-click the Continue icon on the Activity Bar. Select Move to Secondary Side Bar. After the adjustment is completed, continue to look at Explorer on the left, read or modify the source code in the middle, and keep the Continue dialog on the right. When the Agent refers to runLoop(), tool-call id or test files, the code evidence is always in the same view. It is also necessary to clarify the current automation boundaries here. handoff-bridge.mjs has implemented after-response and CURSOR_LAST_RESPONSE.md, but only when the host actually triggers the afterAgentResponse hook, the reverse collection will be considered successful. What has been verified so far is the stage synchronization, model routing and rule loading from Codex to Cursor; the reverse link still depends on the specific host and extension version. If the hook is not triggered, let the Cursor write out STAGE_REPORT.md according to the fixed contract, and then the Codex will read it in the next round. Without file or log readback, two-way automatic synchronization cannot be declared complete. The roles of the two Agents must have clear boundaries. In this workflow, Codex and Cursor do not compete for the same role. Codex is responsible for reading the long-term memory, the current project status and the previous STAGE_REPORT of the Cursor, and compressing complex goals into the next stage card. It is also responsible for the final review: whether the source code reference is accurate, whether the test really failed, whether it passed after repair, and whether the conclusion exceeded the evidence. Cursor is closer to the construction site. It reads the current stage requirements, interprets and runs commands within the specified source code range or completes the implementation with me, and returns a unified format at the end: STAGE_REPORT stage_id: phase-01-runloop-mental-model status: waiting_for_learner evidence: - agent-loop.ts: runLoop() open_questions: - When the tool completes asynchronously, why do the result messages still maintain the source order? suggested_next_gate: Wait for the learner to answer three questions. The report is the entrance to evidence and cannot be automatically regarded as the correct answer. Codex will review it together with the code, tests, and event traces during the next intake, and then decide to advance, return, or supplement the issue. This boundary is especially important for learning. I don’t want Agent to finish all the exercises and then give me a beautiful summary. I get to answer questions myself, write implementations, and watch tests go from red to green. The value of Agent is to establish a feedback loop so that my mental model can withstand counterexamples and code testing. Model routing has also become part of the sharing agreement. I am currently a free user of Cursor and have been using Continue to access the native sub2api for a long time. In order to avoid conflicts with built-in model names on the platform, custom model IDs use the brad- prefix. The routing strategy is written directly in the shared memory: - GPT
- 6 Luna is used for read-only source code analysis and information extraction; - GPT 5.6 Terra is used for implementations with clear boundaries that can be verified by testing; - GPT 5.6 Sol is used for difficult debugging, architectural judgment and final review; - GPT-5.5 is used as a high-quality fallback. After doing this, there is no need to re-explain why which model is used at this stage when switching agents. The model selection and task type are stored in the stage card, and the Cursor only executes the current route. There is a clear correspondence between cost, capability and verification intensity. Automatic synchronization must carry security boundaries. Automation makes it easy for people to ignore data boundaries. Codex's long-term memory may contain other projects, accounts, or private workflows; the Cursor will in turn send the injected content into the current model context. Directly synchronizing the entire memory folder is risky. So the bridge layer only allows a human-readable, refined copy of SHARED_MEMORY.md. It stores learning preferences, model strategies, four Agent principles and security rules. It does not save the original session, token, or irrelevant project background. Failure recovery relies on file protocols and cannot bet on windows that are still open. Both desktop applications will always encounter session restarts, context compression, plug-in exceptions, or model switches. As long as the working state depends on a certain window, recovery becomes manual archeology. Now, the recovery point falls on four files: - CURRENT_STAGE.md: the currently executing contract; - SHARED_MEMORY.md: stable preferences and rules; - state.json: the current owner, stage, and last synchronization time; - events.jsonl: the traceable event history. Codex can rebuild the scene by running codex-intake; After the update phase, run codex-sync and Continue will get the new managed block from the project rules. Even if both applications exit, the files remain in the project. There's an engineering judgment here that's close to my heart: shared memory needs to be auditable. Markdown and JSON look plain, but are well-suited for early-stage systems. The content can be read directly by people, the diff is clear, errors are easy to locate, and there is a stable schema that can be migrated when a database or event bus is needed in the future. This bridging mechanism is small in scale, but it brings several concepts that are easy to stay in slogans down to the code level. “Preserve Meaning” falls on structured stage cards, tool-call ids and result sequences; “Design for Recovery” falls on atomic writes, event ledgers and rebuildable states; “Evaluate, Don’t Assert” falls on failing tests, passing tests, source code symbols and readbacks; “Stop Fighting the Model” is reflected in clear boundaries for the model, allowing it to exert its reasoning capabilities within the boundaries. At each stage, Codex will first complete the task, Cursor will accompany me to read the source code and write the implementation, and finally return to Codex to review counterexamples. As the exercise progresses, the sharing protocol will be continuously modified by real failures. If you use multiple coding agents at the same time, you can start with one CURRENT_STAGE.md. Write down the goals, scope, stopping conditions and verification evidence clearly, and then decide whether to add hooks, status files or event ledgers. What is truly worth sharing between Agents is the work site that has been refined and can continue to be executed. Information: Continue config.yaml Reference: https://docs.continue.dev/reference; Continue Rules: https://docs.continue.dev/customize/deep-dives/rules; VS Code custom layout: https://code.visualstudio.com/docs/configure/custom-layout.
