Have you ever had a moment like this? After finally spending an hour in group chat and two hours in meetings getting the problem aligned with your colleagues, you are ready to put the Agent to work—only to realize that you now need to spend another 20 minutes retelling the Agent the background, the problem, and what needs to be done. Along the way, you may also have to hunt down a document here and take a screenshot there to feed it. And often, after the Agent produces its output, you discover that some details were not explained clearly, so you have to explain them again, find the materials again, and make it start over. The Agent did work for you, but you did not save any of this fragmented time.
There are even more moments like this: the Agent finishes its work and gushes out a huge pile of material. You give it a casual scroll and can see neither the top nor the bottom. Suppressing your fear of reading, you start the review; when you finish and look at the time, half an hour has passed. And that is before those moments when a colleague throws you a long block of Agent-generated material and code to review. If you do not read it, you worry something will go wrong; if you do, it takes serious effort.
Anyone who has worked on a team that uses AI heavily has probably encountered the situations above. They reflect two major pain points in how we work with Agents today:
- Context is scattered everywhere, and building context for an Agent consumes a great deal of human time;
- Agents generate very quickly, but human review speed is limited, making human review the new bottleneck;
Because these two problems exist, time spent on one part of our work rises as time spent on another falls. When we look back in the end, we have barely saved any time at all.
My team has recently been exploring this question: in the era of the Human-Agent Team, how can we genuinely improve team efficiency? Why focus on the team instead of the individual? Because everyone on our team is an AI expert. Each person has their own way of working with agents and already has their One Person Enterprise (OPE) running smoothly; that is not a problem at all 😅. But once the work moves into team collaboration, things change. All kinds of small frictions keep everyone from reaching the efficiency they achieve when working alone.
Before doing this work, I conducted research within our team. The two pain points above were the top two findings, with almost identical shares. A closer analysis shows that the second is affected by the first: when Context is sufficient and high-quality, the probability that an Agent produces a reliable result on the first try increases, the number of reworks falls, and the number of human reviews also falls. To some extent, this eases the review bottleneck as well.
So Context—a word that has already become somewhat “outdated” on social media—remains extremely important. In team collaboration, Shared Context is an important part of improving the efficiency of collaborative work.
With Shared Context, people no longer need to repeat information that the team has already agreed on when talking with an Agent, allowing the Agent to start work more quickly. At the same time, when someone faces a new task without knowing the background—perhaps because they are newly hired or taking over new work—they can ask the Agent directly, rather than spending time finding the right person and then more time aligning information with them. Even the person handing over the work does not need to spend time writing a handover document, because all the information has already been Captured by Shared Context; someone else can simply ask an Agent and find out. And so on. You will discover that a major missing piece preventing our team's Loop from turning today is Shared Context.
Many people may think that building Shared Context is simple. In essence, it is just building a Knowledge Base. Write a script that periodically pulls down the team's group chats, meetings, and emails into one unified place, such as a Github repo. Throw in all the team's documents and materials as well, then let the Agent treat the information there as context. Wouldn't that be enough?
Karpathy's article roughly describes this kind of model. Yes, this approach can work for an individual. But in team collaboration, we have found many problems that this model cannot solve well. For example:
- When things in the Raw Context Files conflict—A writes in a document that the release is this week, while B says in group chat that the release is next week—which one should the Agent treat as correct?
- When the semantics in the Raw Context Files are not clear enough, the Agent interprets them according to meaning A the first time and meaning B the second time, causing its later behavior and judgments to swing back and forth. What then?
- With a personal knowledge base, if you find something wrong, you can correct it later because you know all the Raw Context. But in a team knowledge base, there is a great deal of context you do not know at all. When an Agent gives you a conclusion based on unknown context, you cannot spot the problem, much less correct it. How do we solve this trust problem?
So our team believes that building Shared Context requires a new solution.
First, Shared Context must be trustworthy and traceable. This is the foundation that lets both people and Agents on the team dare to consume this Context. Therefore, we collect raw information, but we do not consume it directly. Raw information exists only as the lowest link in the chain of evidence. Above it, we rebuild a layer of source of truth: context that has been filtered, distilled, and confirmed, serving as stable context for downstream Agents to consume.
Second, it needs to be consumable by both people and Agents. Agents need Shared Context when they work, but people also need Shared Context to understand project background and obtain project progress quickly, so that we can reduce the time people spend repeatedly aligning on background. But Markdown files that are suitable for Agent consumption are not the best solution for human consumption. So we crafted an interface that presents Shared Context clearly, allowing people to find the most important information at a glance.
Third, the cost of maintaining Shared Context must be low enough. Otherwise, as Context accumulates, its maintenance cost will eventually exceed the benefit of using it. This is also why many people ultimately abandon a knowledge base: maintenance is expensive, so they do not want to maintain it → Context quality gets worse and worse → the benefit of using it gets lower and lower → they eventually abandon it. In our solution, Shared Context is automatically updated from continuously changing raw information, minimizing manual maintenance steps as much as possible.
Finally, only a self-contained loop that can complete tasks creates genuine efficiency gains. Our principle here is that users should be able to complete the full task loop with whatever Agent tool they use; we do not require them to migrate away from an Agent they already use comfortably. So we provide a set of onboarding tools for Personal Agents, enabling any Agent to use this Shared Context, automatically claim low-risk tasks, complete them, and update Shared Context, forming a complete loop.
Ultimately, through Shared Context and its supporting tools, we hope to achieve this goal: in team settings, people can understand project status at a glance and put an Agent to work with one sentence; meetings are kept to a minimum, parallel work is maximized, and team efficiency genuinely improves.
We believe in this vision. But during real development, we have discovered that building trustworthy Shared Context is far more complex than we imagined. We will keep exploring, and I will keep sharing the pitfalls we encounter and the experience we gain along the way, to see how far we can go.