AI for Teams: Team-in-the-Loop

Most AI deployments give every employee their own copilot and stop there. A team of 50 ends up with 50 private agents, each knowing nothing about what the other 49 are doing. The org chart groups them as a team. The AI architecture treats them as 50 individuals who happen to share a Slack workspace. Insights, decision context, and domain knowledge stay locked inside each person’s chat history.

The agent needs to become a team member, with shared chats and shared memory, able to pull knowledge from anyone on the team and reach out to any person for clarification when it gets stuck. I’ve been calling this “Team-in-the-loop”: the entire team as the agent’s operating context.

50 individual copilots silo knowledge in private chat histories — each conversation starts from zero. Team-in-the-loop treats the whole team as the agent's operating context, accumulating shared knowledge that compounds across every interaction.

In a Team-in-the-loop setup, the agent belongs to the org, available to everyone. It accumulates knowledge by working alongside people over time.

When the agent has access to the whole team’s knowledge, it starts to resemble a junior team member who’s sat in on every meeting, read every doc, and can go tap someone on the shoulder when it needs to. It can check what Sarah documented last week about an exact edge case, because that knowledge is part of its context.

Team-in-the-loop treats people as active participants in the agent’s reasoning. The agent can ask Sarah directly, or surface a question to the engineer who built the service three years ago. The team is in the loop as collaborators.

Getting the agent to that point requires solving a problem that most teams underestimate: where does the team’s knowledge live, and in what form? The answer is almost never a clean, structured database. It’s scattered across Slack threads and support tickets and design docs that no one remembers writing.

The knowledge store has to be shapeless

The knowledge backing this can’t have a fixed schema. The moment you force organizational knowledge into a predetermined ontology, you lose everything that doesn’t fit, and what doesn’t fit is often the most operationally useful. A customer’s offhand comment in a support ticket. A design decision that only makes sense if you know the regulatory constraint behind it. The reason we chose Postgres over DynamoDB for that one service, which lives in a Slack thread from 2024. Knowledge is shapeless, and the store has to be shapeless too. It has to accommodate any possible structure and make anything presentable on demand, regardless of how it was originally captured.

Build a system optimized for structured data and the unstructured data either gets forced into the wrong shape or stays outside the system entirely. Anything outside the system is private context again, inaccessible to the agent, invisible to the team.

Every knowledge management tool I’ve seen makes the same bet: if we get the schema right, retrieval will follow. But recall quality depends on whether the knowledge fits the schema at all, and most organizational knowledge resists categorization. A single Slack thread might contain a product decision, a technical constraint, a customer insight, and a joke. No single ontology bucket fits cleanly, so the system either picks one and loses the rest, or fragments it across categories and loses the thread. Shapeless storage that defers presentation to query time is the only design that doesn’t lose information at write time.

Why mid-task retrieval fails

Most “knowledge-augmented AI” architectures fail at the same point: they let the model decide when to retrieve. The agent is halfway through writing your document and it autonomously decides to go fetch some context. Maybe it fetches the right thing, maybe it fetches something adjacent that muddies the output. That retrieval decision is a source of noise. Each autonomous fetch risks pulling irrelevant context, and those misses compound across the task.

This is specifically why MCP doesn’t work for this use case. MCP is a protocol for giving models access to tools, and the model decides when to invoke them. That decision layer is the problem, and the model shouldn’t be choosing mid-task whether to consult the knowledge base. The knowledge should be loaded before the task starts, curated by the system (or the human) based on what’s relevant.

Giving the agent MCP access to your knowledge base doesn’t solve the Team-in-the-loop problem. You still get autonomous, unsupervised retrieval decisions mid-task, and those decisions are where recall quality degrades. The curation step, deciding what the agent should know before it starts, is where the team’s knowledge becomes useful.

Letting the model decide when to retrieve introduces noise at each fetch decision. Pre-loading curated context before the task starts removes that decision layer entirely, producing cleaner results.

The API as connective tissue

The thing that makes all of this work end-to-end is that the agent is available via API. Same agent, knowledge base, and memory across every interface. A PM opens a chat with the agent through Linear MCP, describes what needs to be built, and the agent produces a spec with full context from the team’s knowledge. An engineer picks that up in OpenCode or Claude Code, and the agent already knows the spec, knows the architectural constraints, knows what Sarah said about that edge case. No context handoff, no “let me re-explain the requirements,” just one agent, one knowledge base, and multiple interfaces.

The API is connective tissue between roles. A PM's spec and an engineer's implementation share the same agent state — context travels with the agent, not as documents between people.

The API is the connective tissue between PM tooling and engineering tooling. The PM doesn’t have to think about how the engineer will consume the output. The engineer doesn’t have to ask the PM to re-explain. The agent carries the context across the boundary because both roles share the same agent state.

The knowledge doesn’t move between people as documents or handoff messages. It stays in the agent’s state, and the PM’s Linear workflow and the engineer’s coding environment are both surfaces into the same underlying system. What one role adds, the next role benefits from, and the spec-to-build cycle compresses because the context travels with the agent.

From individual copilot to organizational agent

The pieces are: shared memory, shapeless knowledge, pre-injected context, and a single agent exposed through every interface the team already uses. None of these ideas is new on its own. The combination is what produces a different kind of AI deployment, one that treats the organization as the unit of intelligence.

This is what we built Jitera to be. Shared chats where the whole team talks to the same agent, not 50 private conversations that forget everything by tomorrow. A knowledge store that accepts whatever shape your organization’s knowledge actually takes — Slack threads, support tickets, design docs, things no ontology would ever capture — and makes it available at query time without forcing it into categories first. Context that gets curated and loaded before the task starts, so the agent works with what it knows instead of guessing mid-task what to fetch. And an API that exposes the same agent state to every tool your team already uses: Linear, Claude Code, or anything else with an OpenAI-compatible endpoint.

The agent gets better the longer your team works with it. It remembers the design decisions from three sprints ago, the customer constraint that only one person heard in a call, the naming convention your team agreed on and never wrote down. It compounds organizational knowledge instead of losing it at the end of every chat session.

Team-in-the-loop is not a feature you can bolt onto an individual copilot. It’s an architecture decision — one that determines whether AI stays at the level of individual chat assistants or becomes something the team actually relies on. That’s what Jitera does.