# When Everyone Has AI Agents, Who Knows What They’re Doing? > Source: > Published: 2026-08-17 00:26:28+00:00 We started building OliverGraph to give teams and their AI agents shared context across GitHub, Slack, docs, and the other places where work happens. At first, we thought the main problem was retrieval. Company knowledge is scattered across GitHub, Slack, docs, tickets, and people so we could connect those systems and get the right context to the agent when needed. But we ran into another problem. Agent runs were becoming another place where important context lived. An agent also gets context directly from the engineer using it. An engineer might tell an agent that the team tried something before, that a customer depends on a certain behavior, or that there's a constraint that isn't documented anywhere else. The agent uses that context while doing the work, but when the run ends, it can disappear with it. The next engineer's agent may see the resulting code without knowing what context was given to the previous agent. This gets messier during outages. Several engineers might be investigating at once with their own agents. One agent rules out a recent deploy while another discovers an issue with a database query. Those findings are now spread across separate agent sessions, and another agent might spend time investigating something that was already ruled out. Companies have fragmented context. One engineer remembers an old outage and another engineer remembers that the team already tried an approach but abandoned it. So we ask each other. You might not know the answer, but you know John worked on that part of the system. John remembers the PR and the PR points to an incident. People slowly build a mental map of where all that context lives in the company. Agents don’t have that. As everyone starts using more agents, it becomes harder for humans too. My agent may be changing onboarding while your agent is modifying authentication. Another teammate’s agent may have just discovered an API limitation that affects both. The team can suddenly have much more work happening than anyone has visibility into. We want to keep the useful history from agent runs and connect it to artifacts that exist within the company (such as PRs, docs, outages, etc.) If an agent changes a service, we want to capture what it was trying to do, what it changed, and why it happened. Then we connect that history to artifacts in OliverGraph: the code, PRs, conversations, previous agent runs, decisions, and people involved. When another agent starts working on something related, that history can be retrieved and fed back into its context. The next agent should know what previous agents already tried, and the team can see what those agents have been working on and why. If you’re running multiple coding agents across your engineering team, I’d be curious how you’re handling this today. We’re also looking for a few teams to try OliverGraph with us: [olivergraph.com](https://olivergraph.com/) so please send us an email at [ryan@olivergraph.com](mailto:ryan@olivergraph.com)