Definition
Team-shared agent knowledge is the infrastructure that turns individual agent session outcomes into searchable, replayable, reusable assets available to every engineer on the team — so one person's solved problem stops being one person's solved problem.
Quick breakdown
| Shared capture | Every engineer's sessions land in a storage tier the team can query. |
|---|---|
| Searchable index | Semantic and keyword search across every session, scoped by project, author, or error. |
| Replay | Any engineer can step through any recorded session to see how it ran. |
| Skill library | A git-versioned directory of skills extracted from the team's best sessions. |
| Access controls | Project boundaries and provider-key scopes so shared does not mean global. |
The knowledge problem in agent teams
One engineer discovers a breakthrough sequence. Without a shared system, that knowledge stays in their head, or in a Slack thread that scrolls out of view.
A software team figured out how to ship code without this problem a long time ago. Git, pull requests, code review, CI. Every change is legible to everyone. An agent team on its own doesn’t inherit any of that infrastructure. Sessions happen on individual laptops. Transcripts land in per-user SQLite files. The patterns one person discovers — the right prompt for a tricky refactor, the exact tool sequence to debug a flaky test, the workaround for a provider’s rate-limit behavior — are locked to that user’s machine unless the team deliberately lifts them out.
The cost isn’t conceptual. It’s wall-clock engineering time. For example, a team of five running ten sessions a day produces fifty daily opportunities to capture a reusable pattern. Most teams capture zero of them. The forty-nine that fall through the floor become the substrate for a slow tax: every month, the team can end up collectively re-solving problems it already solved.
What shared knowledge looks like in practice
Engineer A Engineer B Engineer C
│ │ │
▼ ▼ ▼
Session Session Session
│ │ │
└──────────┬─────────┴─────────┬─────────┘
▼ ▼
Shared tapes store Shared skills repo
│ │
▼ ▼
Search / replay Loaded by next run Concretely, a team with shared knowledge infrastructure can:
- Find the session where a teammate fixed the Kafka timeout last sprint, by describing the problem in natural language.
- Replay a colleague’s debugging run to see which tool calls worked and which failed.
- Invoke a skill extracted from any teammate’s session, without knowing it existed.
- See, at a glance, which patterns are invoked most often across the team’s projects.
None of these moves require asking a person to remember anything. The archive is the memory.
Individual vs team-shared agent operation
| Individual mode | Team-shared mode |
|---|---|
| Sessions stored locally on each laptop | Sessions replicated to a team-accessible store |
| Insights communicated in Slack, if at all | Insights searchable across every teammate's history |
| Skills recreated per project by each engineer | Skills checked into a shared repo, versioned |
| Onboarding: "ask someone who's done this before" | Onboarding: "search the archive and invoke the skill" |
| Team capability = strongest individual | Team capability = union of every engineer's best sessions |
The second column is not more software. It is the same software, pointed at a different storage tier, with intentional practices layered on top.
How sharing actually scales
For example, a team of 5 engineers each running 10 sessions a day generates 50 daily opportunities to capture a reusable pattern. Without shared infrastructure, 49 are lost.
The compounding effect tends to take a quarter or two to become visible. In the first week, a shared archive can look like a curiosity. By week four, a new engineer can search for “how do we handle Postgres timeouts” and find real examples. By week twelve, many sessions invoke a skill that originated from someone else’s work. The team’s effective velocity stops being bottlenecked by any individual’s experience.
This is the compound interest argument for treating agent sessions as team data. The ROI of the first captured session is tiny. The ROI of the thousandth is the reason a team adopts the practice. The mechanics of that compounding live in continuous agent improvement.
Where sharing has to stop
Team-shared does not mean ungoverned. A shared store that spills credentials, leaks customer data, or mixes unrelated project contexts creates more problems than it solves. Practical boundaries:
- Project scoping. Sessions tag themselves with a project identifier. Search queries default to the caller’s projects. Cross-project access is explicit.
- Credential hygiene. Keys used by one engineer’s session do not leak into another engineer’s replay. The proxy redacts at capture time.
- Retention. The team decides how long sessions persist. Skills persist; raw sessions age out.
- Sensitive data. Some sessions — security incident response, customer-support replays — require private storage or deletion. The infrastructure supports exclusion lists at capture.
Sharing is a deliberate choice per session, per project, per class of data. The infrastructure makes the default sensible and the exceptions explicit.
Where Paper Compute fits
tapes is the capture and search layer; skill drafting is consolidating under the paper CLI; the shared skills repo is the team library; stereOS is where skills run when they involve executing code in an isolated environment.
Individual mode is the default. Team-shared mode is a practice. The shift from one to the other can be a high-leverage move for a team running agents.