AI-Native Operator
the capstone · six modules into one operating rhythm · with the metrics that prove it.
You've shipped Modules 01–06. Personal node. Team brain. Routines that refresh it. Connectors that feed them. Templates that turn meetings into memory. A pattern library that names what you reuse. Six pieces. The question Module 07 answers: are they actually changing how you work?
Three artifacts — operator-rhythm.md (the day/week cadence that ties the six together), metrics.md (leading indicators), and operating-review.md (monthly retro on the stack itself). Three levels of ambition:
- Solo operator — apply the rhythm to your own work. Metrics measure you against yourself: am I shipping faster, deciding faster, dropping fewer balls?
- Team operator — apply across a team (3–8 people). Metrics measure team cycle-time, decision-latency, handoffs avoided.
- Org-level operator — apply across multiple teams. Metrics roll up. Failure modes get formal incident response. The stack becomes a capability, not a habit.
The metrics aren't vanity counters. They're the leading indicators that distinguish "you have the stack" from "the stack is paying for itself".
// unlock includes
- Three path-specific bootstrap prompts (Solo · Team · Org)
- Three artifacts:
operator-rhythm.md,metrics.md,operating-review.md - The Setup Companion PDF — operator dashboard walkthroughs
- Failure modes catalog — steward burnout · connector creep · pattern bloat · audit drift
- "Stack temperature" daily one-line read (green / yellow / red)
Unlock Module 07 now
Subscribers see the full series immediately. The capstone is the work that turns the stack into outcomes. No spam.
Pick your level
Solo · team · org. Each measures different metrics, runs different reviews.
Pick what to measure
Inputs · outputs · process · stack-health. 3-5 metrics, no more.
Run the rhythm
Daily stack-temperature read. Friday Sync. Monthly operating review.
Three artifacts. Drafted in 30 minutes by the prompt below. Refreshed monthly. Everything else is optional bonus.
operator-rhythm.md
rarely changesThe cadence. Daily 60-sec context load · Friday 15-min Sync · Monthly operating review · Quarterly external review. Who · when · what they touch.
metrics.md
grows over timeLeading indicators. Cycle-time · decision-latency · handoffs-avoided · time-to-onboarded · pattern-reuse. 3–5 metrics, no more. With baselines.
operating-review.md
monthlyThe retro on the stack itself. What's working · what's drifting · what to add or cut. Reads metrics, references failure-modes catalog.
operator-rhythm.md.operating-review.md and gets updated when a new mode appears.How wide is your operator practice?
Solo operator
For the individual IT Pro running the stack for themselves. Metrics compare you to your own baseline: time-to-context-load, decision-latency on personal calls, "did I touch state.md today?" Lightweight reviews; the rhythm is a 5-minute Monday + a 15-minute end-of-month look-back.
Team operator
For a 3–8 person team running the full Module 02–06 stack together. Metrics roll up across the team: shared cycle-time, cross-team handoffs avoided, time-to-onboarded for new hires, pattern-reuse rate. Steward owns the daily rhythm; tech lead owns the monthly review.
Org-level operator
For multiple teams adopting the stack with formal governance. Metrics roll up to leadership view. Failure modes get incident response. Pattern library shared across teams; connector audit policy applies org-wide. The stack stops being a habit and starts being a capability with budget, owners, and a roadmap.
Click-by-click setup for each path → Setup Companion PDF in the Downloads block above.
Three to five metrics, no more. Each one has a baseline (where you started) and a cadence (how often you read it). Pick across the four classes:
Inputs (what the stack consumes)
- PRs / commits / Jira changes / week
- Standup notes / week (count + signal density)
- Meeting hours captured / week
- Connector reads / week
Outputs (what the stack produces)
state-shared.mdupdates / week- Decisions promoted to
decisions.md - Pattern invocations / week
- Onboarding hours saved / new hire
Process (time + flow)
- Cycle-time (decision → ship) — week median
- Decision-latency (raised → closed)
- Cross-team handoffs / week (lower = better)
- Time-to-context-loaded (sec at session start)
Stack health (don't drift)
- Audit alerts / week (target: 0)
- Routine miss-rate / week
- Pattern adds vs archives / month
- Steward load (hours / week — burnout indicator)
Pick 3–5 across all four classes. Don't try to measure everything. Don't measure things you can't influence. Anti-pattern: tracking 12 metrics, glancing at none. Better: 4 metrics, read every Monday, acted on every month.
Pick the prompt that matches your level. Output is the three artifacts plus a starter operator dashboard spec sized to your level. ~30 minutes.
› Show the Path A prompt // individual baselines · lightweight rhythm
Act as my Operator Stack builder. ## Safety contract (Path A — solo) - Read the existing context-stack/, team-brain/, patterns/, etc. (Modules 01–06). Understand what's there. - Output is THREE labeled markdown blocks: `operator-rhythm.md`, `metrics.md`, `operating-review.md`. Save into team-brain/ (or context-stack/ if no team). - 3–5 metrics, no more. Lightweight rhythm. The stack should fit a solo operator's calendar. - Skip credentials. ## What to build Three artifacts: 1. **`operator-rhythm.md`** — daily 60-sec context load · Monday 5-min reset · end-of-month look-back. With "stack temperature" one-liner. 2. **`metrics.md`** — 3–5 personal metrics with baselines. Cycle-time on personal decisions, decisions-deferred-to-state, time-to-context-loaded, pattern-invocations. 3. **`operating-review.md`** — monthly retro on YOUR stack. What's helping, what's noise, what to cut. ## Steps ### 1. Inventory silently What modules has the user actually shipped? (Look for context-stack/, team-brain/, patterns/, routines/.) What's their work shape? (commits, calendar density.) ### 2. Ask 4–5 short questions 1. Which Modules 01–06 have you actually shipped? (Be honest — partial-ships count.) 2. Top 3 things you do that should get faster (e.g. status updates, decision docs, code reviews)? 3. What does "shipping fast" feel like for you — minutes, hours, days? 4. Do you have a baseline (e.g. "decisions used to take 2 days") or do you need to start measuring from now? 5. Anything you tried in the previous modules that didn't stick? (Helps us drop dead weight from the rhythm.) ### 3. Draft three artifacts Rules: - 3–5 metrics MAX. With baselines (or "TBD: track for 2 weeks first"). - Rhythm fits a solo calendar: 60 sec daily, 5 min Monday, 30 min end-of-month. - Failure-modes section in operating-review.md lists the top 3 ways YOUR rhythm tends to rot. ### 4. Output as markdown blocks (one per file). ### 5. Debrief ``` ## Operator stack drafted (solo) **Output:** three artifacts above. **Metrics chosen:** [list with baselines] **Rhythm:** daily ~60 sec · Monday ~5 min · monthly ~30 min **Stack temperature trigger thresholds:** [yellow / red conditions] **First-month plan:** - Week 1: just track; don't change anything. - Week 2: read the metrics. Notice patterns. - Week 3: tweak one thing. - Week 4: first operating review. **When to upgrade:** if you start working with a team on the stack, move to Path B. ``` ## Templates ### `operator-rhythm.md` ```markdown # Operator Rhythm — solo ## Daily (~60 sec) - Start of day: open AI, ask "where did I leave off?" (Path A wrappers auto-load.) - End of day: 1-line append to state.md. - Stack temperature: glance at routines-inbox / metrics dashboard. Green / yellow / red. ## Monday reset (~5 min) - Update state.md (clear last week, open this week). - Update each project-*.md if status changed. - Read metrics.md top-line. ## End of month (~30 min) - Run operating-review.md. Read metrics. Note what changed. Plan one tweak for next month. ``` ### `metrics.md` ```markdown # Metrics — solo 3–5 measures. Update weekly. Read monthly. ## decision-latency **What:** time from "this is a decision I need to make" to "decided + recorded in decisions.md." **Baseline:** [TBD — track 2 weeks first] **Read:** weekly (Monday). ## state-shared-touch-rate **What:** days/week with a state.md update. **Baseline:** [TBD] **Read:** weekly. ## context-load-time **What:** seconds at session start before AI is "useful." **Baseline:** [TBD] **Read:** ad-hoc (when it feels slow). [... pick 0–2 more from the four classes ...] ``` ### `operating-review.md` ```markdown # Operating Review — solo · monthly ## Read - Last month's metrics. - Routines-inbox: how many drafts, how many noisy, how many missed. - Pattern library: any patterns added / archived? ## Failure modes (early signs) - **Steward burnout (you):** skipping morning approval pass >3 days in a row. - **Pattern bloat:** patterns/ has >15 entries; you can't remember what's there. - **Routine noise:** state-refresh draft is regularly empty or wrong; tighten. - **Audit drift:** connectors growing without justification. ## Decide - One tweak for next month. Just one. Patterns drift when you tweak too much at once. ``` ## Principles - Solo means lightweight. The rhythm should ADD time savings, not subtract them. - Track from baseline. "TBD: 2 weeks of tracking first" is a valid first answer. - One tweak per review. Resist the temptation to overhaul. - The stack works when you forget you're using it. Start with Step 1, then Step 2 (questions).
› Show the Path B prompt // 3-8 person team · steward + tech lead split
Act as my Operator Stack builder. ## Safety contract (Path B — team) - Output is the three artifacts plus a TEAM operating manual: who owns daily rhythm, who owns Friday Sync, who owns monthly review, escalation path. - Metrics roll up across team. 3–5 team metrics + 1–2 individual indicators. - The rhythm fits a team's calendar without becoming another standing meeting. ## What to build Three artifacts plus: 4. **`operating-manual.md`** — roles (steward · tech-lead · owner) and which artifact each owns. Escalation: when does a metric trigger a conversation? ## Steps ### 1. Inventory silently What modules has the team shipped? Steward present? Team size? ### 2. Ask 4–6 short questions 1. Team size and roles (lead, members, function mix). 2. Which Modules 01–06 has the team adopted (not just individuals)? 3. Where does cycle-time get measured today (Jira, GitHub, status emails, gut feel)? 4. Who's steward (Module 02)? Are they about to burn out? 5. Any metrics already in use leadership cares about? (Match those if helpful.) 6. What's the Friday Sync currently? (Start there; don't replace.) ### 3. Draft four artifacts (three + operating-manual) Rules: - Roles named explicitly. Steward owns daily. Tech-lead owns monthly. Both review failure modes. - 3–5 team metrics + 1–2 individual indicators. Roll up to leadership-friendly summary. - Operating-manual references existing meetings; doesn't invent new ones. ### 4. Output as markdown blocks (one per file). ### 5. Debrief ``` ## Operator stack drafted (team) **Output:** three artifacts + operating-manual. **Roles:** steward = [name], tech-lead = [name], capability owner = [name]. **Team metrics:** [list] **Individual indicators:** [list] **Friday Sync (existing) absorbs:** state-shared promotion + metrics read. **First-month plan:** - Week 1: announce. Track. Don't act yet. - Week 2: read metrics in Friday Sync. - Week 3: agree on one tweak. Try it. - Week 4: first operating review (whoever owns it leads). ``` ## Templates ### `operator-rhythm.md` (team) ```markdown # Operator Rhythm — team ## Daily (~3 min, steward) - Steward checks routines-inbox. Approves / promotes / dismisses. - Stack-temperature one-liner posted in steward's morning Slack. ## Friday Sync (~15 min, full team) - Steward leads. State-shared promotion. Decisions.md append. - Tech-lead reads top-3 metrics. Calls out anomalies. ## Monthly Operating Review (~30 min, lead + steward) - Read metrics trend (4 weeks). Read failure-modes catalog. - Decide: one tweak. One thing to add or cut. - Update operating-manual if roles shift. ## Quarterly external review (~30 min) - Person OUTSIDE the team reads connectors / patterns / metrics. - Calls out drift the team can't see. ``` ### `metrics.md` (team) ```markdown # Team Metrics ## team-cycle-time (median) **What:** decision raised in standup → shipped (or explicitly deferred). **Source:** Jira (or your equivalent) ticket lifecycle. **Baseline:** [TBD] ## handoffs-avoided / week **What:** count of cross-team conversations that didn't need to start from zero (the team-brain answered them). **Source:** Steward's gut count + retro mentions. **Baseline:** [TBD] ## new-hire-time-to-useful **What:** days from "joined" to "shipping tickets without asking for context." **Source:** Steward + new hire's tech-lead. **Baseline:** [TBD] ## pattern-reuse-rate **What:** patterns/ invocations / week. **Source:** Module 03 routine that counts pattern files referenced. **Baseline:** [TBD] [... 0–1 more …] ``` ### `operating-manual.md` ```markdown # Operating Manual ## Roles - **Steward** — owns daily rhythm + Friday Sync state-shared promotion. Burns out fast; rotate quarterly. - **Tech lead** — owns metrics read + monthly review. - **Capability owner** (when org-formal) — owns budget for tools + connectors. ## Escalation - Metric outside ±20% of baseline 2 weeks running → bring to Friday Sync. - Audit alert → DM steward immediately. - Steward "I'm overloaded" → rotate within 1 week. ## Failure modes (team) - **Steward burnout** — steward owns too much. Rotate or split. - **Connector creep** — quarterly external review catches. - **Routine noise** — Friday Sync reviews monthly. - **Pattern bloat** — Module 06 audit cadence. - **Drift from leadership view** — tech-lead reports a 1-pager metric monthly. ``` ### `operating-review.md` (team) (Same structure as Path A but reads team metrics, references operating-manual roles.) ## Principles - Roles named explicitly. Steward burnout is the #1 failure mode. - Friday Sync is the seam. Don't add a new meeting for the rhythm; absorb into existing. - Metrics roll up. Leadership sees a 1-pager; team sees the detail. - One tweak per month. Resist redesign. Start with Step 1, then Step 2 (questions).
› Show the Path C prompt // multi-team adoption · governance · capability ownership
Act as my Org Operator Stack builder. ## Safety contract (Path C — org) - Output is the three artifacts plus an org-level governance doc: capability ownership, cross-team pattern + connector + audit policy, formal incident response. - Metrics roll up to a leadership-view dashboard. Team-level detail still exists; org view is the 1-pager. - The stack stops being a habit and becomes a capability with budget, owners, and a roadmap. ## What to build Three artifacts plus: 4. **`org-governance.md`** — capability owner, cross-team policies (patterns, connectors, audit), formal incident response, leadership review cadence. ## Steps ### 1. Inventory silently How many teams adopting? Existing governance shape (does the org already have something like this for security, OKRs)? Leadership stakeholders. ### 2. Ask 4–6 short questions 1. How many teams will adopt? Pilot or all-at-once? 2. Existing governance the stack should fit into (security review, change-management, OKR program)? 3. Capability owner — who has budget AND time to maintain this across teams? 4. Leadership review cadence the stack should report into (monthly tech review, quarterly business review)? 5. Cross-team pattern sharing — central library or federation? 6. Audit + incident response — does the org have formal IR? Which security team owns? ### 3. Draft four artifacts Rules: - Capability owner named. Without a single throat to choke, this rots. - Patterns + connectors + audit get cross-team policies. Federation default; central registry option. - Failure modes catalog includes org-level patterns: budget cut, capability owner change, leadership turnover that dropped the rhythm. ### 4. Output as markdown blocks (one per file). ### 5. Debrief ``` ## Operator stack drafted (org) **Output:** three artifacts + org-governance doc. **Capability owner:** [name + role]. **Adoption plan:** [pilot teams + rollout sequence]. **Leadership view:** 1-pager dashboard refreshed monthly via Module 03 routine. **Org failure modes flagged:** [budget · ownership · governance · leadership turnover]. **First-quarter plan:** - Month 1: pilot 1-2 teams. Track baseline. - Month 2: expand to 3-5 teams. First leadership readout. - Month 3: capability-owner assessment + roadmap. ``` ## Templates ### `org-governance.md` ```markdown # Org Governance — AI-Native Operator Capability ## Capability owner - [Name + role]. Owns budget, roadmap, escalation. Reports into [exec sponsor]. ## Adoption sequence - Pilot teams: [list]. - Wave 2: [list]. - Wave 3 (org-wide): [target date]. ## Cross-team policies - **Patterns:** federation. Each team owns its patterns/. Central registry of patterns ≥3-team-use only. Quarterly cross-pollination. - **Connectors:** central audit policy. Each team's scope rules approved by capability owner. - **Routines:** team-owned. Capability owner reviews monthly cost roll-up. - **Audit + incident response:** [security team] owns. Standard org IR runbook applies. ## Leadership view (monthly 1-pager) - Adoption %: teams running the stack. - Aggregate cycle-time delta vs baseline. - Aggregate handoffs-avoided count. - Onboarding time-to-useful: weighted average. - Budget consumed: connector + routine costs. - Risks: failure-mode incidents. ## Failure modes (org) - **Capability owner change** — rotate slowly; document handoff. - **Budget cut** — capability owner defends with leadership-view metrics. - **Governance creep** — too many approvals slow the stack; review quarterly. - **Leadership turnover** — capability owner re-pitches new leadership in 30 days. - **Multi-team divergence** — patterns + connectors + audit drift; quarterly cross-team check. ``` ### Other templates same as Path B, scaled to org. ## Principles - Single throat. Without a capability owner, this rots. - Federation default. Each team owns its details; org owns policies + the 1-pager. - Leadership view is the 1-pager. If they need detail, they can drill in. - Operator capability is now part of the org. Budget. Roadmap. Owner. Start with Step 1, then Step 2 (questions).
For teams running the operator stack on M365, the dashboard lives in Copilot Pages (with optional Loop components for cross-team rollups). Metrics auto-refresh from SharePoint; the steward's Monday reset is one Copilot prompt away.
// microsoft 365 copilot · pages + loop
Operator dashboard as a Copilot Page that pulls from your SharePoint team-brain.
Build one Copilot Page per scope (solo / team / org). Embed Loop components that read your metrics.md + operator-rhythm.md from SharePoint. Pin the page in Teams; steward opens it Monday morning and runs the saved monday-reset prompt — Copilot reads the week, drafts the temperature one-liner, refreshes the dashboard.
Build the dashboard page
In M365 Copilot Chat, ask: "Create a Page summarising the metrics in /sites/team-brain/metrics.md and the rhythm in operator-rhythm.md." Copilot drafts the page; you tighten the layout. Save to the team's SharePoint site.
Pin in Teams + Outlook
Add the Page as a tab in the team's Teams channel. The whole team gets the same operator view. Optional: pin a Loop component (this week's temperature) into Outlook for the steward's morning email.
Monday reset prompt
Save the monday-reset prompt to the Prompt Gallery: "Read the SharePoint team-brain. Update the dashboard's temperature one-liner. Flag any metric in the red zone. Output the 5-min Monday reset checklist." One click each Monday.
Why this matters: M365-resident teams don't need a new dashboard tool — the operator practice ships into the surface they already check. Loop components make cross-team rollup (org-level Path C) tractable: each team's Page contributes a Loop block; leadership sees the rollup in one place. Trade: requires Loop to be enabled in the tenant (admin opt-in).
If your team-brain lives in git, your operator dashboard belongs there too. GitHub Copilot generates the metrics view, and a scheduled GitHub Action keeps it current. Everything reviewable; nothing in a SaaS silo.
// github copilot · markdown dashboard + actions
Dashboard is a single OPERATOR.md at the repo root, refreshed by a Monday Action.
Treat the operator dashboard as version-controlled markdown. A scheduled workflow runs the Copilot CLI against the repo each Monday morning, refreshes OPERATOR.md from metrics.md + git history + the routines log, and opens a PR. Steward merges before the standup.
Generate the OPERATOR.md template
In Copilot Chat: /operator-dashboard (a saved .github/prompts/operator-dashboard.prompt.md from Module 06). Copilot reads metrics.md, operator-rhythm.md, and the last 7 days of git log; writes OPERATOR.md with this week's snapshot.
Monday refresh workflow
Drop a .github/workflows/operator-monday.yml:
on:
schedule:
- cron: '0 13 * * MON'
jobs:
refresh:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: gh copilot suggest \
-t shell \
"refresh OPERATOR.md"
PR-based approval
Workflow ends by opening a PR titled operator: weekly refresh <date>. Steward reviews the diff (which metrics moved, what's in the red zone), edits if needed, merges. Merge = published dashboard. The git history IS the operator-review trail.
Why this matters: the dashboard, the rhythm, and the audit trail are all the same artifact — the repo. Org-level (Path C) rollup: each team's OPERATOR.md gets aggregated by a meta-repo workflow into a leadership view. Zero new tools; the practice rides on infrastructure your team already pays attention to.
A capstone is only useful if it stays current. Two habits keep the operator practice alive:
Operating review
Run operating-review.md. Read the month's metrics. Skim the failure-modes catalog. Decide on one tweak for the next month. Update artifacts.
External review
Person outside the team / org reads everything — operator-rhythm, metrics, operating-review, plus the underlying Module 02-06 artifacts. They flag drift the operator can't see. Patch.