# Some roads lead to other minds

2026-10-22 · Mike

The agent that solved a problem last month can still be useful to the agent working on it today. Here is how I connect project documentation, specialist agents and saved history.

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](https://openrig.dev/blog/how-my-agent-teams-find-their-way), 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.

![A map with people at the library, cabin and workshops, connected by roads from the arrival clearing.](/blog-assets/some-roads-lead-to-other-minds/wide-map-1280.jpg)

*A useful project map includes who knows the area and how to reach them.*

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.

```text
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](https://openrig.dev/features/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.

*Demonstration: Ask an online agent with rig send. The agent who worked on Slack is online, so the builder runs rig send slack-original@demo "Why use OpenRig messaging?". The reply arrives in the builder's terminal: messaging handles agent addresses and delivery, and the adapter handles Slack-specific work.*

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:

```sh
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:

```sh
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.

*Demonstration: Ask an earlier session with rig ask. The agent who built the Slack work is offline. rig ask demo "What did you search for?" --seat slack@demo searches that seat's saved history and returns excerpts: it searched for Slack, found leftover pieces and concluded the integration had barely started. Then rig ask with --wake slack@demo@2 explicitly resumes the earlier session to answer: it treated what it found as all that existed and missed the existing messaging system. The resumed session answers once and exits.*

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.

Source video: https://youtu.be/CYRJDTcTKhQ