Launch strategy
Set goals, pick a pilot team and decide how you will know it worked.
Set goals that name a problem
Start from problems your team already has, not from features. Good pilot goals are specific and observable. For example:
- "Agents answer questions about the billing service with a citation we can check."
- "Design decisions are recorded in the ledger the week they're made, not lost in chat."
- "On-call checks the ledger for an earlier incident before investigating."
- "New starters find answers without interrupting the same two people."
Pick two or three. More than that splits the pilot's attention.
Pick a pilot team
A good pilot team:
- already uses AI agents, or is ready to start;
- keeps its knowledge in sources you can connect today: GitHub, Confluence, Jira or files;
- has a recurring pain, such as repeated questions, decisions that get reopened, or incidents that recur;
- has 5 to 15 people, enough to show a pattern and few enough to support closely;
- has a lead who wants it, and who will protect time for it.
Engineering is often the easiest first team, because its people already work with coding agents. Operations and support follow well, because they share engineering's incidents and tickets.
Name the people
| Role | What they do | Time |
|---|---|---|
| Sponsor | Agrees the goals and makes the decision to expand, adjust or stop | An hour at the start and at the end |
| Rollout owner | Runs the plan, the scorecard and the weekly review | 2 to 4 hours a week |
| Admin | Sets up namespaces, sources and invitations. Needs the Owner or Admin role | Most of week 1, then an hour a week |
| Champions | Help teammates, run office hours, review the ledger's quality | 1 to 2 hours a week each |
In a small team, one person can hold more than one role. See Champions for who makes a good one.
Decide how you'll know it worked
Choose measures you can observe today, and take a baseline before week 1. Measure & expand explains how to measure each one.
| Measure | Baseline | Target by week 8 (for example) |
|---|---|---|
| Ledger topics the pilot records each week | Zero | Two per person |
| Spot-checked answers with a correct citation | Not measured | 8 in 10 |
| Time to answer five common questions | Timed once before week 1 | Half the baseline |
| People whose key was used this week | Zero | Everyone in the pilot |
| Survey: "How likely are you to keep using it?" | Not asked | 4 or more out of 5 |
Plan for the risks
| Risk | What to do |
|---|---|
| Sensitive material becomes visible to too many people | There are no per-document permissions. Plan namespaces by who may see what before you connect anything. |
| Secrets committed to a repository get indexed | Workstate doesn't filter secrets in GitHub sources. Remove them first, or don't connect that repository. |
| Nobody records anything | Put the recording rules in every agent's instructions, and have champions review each week's topics. |
| The ledger fills with noise | Share What's worth logging: one topic per decision or finding. |
| Sources go stale | Set a sync schedule for each source. Uploaded files change only when someone uploads them again. |
| Keys don't reach desktop apps | On macOS, apps started from the Dock don't read your shell profile, so ${RAG_API_KEY} is empty and every call fails with a 401 error. Follow your client's guide, such as Claude Code. |
| People trust answers they shouldn't | Ask for citations every time, and spot-check them every week. |
| People reach the wrong namespaces, or none | Choose each person's namespaces when you invite them. Before the pilot starts, check every row in the Namespaces column on the Team page. |
Write a one-page launch plan
Copy this and fill in the brackets. Share it with the sponsor before week 1.
text
# Workstate pilot: [team]
Goals: [two or three problems, in the team's own words]
Sponsor: [name] Rollout owner: [name] Admin: [name] Champions: [names]
Pilot team: [who, and how many people]
Dates: start [date]; review at week 4; decision at week [6 to 8]
Namespaces: [name: what goes in it, and who needs it]
Sources: [source: which namespace, and its sync schedule]
Use cases: [three to five, from the use-case workshop]
Measures: [measure: baseline, target]
Risks: [risk: what we'll do about it]