AI is a building block. That was the argument in my last post. AI already helps my team in the ways you would expect. It helps us write code, draft plans, move work forward. Where it keeps coming up short is narrower and harder to name. It does not do the thing an experienced teammate does almost without thinking: surface the decision that matters and connect the dots, so someone lands on the right call instead of a defensible wrong one. That is the workflow I do not have an AI-native version of yet, and I am still working out what it looks like for my team.
I spent last week at a conference, a full week away from my team. While I was gone, the kind of gap I have been trying to close opened up. A question came up whose answer meant connecting a few things that lived in separate places and had only ever been connected in one person’s head, which this time happened to be mine. The team is more than capable, and they worked through it. It just took longer, and some of it stayed open, because the reasoning that would have connected those things quickly was not written down anywhere. What stayed with me afterward was structural. The reasoning had no home other than a person, so the moment that person was out of reach, so was the reasoning. It could just as easily have been anyone else on the team. And I spent that same week in room after room where vendors and sponsors were each trying to build some version of the thing that would have kept that from happening. The word they all reached for was context.
It came up so many times, from so many angles, that I started to suspect we were all using it to point at something none of us had defined.
So this is not a finished thought. It is the closest I have gotten after a week of listening and a longer stretch of chewing on it, and I am still not sure it is right. But it is the most any of this has clicked for me so far, so I want to try writing it down.
The person was the bridge
For a while I assumed the problem was that AI lacked context, and that the job was to go get it more. That holds right up until you ask when the context went missing, and there is no good answer, because it never did.
The individual systems, while not simple, exist already. The hard part was the reconciliation between them. Someone experienced holds the state of the code and the thread from three weeks ago and the decision nobody wrote down, all at once, and produces a judgment. That reconciliation was always the expensive part, always done partially, and it almost never got written down, because a person could get away with holding it. There was no cost to leaving it implicit. The person was the bridge.
None of this is new. It is a tale as old as teamwork. Teams have always tried to get this reasoning out of people’s heads and into something the rest of us can use, through documentation and curation and pruning and the constant updating that keeps any of it true. That work is slow and expensive, and most teams undervalue it right up until it is missing. Mine is no different. We pay that tax by hand, imperfectly, because functioning without it is worse.
What has changed is the urgency, because teamwork now includes agents. AI did not remove the person who did the reconciling. It ended our ability to leave that work implicit. An agent cannot do the intuitive, partial reconciliation someone does in a hallway conversation, and it will not quietly cover the gap the way a person did. So a gap that was always there, always a liability, suddenly has a cost attached to it, and you feel it at the scale of a team.
This is the bus-factor problem, at the scale of a whole team. Every one of us is holding reasoning that someone else would need. When anyone is out for a week, there is knowledge in their head, about the design system, or an infrastructure choice, or how the analytics are wired, that the rest of us would have to piece back together. The reasoning that connects our systems of record has been living in people, and it has always been one departure away from gone. That was easy to look past while someone was there to reconstruct it live, on demand, for free. It gets harder to look past as teams push more decisions onto more people and more agents, because for any of that to work the connective reasoning has to leave the heads it lives in.
What I want is a pit of success, so the right call is the easy one to fall into no matter who is or is not in the room that day.
Everyone was building a different house
Not every talk was about this. But context kept surfacing, and a striking number of the vendors and sponsors were each, in their own way, trying to fix some version of the same problem. Watching them not quite agree is what made me start pulling on the thread.
One team argued the answer is a single company-wide wiki, grown rather than built, where every entry carries a human’s name and an agent proposes changes a person accepts. Another argued you should not curate a store at all, because stores go stale, and you should generate context on the fly from a graph over your live sources. Another argued that flat files fall apart under many hands, and that you need a temporal graph that keeps the provenance of every derived fact through every merge and revision. Another argued the whole reason coding agents work and knowledge-work agents flail is that code has a repo, a history, tests, and an undo button, and knowledge work has none of them.
They sound like competitors. What I started to see instead was people building different houses for the same missing thing, each trying to find a place to keep the reasoning that used to live in a head. They looked like they were competing over context. Underneath, they were competing over where the bridge should live.
The bridge is a record
Here is the piece that made the rest click, at least for now. What we are missing is a record of the bridges: the reasoning that says why the code looks the way it does, why this account gets handled differently, why we stopped doing the thing we used to do. A bridge connects two systems of record, and the reasoning for why it connects them the way it does is content in its own right.
Which means the bridge is a system of record too.
I keep sitting on that, because it reorganizes how I see the whole problem. It is tempting to treat a bridge as plumbing between the real records. I think the bridge is a record. It gets built, which means someone had a reason. It can be inspected, which means the reason can be read. And it can fall down, which means that when one of the things it connects changes, the bridge might no longer hold, and someone has to know it was there in order to go check.
Any one of us, looked at this way, is a walking set of bridges. Take any engineer on the team. Somewhere in our components a value is hard-coded instead of pulled from the token, and the code gives no hint why. The reason is a call they made months ago, tied to an accessibility decision that lives in a doc almost nobody opens. The same thing shows up everywhere once you start looking. A cache holds for thirty seconds because of a commitment that lives in a contract and never made it into the code. A service runs in one region and not another because of a data residency rule no one wants to relearn. An analytics event carries a specific meaning, and the definition that makes the dashboards trustworthy lives in one person’s memory and nowhere else. In each case the bridge is the sentence connecting the two sides: this is done this way because of that, and if that changes this should be revisited. It exists in neither system. It exists in a person. When they are out, the bridge is out with them, unless somewhere along the way it became a record.
Who builds the bridges
If bridges are records, the next question is who writes them? And here the sharper instincts from the conference help. Nobody is going to hand-author the reasoning connecting their systems of record for the benefit of a future stranger. That has never happened and it will not start now. I am not going to either.
But an agent can propose a bridge.
It can look across the code and the thread and the ticket, derive a reasonable guess at why they connect, and put that guess in front of a person. The person ratifies it, corrects it, or throws it out. The correction gets captured, with a link back to where it came from, and it becomes a record the next developer and the next agent start from instead of rebuilding.
I want to be careful here. The agent is not the verifier. It does not know whether the reasoning is right or the decision was sound. That judgment stays human. What an agent can do is derive, propose, and expose, so the reasoning stops dying in someone’s head or a closed session. The machine drafts the bridge. The person says whether it holds.
It concentrates the hard problems, it does not solve them
Here is the thing though. Making the bridge a record concentrates the hard problems rather than solving them, and it puts them somewhere I can point at. The bridge goes stale when either side changes. It needs provenance, or it turns into a confident claim with no way back to its justification. Someone has to verify that a proposed bridge holds, and that someone is a human, at a cadence I do not yet know how to scale. I am not going to pretend I have solved that here.
Even so, locating the problem feels like progress. For as long as I called all of this context, the hard parts were smeared across a word that could mean almost anything, and I could not say where they lived. Naming the bridge as a record brings them into focus. Staleness bites on the bridge. Provenance is required on the bridge. Verification, the real kind, will have to happen on the bridge.
Framing it this way also lets me stop treating retrieval and recency as separate problems. While the reasoning lives in a head, you cannot find it, you cannot tell whether it is current, and you cannot tell whether it is right. Those are symptoms of the same missing home. A record with an address and a version answers the first two almost by construction. What is left is keeping it honest, which is the expensive part, for the same reason verification is: someone has to judge.
There is an obvious next question hiding in that ratify-and-correct loop, which is whether the system itself gets better at proposing bridges over time, instead of only accumulating better ones. That turns entirely on whether the correction signal can be trusted, which is harder than anything here, so I am leaving it alone for now. I raise it only so it is clear I can see it. The same goes for whether AI should be doing this reconciliation at all, and for how we ever confirm that ratified reasoning was sound. Those are their own questions.
What I have, and what I don’t
So this is where I am, for now. I think context was never the thing missing. It has been sitting in the records we already keep. The thing that lived only in people was the reasoning that bridges those records, and it was fine to leave it there right up until we asked something that was not a person to do the connecting.
I think those bridges have to become records of their own, built by agents proposing and humans ratifying, so that when any one of us is out of reach, the reasoning is still there for the people and the agents who need it.
I do have a hunch about where those records should live, and it points back to one of the houses I heard argued for. Of all of them, the wiki is the one I keep returning to, something richer than a pile of markdown files and still recognizably a wiki. I am not ready to make that case yet, so it is a piece for another day.
What I do not have is what that workflow actually looks like. I have watched, up close and recently, what happens without it, and I know I do not want the fix to be a person quietly put back into the wrong part of the loop to do the reconciling by hand.. I know the outcome I want. I am still looking for the mechanism.