I have Rules review a Forge plan and send it back through Cockpit

Let me walk you through the way I work; we are doing this as a guide. First of all, I have an agent: an agent I call the Forge agent, and it presents a report to me. Here it has produced a long report; at one point I told it to “keep it tight.”

The interactive flow below is not a row of unrelated screenshots. It follows the exact order in which I pointed at the screens while speaking:

Forge report
→ copy the report from the same conversation
→ architecture review in Rules
→ explicit approval to send
→ Rules → Forge route in Cockpit
→ delivery into Forge
→ context wall + COS + continue + final plan

7 screens · 20 steps · click to explore

1

1 · Forge report1

2 · Copy report1

3 · Rules review1234567

4 · Send approval12

5 · Cockpit route123

6 · Message in Forge1

7 · Continue with COS12345

The long Forge report

First, my Forge agent presents a long report. It explains the plan and architecture in detail; I tell it to “keep it tight.” In the next step I copy the relevant part of that report directly from the same agent conversation.

The long Forge report

Restart

← Back

Close

Click the active region to move in the order of the speech. The last region in each scene opens the next screen.

## 1. I take Forge’s report from the same conversation

First, the Forge agent presents its report; the screenshot above is how it reports. I then do not retell that report in my own words: I select the relevant report section inside the same agent conversation and copy that part. What reaches the reviewing agent is the agent’s own report, not a summary I produced afterward.

## 2. I report it to my Rules agent inside my own spoken conversation

Then I take this agent’s report to my own agent: I have an agent I defined as the rule agent (Rules), separate from Forge, and I report the plan to it. With Optionist, I place the report that agent gave me inside my own spoken conversation. The agent’s identity travels too — because I copied the message from the agent conversation, it reaches my main rule agent with the session part visible in the screenshot.

I hand it to my rule agent to review it against the rules; this agent knows my complete rule set. I generally use it for architecture work — because its cost is high — not for everything. Its own context is already very high at 72%.

After I copy the conversation in, Rules evaluates the Forge conversation: it works out what is sound in the plan according to my rules and what is missing. It then also says what the agent should do, and prepares the message that will go back to Forge.

## 3. Rules gets my decision before sending the message

I ask the agent to send this message. Here the agent shows the sending step, asking whether it should send; I say, “Okay, send it to them.” The agent messaging protocols look like this: these are different applications — this one is a Fable, the other agent is two different processes running with Codex and Ghostty. I tell it to send the message.

## 4. I send the message from Rules to Forge through Cockpit

The agent performs the send through Cockpit — again through optionOS’s Cockpit application. Cockpit is this application: inside it, the first agent (Rules) and Forge are two agents that actually talk to each other. For it to send, there is the paper-plane message button on the Rules card; I activate it and hand it over, and the Rules agent sends the message to Forge.

The delivered message tells Forge how it handled its work, what it should do, and so on. I see the message arrive in the Forge conversation. The copied source, the reviewing agent, my send decision, and the receiving agent therefore remain connected.

## 5. When Forge hits the context wall while preparing the final plan, I continue with COS

Afterwards, once its work is done, the agent presents the final plan to me from these instructions. But here we run into the agent’s context window: the part where the message was delivered is visible, and as you may notice, I have hit the agent’s context limit. The stop part here is the COS command I mentioned before: I use it to stop the conversation and trigger the injection. After the conversation hits the wall, I press the continue button — or rather, I type “continue.”

Then comes the part I call context injection: my COS command. It is a structure where I hand the agent’s conversation back — with its images removed — pruned message by message with my own approach and algorithm. There is absolutely no summarization here; no summarizing — think of it as data pruning only. Then the conversation starts again, and the agent goes back to work from the newly given instructions and finally starts presenting the plan to me. Once the plan is presented, what I do is say accept and have the agent build it. This is how I can work interactively with more than one agent.

## 6. The tools in this flow are separate, but they carry the same evidence

Finally: my agent is there as the Forge agent, the Rules agent was over here, and I use all of this — even while capturing this very speech — with my own application, Optionist. Optionist captures which agent I copied each item from: it showed all of them as Forge, Forge, Rules, Rules, Optionist, Forge. It even keeps a separate Claude icon for what it captured from Claude; what it captured from Forge sits in the Forge circle with the Forge label. While doing all of this, even while recording this speech, I use my own annotation tool: components like screen recording, GIF, and text capture.

The features present in this flow are:

Cockpit   → optionOS’s Cockpit application; makes the agent cards and the Rules → Forge message route visible
Dictation → Optionist’s own dictation application; collects my speech and copied agent messages on one timeline
Annotation → also inside Optionist; carries the regions I mark over screenshots, GIFs, and text in the same context
COS       → Optionist’s transcription-management command; stops at the context wall and continues by pruning data, without summarizing

This is how I let multiple agents message one another. When I am too tired to review my very large rule set by myself, I get support from an agent — I get that support even when I am not tired — and I can build systems that fit the plan and the architecture without friction. This was a feature I had already built for myself inside optionOS. I think this feature is especially critical for people who work with many agents.