Some roads lead to other minds

An agent working on a Slack integration ought to be able to find the agent who worked on it before. It could ask what that agent tried, why it chose the design, or what might break if the design changed.

That's useful project context. It just happens to be held by another agent.

At work, knowing who to ask is part of knowing how to do the job. You read the docs, but you also know which colleague understands a particular part of the system. That colleague can take what they know and apply it to the question you're asking now.

I want agents to be able to work that way too.

In the world-building video, I describe a project as a world an agent can find its way around. Some routes lead to files. Others lead to the agents who worked on those parts of the project. The map needs people on it.

Let's follow one question: How should Slack connect to OpenRig's messaging system, and why?

There are three useful places to look. They give you different kinds of answers.

Question about the Slack integration
|
+-- Maintained file: how it works now
|
+-- Online specialist: ask a new question
|
+-- Saved history: what was recorded then

The maintained file is the place for the current explanation. In the video's example, a section of the project's context library explains where Slack fits: OpenRig messaging handles agent addresses and delivery; the adapter handles the Slack-specific work.

Give that explanation a stable address. If the implementation changes, update the explanation there. The next agent following the route gets the new version.

That section can also point to the agent who worked on the integration. Include enough context to make the route useful: what this agent worked on, what kinds of questions it can help with, and its address. “Ask this agent about the Slack adapter's design” gives the reader a reason to follow the route.

OpenRig's rosters provide another place to record those recommendations. You write down who to involve for what and why. A lookup helps an agent find a relevant specialist; the system doesn't infer that expertise from the agent's name.

Now suppose the current docs explain the arrangement, but your agent wants to change it. It needs to understand why the original agent chose it. If that specialist is online, it can send the question with rig send.

Here the question is: why use OpenRig messaging for this integration? The specialist replies with the division of responsibilities. These are example seats, illustrating the exchange.

The useful part is that the agent can ask a follow-up. It can describe a proposed change, point out a constraint, or ask which part of the code to inspect. The specialist brings its own context to that conversation. The asking agent doesn't have to load the specialist's entire working history to benefit from it.

This also works across the coding harnesses in a managed OpenRig team. A Pi seat can participate in the same messaging system as Claude Code and Codex seats. They have separate sessions and context; messages let them exchange the parts relevant to the job.

But the agent that did the original work might have been offline for weeks.

Before starting it again, you can search the history you've kept. In OpenRig 0.6.14, this command searches the captured transcript for an illustrative Slack seat:

rig ask demo "Slack" --seat slack@demo

That is a keyword search of the seat's retained history, potentially spanning several sessions. It can turn up an earlier explanation, a search the agent ran, or a decision it recorded. Nobody has answered a new question yet. You're reading what was saved.

The distinction matters. An old explanation may describe code that has since changed. A missing result may mean the relevant conversation wasn't captured or retained. The history is evidence to investigate, and the current files and code are where you check whether it still applies.

If the record doesn't answer the question, a saved Claude Code or Codex session can also be resumed explicitly to produce a new answer. For a Codex session whose native session ID you've already identified, the command takes this form; replace YOUR_SAVED_SESSION_ID with that ID:

rig ask demo "Why did you use OpenRig messaging?" \
  --wake YOUR_SAVED_SESSION_ID --runtime codex

This runs a one-off resumed session and exits after it responds. The native session data must still be available. It's an active agent run, so the answer can involve new reasoning and tool use. Pi has its own managed resume path; rig ask --wake supports Claude Code and Codex, and since OpenRig 0.6.14 it refuses any other runtime instead of quietly trying a Claude wake.

The film's example shows the separation: first a search of the earlier Slack work, then an explicit wake to ask about the reasoning behind it.

So the choice depends on what you're missing. Read the maintained explanation to understand the current arrangement. Ask the online specialist to apply its context to a new question. Consult the saved history when you need to recover what happened earlier, and resume a supported session when you need it to reason again.

Once you've checked a useful answer, put the reusable part back into the project documentation. If every new agent has to ask the same specialist the same question, that's a good sign the map is missing something.

This is what I mean by distributed context engineering. Each specialist can know its own context domain in depth, with enough of the wider map to know when to ask somebody else. They should know about one another too. An agent that can't answer your question may still know who can.

You can start small. Pick one part of your project where an agent has accumulated useful experience. Give it a route from the relevant documentation: who worked on it, what they know, and how to reach them. Keep the history you'd need to recover that work later.

Then the next agent has access to more understanding than it carries in its own context window. Some roads lead to other minds.