A Context Layer for Teams

Most teams already have the raw material for a context layer. It is sitting in Google Drive folders, spread across Word docs, PDFs, and slide decks. Meeting transcripts exist too, but they often live in whatever tool captured them, in someone's downloads folder, or nowhere after the call. Slack holds another large part of the story: quick answers, decisions, follow-ups, and context that never makes it back into a durable record.

That is already a lot of context. The problem is not that the team knows nothing. The problem is that the knowledge has no stable shape.

A project, client, product area, or service ends up with several partial histories. There is a folder in Drive. There are a few decks. There may be notes in docs. There are transcripts somewhere. There is a Slack channel where important decisions were actually made. People can usually find pieces of the story, but they still need to ask around to reconstruct what happened, what matters now, and where the current version lives.

That is the gap a team context layer is trying to close.

What the team is trying to achieve

The target is not a grand knowledge graph on day one. It is a shared working memory that feels dependable.

A person should be able to open one project, client, or service record and see the current files, the latest meeting notes or transcripts, the active decisions, the owner, and the next actions in one place. If someone asks what changed this week, the answer should point back to the files, transcripts, or Slack threads it came from. If a teammate or agent picks up the work tomorrow, they should not need to rebuild the history from scratch.

That is the user-facing test. If the system does not make handoffs, search, and follow-up work easier, then it is not solving the real problem yet.

What a context layer is

A team context layer is not a replacement for Drive, Slack, or the transcript tools people already use. It is a thin shared layer that keeps the important facts and source links in one structured place.

That distinction matters. The Word doc can stay in Drive. The transcript can stay in the call tool or be saved back to Drive. The Slack thread can stay in Slack. What the context layer adds is a stable record that says: this project exists, these are the important source materials, this is who owns it, this is what changed recently, and this is the set of materials a person or agent should read first.

Once that record exists, people and agents stop starting from a blank search box every time.

Why this matters now

For years, teams could get away with partial answers. One tool handled docs. Another handled tickets. Another handled service metadata. The gaps were real, but people patched around them with meetings, Slack, and memory.

That starts to break down when an agent is expected to answer a question, review a change, update a service, or run a workflow. The agent needs more than documents. It needs a stable record, clear ownership, linked sources, and a clear place where updates are supposed to land. It also needs to know which slice of the system it is allowed to see.

That is why the useful versions look less like bigger wikis and more like small structured systems with generated views. What matters is keeping files, transcripts, decisions, ownership, and permissions aligned as the organization changes.

How I would start

I would still start narrowly. Pick one thing the team repeatedly needs to reconstruct. That might be a client account, a product area, an internal service, or a major project. Do not start by trying to model every document and every conversation in the company.

The first job is not to move every file out of Drive. The first job is to create a dependable record for that one thing and link the important source material to it.

One concrete first version

For a first working version, I would use this stack.

The database is not where the Word docs, PDFs, decks, or Slack threads go. Those can stay in the systems where they already live. The database is where the shared record lives: the thing you open first, the thing an agent reads first, and the thing new material gets attached to.

Model the record and its sources

For a team that is starting from Drive, transcripts, and Slack, I would model two things: the record itself and the linked source items around it.

create table context_records (
  id uuid primary key default gen_random_uuid(),
  slug text unique not null,
  kind text not null,
  title text not null,
  owner text not null,
  status text,
  summary text,
  last_reviewed_at date,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now()
);
create table source_items (
  id uuid primary key default gen_random_uuid(),
  record_id uuid not null references context_records(id) on delete cascade,
  source_type text not null,
  title text not null,
  url text not null,
  source_updated_at timestamptz,
  added_from text,
  created_at timestamptz not null default now()
);

That is enough shape for a first version. One table says what the team is tracking. The other table says which files, transcripts, and Slack threads matter for that record. Supabase recommends lowercase table names with underscores, which is a sensible default to follow.

Build it in this order

That is enough for a first version: one shared record, linked back to the source material people already use.

What the user should see

The user experience should stay simple. Open a record and see the owner, the current status, the important files, the recent transcripts, and the links back to the Slack discussions that still matter.

If the record is useful, the team stops asking where the latest deck is, where the transcript went, and which Slack thread had the decision. The page answers those questions directly.

What the agent should see

The agent should not scrape the HTML page. It should read the same record and source list directly. In MCP terms, a record can look like this.

{
  "uri": "context://project/acme-renewal",
  "name": "acme-renewal",
  "mimeType": "application/json",
  "text": "{"kind":"project","owner":"revops","status":"active","sources":[{"type":"drive_ppt","title":"Q2 renewal deck","url":"https://drive.google.com/..."},{"type":"transcript","title":"2026-04-12 customer call","url":"https://drive.google.com/..."},{"type":"slack_thread","title":"pricing discussion","url":"https://slack.com/..."}]}"
}

That follows the existing MCP shape: resources have URIs, clients can list them, and clients can read them. The same record can then appear in the Next.js page for a human and in the MCP response for an agent.

Be literal about policy

Policy should stay equally concrete.

Supabase is explicit about this: once RLS is enabled, no data is accessible through the public API until you create policies. That is useful here. It forces the team to decide who can read which records before the system sprawls.

What good looks like after one month

After a month, the goal is not a platform launch. The goal is something smaller and more concrete.

If you can get that far, the next steps become much clearer. You can add a second kind of record. You can automate how transcripts get attached. You can flag stale records. At that point, the team is maintaining a small piece of infrastructure rather than talking about the idea in the abstract.

Sources