Shared Context Needs Somewhere to Live
TL;DR: Shared Context cannot stay inside personal agent sessions. It needs to be text-based, keep its history, and be shared by the team and the team’s agents. Those three conditions ended up shaping our choice of tool.
Context Had Nowhere to Land
In the previous post, I wrote about a problem we had started to feel: agents made each of us faster, but the context did not move with the work.
Discussions happened in Teams, Zoom, and Slack. Working context stayed inside personal agent sessions. Documents usually showed the final output, but not all the judgment and back-and-forth that produced it.
As soon as a discussion turned into execution, the next person, or the next agent, had to put the story back together first.
So the first question was not which tool to use. It was more basic: if Shared Context was going to become real team infrastructure, where would it live, and what form would it take?
Three Conditions We Could Not Get Around
First, it had to be text-based.
People should not need a special product just to read it. Agents should not have to work from screenshots or guess their way through a UI. In our pilot, Markdown for people and JSONL or JSON for machines was enough.
Second, it needed to keep its history.
The latest answer was not enough. We needed to see when a source changed, when a proposal became a decision, and when a generated artifact started going wrong. We needed a diff, not another round of “I remember it this way.” People make mistakes. Agents do too. History tells us where things went wrong and gives us somewhere to roll back to.
Third, it had to be truly shared.
Not “I send you a document, then you feed it to your agent.” The team and the team’s agents needed to see the same files at the same version. Otherwise we had just added another handoff, with a person stuck in the middle carrying things around.
The conditions came first. The tool came later.
Those Conditions Ruled Things Out
A personal agent session was great for getting work done, but it failed the sharing test. If the result was wrong, was the execution off, or was the original decision bad? Inside one person’s closed loop, the rest of the team could not tell. So much for collaboration.
Plenty of real discussion happened in Teams, Zoom, and Slack. But after the discussion ended, what remained was not a stable view of the team’s current state.
What about a folder on a shared drive? We considered that too. It worked well for people: everyone could open the same file, and some tools kept version history. With agents, though, it often turned back into downloading, uploading, and feeding files around. We needed to see a group of related changes together, not open the history of each file one by one.
We could have built a new platform. Then the pilot would have tested the platform before we had proved that Shared Context itself was useful. We would have built the kitchen before testing the recipe.
Once we put those tradeoffs next to the three conditions, the choice became clearer.
GitHub Was a Good Fit
GitHub gave us all three in one place.
Text is native. Every change leaves a history. A repo gives the team one address, while branches, commits, and diffs make changes easy to inspect. Our agents already work from repos, so, with the right permissions, they can read the same configuration and artifacts as the people.
In the pilot, we kept different sources, team configuration, human-readable Markdown, and machine-readable data separate, but inside the same repo. People and agents start from the same commit. When something changes, we look at the diff instead of arguing over which copy is current.
That is why we chose GitHub for this pilot. Not because Shared Context belongs in GitHub by nature, but because GitHub met the conditions without making us build another product first.
Somewhere to Put It Was Only the Start
Once we chose GitHub, we took the next obvious step. We put the discussions needed for the pilot, whether they came from chats, meetings, or GitHub work, into a place the whole team could access in different forms.
At least everyone could see the same material, people and agents alike.
Then came the next problem. If we could put everything in, should we? Does more information make Shared Context better? Once a chat, a meeting transcript, or a string of issue comments lands in the repo, does it become team state?
Putting everything in a shared place only makes it visible. Deciding what actually counts is where the trouble starts.
简单说： Shared Context 不能继续留在各自的 agent session 里。它得是文字，得留下变化历史，还得让团队成员和大家的 agents 看到同一份。这三个条件，最后也决定了我们选什么工具。
Context 一直没有落脚的地方
在上一篇里，我写了一个我们已经开始碰到的问题：agent 让每个人快了，但 context 没有跟着工作一起走。
讨论在 Teams/Zoom/Slack。干活时的 context 留在各自的 agent session。文档里通常只有最后的结果，中间那些判断和来来回回不一定跟得上。
一到把讨论变成执行，换个人或者换个 agent，都得先把前面的故事重新拼一遍。
所以一开始的问题不是选哪个工具。问题更朴素：如果 Shared Context 要变成团队真正能用的基础设施，它到底得放在什么样的地方，又会以什么形式出现？
三个条件躲不开
第一，得是 text-based。
人不需要打开一个特殊产品才能看，agent 也不应该靠截图或者猜 UI。我们实际用下来，Markdown 给人看，JSONL 和 JSON 给机器读，目前够用了。
第二，得有历史。
只留下最新答案不够。一个 source 什么时候变了，一个 proposal 怎么变成 decision，generated artifact 哪次开始跑偏，都得能回头看。我们需要的是 diff，不是再来一轮“我记得当时是这样”。人和 agent 都会犯错。有历史，才知道从哪一步开始错，也才退得回去。
第三，得真的能共享。
不是我发你一份文档，你再把它喂给自己的 agent。团队成员和大家的 agents，应该看到同一批文件、同一个版本。不然只是又多了一次 handoff，人还是中间那个传话、搬东西的人。
先有这三个条件，后面才是选工具。
三个条件也排除了一些东西
个人的 agent session 很适合把活干完，但过不了共享这一关。如果一个人的 agent 执行结果没达到预期，到底是执行跑偏了，还是当初的 decision 就有问题？关在个人的 closed loop 里，团队根本看不出来。那还谈什么合作。
Teams、Zoom、Slack 里有很多真实讨论，但讨论结束后，留下的并不是一份稳定的团队当前状态。
那 shared drive 里的 folder 呢？我们当然想过。对人来说，它很方便，大家能看到同一份文件，有些也有版本历史。可一到 agents 这里，又容易变成下载、上传、重新喂一遍。单个文件也许能回到旧版本，但我们想看的，是一批 context 在同一次变化里到底改了什么。
那要不要干脆新做一个平台？但这样一来，这个 pilot 很可能先忙着验证平台，Shared Context 到底有没有用，反而得往后排。这就是为了一根葱，先做了一桌菜。
把这些取舍和前面三个条件摆在一起，选择才慢慢清楚。
GitHub 是个合适的选择
GitHub 刚好把这三件事放在了一起。
文字是原生的。每次变化有历史。Repo 给团队一个共同地址，branch、commit 和 diff 又让变化可以检查。我们的 agents 本来也会从 repo 工作，只要权限允许，它们就能和人读同一份配置、同一批 artifact。
这两周的 pilot 里，我们把不同形式的 source、团队配置、给人看的 Markdown，还有给机器读的数据分开存放，但都留在同一个 repo。人和 agents 从同一个 commit 开始工作。东西变了，我们看 diff，不用再争哪一份才是最新的。
这就是这个 pilot 最后选择 GitHub 的原因。不是因为 Shared Context 天生就该放在 GitHub，而是它满足了这些条件，又不需要我们先造一个新产品。
有地方放，只是第一步
选了 GitHub 以后，我们很自然地往前走了一步：把 pilot 需要的团队讨论，不管原来来自 chat、meeting 还是 GitHub work，都以不同形式放进这个团队共同访问的地方。
至少大家都能看见了。人能看，agents 也能看。
然后新问题来了：既然能放，是不是应该全放？信息越多，Shared Context 就越好？一段 chat、一份 meeting transcript、一串 issue comment，进了 repo 以后，就都能算 team state 吗？
把所有东西放进一个 shared place，只解决了“看得见”。至于里面什么算数，麻烦才刚开始。