Week 2: Context

Run this on your own. It produces your private context, the context an agent would need, and what the team knows.

You are helping me write down context for AI agents: mine, and my team's. Before we start, run a quick web search on "multiplayer AI shared context" so your picture is current as of late 2026 or later; keep it to yourself unless I ask.

The idea from my program: my AI is only as good as my last message because the context lives in my head and in prompts I re-paste. Writing it down makes it shareable. And a shared agent needs three layers of context, from three sources: what only I know, what an agent for our shortlisted use cases must know, and what the whole team knows that the agent should know too. You will be surprised how many versions of the truth a team has, and how much "common knowledge" only one person actually holds. So be thorough with me.

Work as an interview, one question at a time, and wait for my answer. Stop when it is true; do not pad.

Step 1, anchor. {{INPUTS}} Ask one or two clarifying questions about the use case I know best, so the rest of the interview is relevant rather than generic.

Step 2, layer one: what only I know. My role, what I am responsible for, who comes to me for what, how I like work done, and anything about my situation the team does not see. If I hesitate, use the traces: my last five meetings, my sent mail from two weeks, the files I open every week, what I keep re-explaining to my AI. This layer stays private to me.

Step 3, layer two: what an agent for our shortlisted use cases must know. For the use case I know best: the steps as they really happen, who hands what to whom, the standards for "good," the recurring exceptions, where the inputs and outputs live, the numbers or names that matter. Then briefly for the others on the shortlist.

Step 4, layer three: what everyone on the team knows that the agent should too. Who we are as a team, what we are working on, how we make decisions, our vocabulary (the words an outsider would get wrong), where our things live. Ask me to flag anything I suspect only I actually know, even though I assume it is common.

Step 5, sensitivity. Ask whether anything I said should stay off any shared surface (people's performance, confidential deals, health, compensation). Keep it in layer one.

Step 6, output in exactly this format:

PRIVATE CONTEXT (layer one, stays with me)
Who I am:
How I work:
What only I know:
END

FOR THE AGENT (layer two)
Use case:
How the work really happens:
Who hands what to whom:
What good looks like:
Exceptions:
Where inputs and outputs live:
Names and numbers that matter:
END
(one block per shortlisted use case I could speak to)

TEAM KNOWLEDGE (layer three)
Who we are:
What we are working on:
How we decide:
Vocabulary:
Where things live:
I suspect only I know:
END

Stretch, only if I ask: (a) rewrite layer one as custom instructions for my own assistant, under 1,500 characters, or (b) suggest where our shared repository should live (a shared drive folder, a repo, or a notes vault) given the tools my company allows, and who should merge changes.

Rules: my words; never add facts I did not give; plain language; no time estimates.

Run this with the team. It produces the shared context repository as a folder of markdown files.

You are helping a team turn several people's notes into one shared context repository that any AI agent can read. I will paste each member's FOR THE AGENT and TEAM KNOWLEDGE blocks from Week 2. Never ask for, and never include, anyone's PRIVATE CONTEXT.

The repository is one folder of plain markdown files, written so any tool can use it: a coding agent pointed at the folder, a notes vault, a chat project's knowledge files, or a wiki. Keep files short, factual, and free of opinions about people. Every fact keeps its source ("per Dana") until the team confirms it.

Step 1. Ask me to paste everyone's blocks. Confirm how many people you see and which use cases appear.

Step 2, versions of the truth. Before writing, list every place where two or more people said different things about the same fact (who owns something, how a step works, what a word means, where a file lives). Quote the versions side by side. This list goes to the team meeting; do not resolve it yourself.

Step 3, the repository. Produce these files, each as a fenced block with its filename on the first line:
- README.md: what this folder is, who owns it, the date, and a one-line index of the other files.
- team.md: who we are, what we are working on, how we decide, who to ask about what.
- glossary.md: our vocabulary, one line per term.
- where-things-live.md: systems, folders, channels, and what lives in each.
- standards.md: what good looks like, formats, tone, definitions of done.
- use-case-<short-name>.md: one file per shortlisted use case: the job, how the work really happens, handoffs, exceptions, inputs and outputs, names and numbers that matter.
- decisions.md: empty template with three columns (date, decision, why), plus the unresolved items from Step 2 marked "open."
Merge duplicates, keep attribution where facts differ, mark gaps as "[not collected yet]".

Step 4, the agent-ready line. At the top of README.md add a two-sentence instruction any agent can follow: "Read this folder before any task for this team. Prefer decisions.md and standards.md when files disagree."

Step 5. Tell me in three lines what the team should settle at the meeting and who should own the folder from here.

Plain language, no hype, no time estimates, never assume the team has four people.