When I was little, and I wanted something like, say, candy or toys, I would ask my mom if I could have it. Almost always, my mom would say no, and then I would ask my dad the same question. And more often than not, my dad would say yes. The same question asked of two different people with different contexts and experiences gave different responses. If I were pattern matching, I could choose which parent I asked to get the answer I wanted.
Agentic chat experiences work the same way. How the model responds depends on its reasoning and context window, how the question is asked, and what the system instructions are. What is in the context shapes the answer.
By default, these AI systems are single-player: one user, their memory and context, one-to-one. And we can choose which AI-generated information, assumptions, and conclusions to bring to the team discussions.
Different perspectives can be useful. What makes these differences a problem for collaborative work? The challenge is that the resulting documents may carry incompatible assumptions we need a way to discover and resolve.
Single player context
All of us are being asked to use AI to bring workflow efficiencies at work. People have been trying and learning tools available to them from rudimentary co-pilot agents to a robust system of agents, rules, and skills. Keeping the context shared, current, and relevant between a team is a much harder problem to solve.
What happens when a BRD, a PRD, and an architecture design disagree, and each came from a different person’s AI? Whose context takes precedence? How do you determine conflicts? Who determines provenance? What gets written in the context? What gets excluded?
If everyone is working from their own individual context, or selective context from everyone else, then we are not collaborating in a multiplayer system.
A team needs to be able to rely on decisions and context developed in individual AI conversations. Storing the documents in a common repo may start the process. The harder question is which document becomes the source of truth and governs the work, what happens when the decisions change, and who resolves conflicts. And, that’s why context engineering is as much a product and design problem as it is an engineering problem.
Making context multiplayer
So, what does the multiplayer AI system look like? A system where multiple users can share context, rules, and memory and work as a team within the established constraints of an organization.
The constraints I am thinking of are improving product managers’ decision-making and product thinking with quality requirements, and creating a scalable system of standardized requirements that frees up a PM’s time for learning and problem discovery. The challenge is maintaining the context that PMs can share.
My current thinking is that the shared context, derived from conversations and explicitly curated by humans, should live in a place where teams already collaborate, like GitHub.
Shared context can be at the team level, application or project level, or org level. Then there are the rules by which the context can be managed.
Where do we start, and how do we maintain it?
Consider the following rules:
Define where the context applies. A constraint on one application may not apply to another application involved in the same project. We need to know which context is shared across the team and which belongs to a particular piece of work.
Keep team context with the team’s work. Decisions and constraints that belong to a team can live in the same repo as its product documents, where engineering and architecture can see them too. Context that applies across the org, like shared platforms and policies, should come from one shared place, so every team and its tool doesn’t build its own copy.
Keep a source for the context. If a decision is already written in a product document, the shared context can point to it. If it came from a conversation, someone needs to confirm what was decided and where it applies. Otherwise, how do we distinguish an individual assumption from a decision the team has agreed to?
Select the context needed for the work. How much context is enough to write a requirement or assess a change? What gets excluded? If something necessary is missing, the agent should identify the gap before treating an assumption as a requirement.
Preserve the details needed to understand a decision. We could summarize, but it might miss key details. We could take the top and bottom context, but may miss out context in the middle. The agent should store the decision, the reason for it, and any exceptions, with proper citations to the source.
Make conflicts visible. When the BRD, PRD, and architecture design disagree, someone needs to resolve the disagreement. The agent should show the conflicting context and ask a human, rather than choosing an answer that the next person may assume was agreed.
Let the product documents govern. When the shared context disagrees with a product strategy, spec, or feature, the document should govern the work until someone changes it. The documents are where those decisions get recorded.
Decide how context gets updated. Who maintains it? When a decision changes, what happens to the old context and the work that relied on it? Keeping that context current, relevant, and accessible at the right altitude may be the biggest challenge.
How is your team building shared context today?