# Onboarding Call Agenda Contract This is a prepared decision session, not a blank questionnaire. Prefill the best public-safe thesis from credible evidence, then ask the client to confirm, correct, or decide. Use the complete agenda every time; 30–60 minutes controls depth only. Prepare research is bounded and read-only in this order: exact Calendar/Gmail meeting identity; relevant Grain calls; exact Lightfield CRM records; exact Sellable workspace/sender state; first-party web research through web search or isolated `agent-browser`; then bounded external research for a material gap. Calendar/Gmail identity wins over stale CRM identity. Legacy Slack-backed records are not CRM for this workflow. Each source records an available or explicit unavailable receipt, and each evidence item is classified exactly as `fact`, `inference`, or `open_question`. ## Exact tool input Pass one complete `agenda` object. Never pass `{}`, a partial shape, or private evidence as a public value. ```json { "clientName": "public client name", "engagementId": "exact engagement binding", "workspaceId": "exact workspace binding", "pageRevision": "deterministic visible revision for this prepared or confirmed record", "meetingDate": "public meeting date or explicit pending date", "attendees": ["public attendee names or roles"], "lifecycle": "prepared | confirmed", "readiness": "draft | confirmed | handoff_ready | blocked", "campaignName": "Campaign 1 public name", "campaignObjective": "bounded objective", "sender": "public sender name", "senderPublicUrl": "public sender URL", "product": "public-safe product thesis", "value": "public-safe value thesis", "pain": "public-safe pain thesis", "outcome": "public-safe outcome thesis", "proof": "safe proof or explicit pending proof", "prohibitedClaims": "claims the campaign must not make", "targetCompanies": "company fit", "buyerRoles": "buyer roles", "antiBuyers": "anti-buyers", "exclusions": "exclusions", "geography": "geography decision or explicit pending decision", "dncDependency": "DNC and setup dependency", "audienceOptions": [ { "label": "researched audience label", "companies": "company demographics", "roles": "buyer roles", "geography": "geographic boundary", "notAFit": "who is outside this option", "whyPlausible": "evidence-backed reason to discuss this option" }, { "label": "second distinct researched audience", "companies": "company demographics", "roles": "buyer roles", "geography": "geographic boundary", "notAFit": "who is outside this option", "whyPlausible": "evidence-backed reason to discuss this option" } ], "dreamClients": [ {"company": "dream client 1 company", "buyerRole": "buyer role at dream client 1"}, {"company": "dream client 2 company", "buyerRole": "buyer role at dream client 2"}, {"company": "dream client 3 company", "buyerRole": "buyer role at dream client 3"} ], "linkedInTopics": "relevant topics", "linkedInConversations": "relevant conversations", "linkedInCreators": "relevant creators", "linkedInPosts": "relevant post patterns", "participantBehavior": "relevant participant behavior", "offer": "offer direction", "cta": "CTA direction", "messageDirection": "message direction", "voiceConstraints": "voice constraints", "senderCredibility": "sender credibility", "known": ["public-safe facts and explicit decisions"], "blockers": [ {"description": "real blocker without terminal punctuation", "owner": "client | Aida", "dueCondition": "clear condition without terminal punctuation"} ], "targetDates": { "approvalReady": "actual date or pending date condition", "conditionalLaunch": "date or pending-date target only; no setup or approval completion suffix" }, "decisions": ["confirmed or explicitly pending decisions"] } ``` `dreamClients` contains exactly three company-and-buyer-role pairs. During `prepare`, use explicit `Confirm on call` placeholders when the client has not named them yet. During `finalize`, replace all six placeholder values with the three confirmed companies and the buyer role at each. Legacy dream-account and lookalike fields are not part of this contract. Prepared input uses `lifecycle: prepared` and readiness `draft` or `blocked`. Final input uses `lifecycle: confirmed`; use `handoff_ready` only when no launch blocker remains, otherwise use `blocked`. The same visible revision must be used by the page and returned handoff for one strategy. ### Renderer-composed input fragments The renderer owns punctuation and the fixed launch-gate completion suffix. Supply these values as fragments so the public page is correct on the first lifecycle call: - `blockers[].description` and `blockers[].dueCondition` have no terminal period, question mark, exclamation mark, or semicolon. The renderer adds the sentence punctuation around the owner and blocker labels. - `targetDates.conditionalLaunch` is only the date or pending-date target, such as `Week of July 27, 2026` or `Confirm the next practical date on the call`. Do not append or paraphrase `when setup, representative sample review, and approvals are complete`; the renderer adds that condition once. - Read the composed preview, not only the raw JSON. Any doubled punctuation, duplicated completion clause, or wording that says gates remain open when completion happens must be corrected before the first mutation. When the operator has not been given an explicit accepted revision, derive it from the exact engagement binding: - prepared: `{engagementId}-prepared-v1` - confirmed: `{engagementId}-confirmed-v1` Never use a timestamp, random suffix, session ID, or retry count. An unchanged rerun reuses the exact complete agenda and revision. A materially revised agenda increments only the matching numeric suffix (`v2`, `v3`, and so on), and the operator records which decision changed. Prepare and finalize have separate revision lines; finalization does not rename or mutate prepared history. ## Meeting-ready public page structure Use the former detailed kickoff agenda as the meeting-facing base. The page is for running a 30–60 minute conversation, so it must present researched theses, clear decision options, and confirmation prompts rather than expose the input schema one field per paragraph. 1. **Meeting frame** — date, attendees, objective, and a compact agenda overview. 2. **What we know / what we still need** — public-safe researched facts first; honest gaps with an owner and the exact decision needed second. 3. **Part 1: Strategy** - Product: what it does, how it works, differentiator, target buyer, alternatives, positioning guardrails, and what to confirm on the call. - ICP and targeting: two or three distinct researched audience options. For each, show company demographics, buyer roles, geography, who is not a fit, and why it is plausible. End with exactly three live prompts where the client names a dream company and the buyer role at that company. - Offer and message: pain, outcome, safe proof, proof boundaries, sender credibility, CTA, voice, and two or three angle hypotheses. - Campaign plan: the first hypotheses to test and the decision criteria; final copy and sourcing wait for later representative-lead review. 4. **Part 2: Alignment** - Partnership and ownership: how Sellable and the client make decisions. - Setup readiness: sender state, exclusions, response routing, and any real blocker. - Reply management: who owns review and what happens when interest appears. - Timeline and open items: approval-ready plan, conditional launch target, owners, and the next sync. 5. **Decisions and next action** — confirmed or pending decisions, unresolved blockers, owners, readiness, and exactly what Aida will return for approval. 6. **Machine handoff boundary** — the exact machine-readable handoff is returned by the lifecycle tool for downstream validation. It is never rendered on the public meeting page, and no redundant prepared-history footer is shown. Signal Discovery remains the only first sourcing/relevance method. Describe it in plain English through relevant LinkedIn topics, creators, posts, conversations, and participant behavior. The three dream-client prompts are discussion aids for clarifying fit, not provider seeds or automatic sourcing instructions. ## Required public scaffolding - Deterministic title: `Sellable x {Company} — Kickoff & Campaign 1 Decisions`. - Lifecycle: `Prepared for kickoff` then `Confirmed after kickoff / Handoff ready`. - `What we know / What is still needed` with explicit owners and blockers. - Native Notion headings, bullets, checklists, dividers, and collapsed details; never literal Markdown/HTML or visible managed-region sentinels. - No duplicated H1 inside the page body; the Notion page title owns the H1. - Research-backed prose and decision options dominate the page; the machine handoff exists only in the lifecycle result. - No public `Campaign 1 Handoff`, prepared-history footer, or lookalike section. - Approval-ready campaign plan target within 48 hours after kickoff. - Conditional launch target within 5–7 business days after payment only when setup, the 25–50 representative lead sample, and approvals are complete. - On finalize, replace the managed meeting body with the confirmed record; do not append a redundant prepared-history footer. ## Activation and responsibilities Activation means the representative sample, campaign direction, sender/setup, exclusions, approvals, and accountable owner are launch-ready. Kickoff completion is not activation and does not authorize first sends. Aida is the single Customer Success Engineer and launch operator. Aida later builds Campaign 1 through its separate approved workflow, sources the 25–50 representative lead sample, and creates the separate approval packet. The client waits for that packet unless one confirmed client-controlled blocker is assigned explicitly. The client is never asked to source accounts, draft messages, or operate campaign setup as generic homework. ## Public safety and source boundary Never render deal terms, pricing, transcript excerpts, private emails, internal notes, provenance, confidence labels, source/internal IDs, private DNC entries, facilitator instructions, or unsupported claims as facts. Sales Navigator is allowed only as a setup/readiness fact. Do not recommend hiring, funding, timing, technology, generic intent, Prospeo, Apollo, database-provider signals, or dream-client seed sourcing in this method. ### Lexical fail-closed scan The renderer rejects these case-insensitive character sequences in every public agenda string, audience option, blocker description, and blocker due condition: - `deal term` or `deal terms` - `funding signal` - `hiring signal` - `timing signal` - `technology signal` - `generic intent` - `sales navigator activity` - `provider seed` - `transcript excerpt` - `slack canvas` - `private dnc` - `source id` - `internal id` - `facilitator instruction` This is lexical, not semantic: a sentence that says not to use one of those phrases still fails. Never put the literal sequence into `prohibitedClaims`, `exclusions`, `dncDependency`, or any other public field. State the safe boundary using different public language, such as `commercial details remain private`, `apply approved exclusion data before activation`, or `broad behavioral indicators are out of scope`. Before the lifecycle call, scan the entire complete agenda and rewrite every match without weakening the boundary. The method cannot send Slack/Gmail, search/import leads, create the sample or approval packet, mutate a campaign, or launch outreach.