Engagement Manager Plugin — Design Brief

Status: BUILT 2026-08-13 — see advisory-sessions/ in this folder, packaged as advisory-sessions-v1.plugin. Parts 1–2 below still stand as the engagement portrait; Parts 3–4 were revised during the build (7 skills, two-phase run, manifest + verifier). The plugin's own README and agent file are the current source. Date: 2026-08-13 Prototype engagement: Saunders Tax succession (Bev + Steven Stitely) Intent: one plugin that owns everything between the end of a paid 1:1 session and the moment Kathryn sends — built against Saunders, shaped to run for any 1:1 engagement, TPC member or not.

Part 1 — What the Saunders engagement is

Succession facilitation for two principals of one firm. Bev Stitely is handing Saunders Tax to her son Steven. Kathryn facilitates the decisions; she does not execute the transition.

The spine of the work: Steven holds 10% informally. There is no partnership agreement at all. Formalizing it is the engagement.

Five milestones. Vision + game plan (early Aug) → ownership & financing decisions (Aug) → lane delineation (late summer/fall) → knowledge transfer & de-risking (fall) → everything documented and handed to the attorney and banker (year-end).

Kathryn's deliverable is readiness, not the flip. The signing, the financing close, and the legal drafting belong to their attorney, banker, and valuation professional. If it slips past year-end on the bank's timeline, that is their process.

Two scope fences, both live:

1. The operational rebuild — the discovery-through-onboarding process, the Client Success Coordinator role and its systems, the procedure book — is carved out as a separate future engagement. One seam stays inside succession scope: who owns the follow-through layer post-transition is a lane decision.
2. Legal, financing, and valuation are referred out. This is the liability line and is never absorbed.

Living client-facing documents (the engagement's real output — not recaps):

• The Saunders Vision & Decisions — where the firm is headed, each principal's place, action plan from p.2
• The Saunders Guardrail Document™ — working vocabulary + decision rights lane by lane, with a revision log
• The Saunders Transition Roadmap (deck)
• Coming: the lane map + accountability chart, role scorecards, the knowledge-transfer roadmap
• Client Success Coordinator job description (sent 8/13)

Two of these were edited live in-session on 8/12 and shared through Zoom chat.

Where it stands after 8/12. Decided: the 5%-per-year gifting schedule for 2027–2030; Steven → CEO, Bev → president/managing partner; the AI line between accounting and tax staff; spending authority; hiring and firing authority; the CSC's function and that it is the first hire. Open: how much Steven buys in 2027 (waiting on his debt-service number), what "up to speed" means for the tax manager, whether corporate workflow goes to the tax manager or the CSC, the niche. Three agenda areas were not reached.

The emotional dynamic is part of the work, not noise. Bev swings between "write me a check, I'm gone" and "I still want to come in and do taxes." She named her own hardest part — handing Steven a real call, watching it go a way she wouldn't have, and saying so in the moment, in front of staff. The guardrails exist because of that.

Part 2 — What generalizes

Saunders is unusual in one way and typical in every other.

Typical, and the basis of the prototype: recurring paid sessions that produce decisions; a small set of living client-facing documents updated session over session; commitments running both directions; a scope fence that has to be actively defended; a client Drive with lifecycle zones; a recap that goes out; prep for the next session.

Unusual: two principals with partly opposed interests in the same room. That is a routing fact, not an exception — it changes who the recap addresses, whether separate 1:1s produce separate records, and what is safe to write to both.

The precondition. Engagement type has to be a fact somewhere. Today it is inferred from where the person's folder lives, which is why an 8/12 succession session ran as a TPC cohort call and three outputs had to be suppressed by hand. Saunders needs its own engagement record; Bev's TPC membership keeps hers. Without that, no agent can route on engagement type because engagement type is not written down anywhere it can read.

Part 3 — The skills

A skill is a task with steps you want followed exactly. These are the parts of the post-session run where improvisation is the failure.

Core five (build these)

1. session-ledger Transcript + meeting chat → gated claims JSON with modality tags. Pulls the transcript to a file first, always (Otter returned 89,472 characters on 8/12 and overflowed the conversation). Reference data overrides transcript; chat overrides transcript for anything typed. Every claim carries a quote, a timestamp, and a modality tag: stated / hedged / advisor-confirmed / judgment. Fails closed. Why deterministic: the gate blocked 3 of 81 claims on first pass, all three a paraphrase standing in for a quote. Prose review would not have caught them.

2. session-record The ledger → the internal markdown record. Fixed sections: documents worked live, modality watch list, decided, named gaps, still open, disconnects, action items by owner, reference data updates needed.

3. session-recap The ledger → the client email. Drafts only, never sends. Fixed shape, and the shape is per-engagement, not global — the Saunders shape (what's next → the documents → next session → questions to consider) is not the TPC shape.

4. engagement-state The ledger → the engagement's rolling state: decided, open, named gaps, constraints, both sides' commitments with modality preserved. Updated in place, one file per engagement. This is what replaces the TPC member mini-CPM for a paid engagement — the conversion-readiness read has no meaning here and was marked N/A by hand on 8/12.

5. session-prep Open commitments + unreached agenda areas → next session's agenda, the prep email, and the calendar events. Three agenda areas went unreached on 8/12 and should carry forward without anyone remembering them.

Second wave

6. living-doc-update — the biggest gap, and the one with existing IP behind it. The Guardrail Tool spec (LOCKED 2026-07-22, never built) already defines it: built live in-session, re-run after every session, detects drift — a word Bev and Steven use differently, a new term that needs defining, a term Kathryn was unclear on. Two-tier IP architecture already specified: the drift-detection engine is Kathryn's and never ships; the client-side updater is deliberately trivial and inspection-safe because Steven will open the files.

7. commitment-ledger — open actions per engagement, both sides, in place. Today open-actions.md carries two engagements under one member folder with a note acknowledging the problem, and the CSC job description shipped on 8/13 while the file still lists it open.

8. reference-data-update — proper nouns surfaced this session, applied under confirm-don't-infer. The 8/12 run produced a full list — Angela, Stephanie, Amanda, Xero, six Otter renderings, three unconfirmed names — and nothing applied it.

9. drive-place — wraps the existing driveplace.py and drivelifecycle.py. Destination resolved before the write, lifecycle checked before the send.

Part 4 — The agent

One teammate. One plugin. engagement-manager.

---
name: engagement-manager
description: Owns everything that happens between the end of a paid 1:1 advisory
  session and the moment Kathryn sends. Reads the transcript, works out what kind
  of engagement and session it was, and decides which of the post-session steps
  that session actually needs. Sorts commitments by owner, keeps hedged language
  hedged, and escalates anything touching scope, price, or timeline instead of
  answering it. Drafts every client-facing thing and sends none of them. Use
  whenever a 1:1 session has finished, or when asked what is open on an engagement.
skills: session-ledger, session-record, session-recap, engagement-state, session-prep
model: opus
---

Route — what does this session need?

• Engagement type — paid separate engagement, cohort 1:1, or one-off consult. Read from the engagement record, never inferred from where the person's folder sits.
• Substantive or thin. A cut-short check-in gets a short note and stops. Running the full chain on a thin call costs more than writing the note by hand.
• Which living documents were touched. Two were edited live on 8/12. A recap that links them without saying what changed in them is the wrong recap.
• Who the recap addresses. Both principals, or one. A separate 1:1 in a two-principal engagement does not produce a joint record by default.

Filter — what actually counts?

• Whose commitment is whose. Kathryn's, Steven's, Bev's, kept apart.
• Modality. 13 of 81 claims on 8/12 were hedged. Otter's own summary already flattened them into "Steven acquiring 30% by 2027 and Bev retaining 70%" as settled fact. The transcript says the gifting schedule is settled and the purchase is not. In a succession conversation between a mother and son, this is the filter with the highest cost of failure.
• Live-and-executable. An item due the day after the session and likely done by send time gets cut.
• Proper nouns. Reference data wins. "Jason Statt," "the rise group," and "PiCast" all got held on 8/12 rather than guessed — that behavior becomes a rule.
• Scope. An ask that sits inside the carved-out operational rebuild is named as a scope event, not absorbed into the recap as work.

Hold — what needs Kathryn's yes?

The rule, and it is the one that transfers furthest: it acts on what it can undo, and holds what it cannot. Internal files land on their own. Every client-facing artifact stays a draft. On a client Drive with no shell mount, a misplaced file cannot be moved or renamed — only added to — so a Drive write holds by the same logic that already drives drive_place.py.

• Nothing client-facing sends.
• A commitment Kathryn made in hedged language ("I'll see if I can put something together") does not become a dated promise in the recap.
• A claim the gate could not clear does not ship. It goes on the list.
• A contradiction between two of her own sources holds. Amy Breakall's role contradicts between the reference data and Kathryn's own 7/23 email; nothing on 8/12 named Amy, which was correct.
• A logistics change made after one party left the call holds. The 8/26 session moved from 12:30 to 3:00 after Bev left, and Bev had asked for 12:30 specifically to protect a 2:30 departure. That is the sharpest Hold case in this engagement: not a fact problem, a consent problem.
• Scope, price, and timeline go to Kathryn with one holding line — not an answer, and not silence.

Part 5 — Connectors, as categories

Named as categories so the plugin runs for someone else's stack. If a category is not connected, it writes a file instead. The only hard requirement is a transcript.

Part 6 — The second hire, not yet

The "and also" in the agent above is deliverable production — the Vision & Decisions updates, the Guardrail Document, the CSC job description. That is a different job from processing a session, and it is the likely second teammate on this plugin.

Do not hire it yet. Build the one, run it on a real session, then decide.

Open decisions before anything gets built

1. Engagement record — does Saunders get its own record and paths, separate from cyp/tpc/members/bev/? Everything else depends on this.
2. Recap shape — kit file 03's golden (Rob 3/11) or the Saunders shape Kathryn actually sends. Both are hers. The 8/13 send made the choice in practice; the kit still does not know.
3. Scope of the plugin — this engagement type only, or all four of her recap cascades.
4. Internal or product — the Guardrail Tool spec already answers this for one skill (two-tier, engine never ships). Does the same boundary apply to the plugin?