Meeting Briefing Research

skill

Research attendees and companies and merge with relationship memory into a one-page meeting dossier.

Download .md

Meeting Briefing Research

Research meeting attendees and their companies, merge findings with existing relationship notes, and produce a one-page dossier before the meeting starts.

When to use

  • A meeting with an external contact, prospect, or partner is coming up and no dossier exists yet.
  • You need a quick refresher on someone you have met before, updated with what has changed since.
  • A human is prepping for a call and asks for background on attendees or their company.
  • Recurring meetings (e.g. weekly account check-ins) need a refreshed briefing each time.

Tools

  • browser-search — find recent news, company updates, and public profiles for attendees.
  • browser-navigate — open specific pages (company site, news article, LinkedIn-style profile, press release) found via search.
  • browser-extract — pull structured facts (role, company, recent announcements, shared connections) off the opened page.
  • update-memory — save durable relationship facts (role changes, past meeting outcomes, preferences) for reuse in future briefings.
  • write-file — save the finished one-page dossier as a file for the human to read before the meeting.

Playbook

  1. Confirm the attendee list, meeting purpose, and company names from the request. If any are missing or ambiguous, stop and message a human via send-message to clarify before researching.
  2. Check durable notes first: read whatever relationship memory is available for each attendee and company (prior meetings, deal stage, known preferences) before doing new research.
  3. For each attendee, run browser-search for their name plus current company (e.g. "Jane Doe VP Sales Acme Corp") to find their current role and recent public activity.
  4. Use browser-navigate to open the most relevant results — company "About"/"Team" pages, recent press releases, or news coverage — and browser-extract to pull the key facts (title, tenure, recent quotes, notable projects).
  5. Run a second browser-search pass on the company itself (e.g. "Acme Corp funding OR product launch 2026") to surface recent news relevant to the conversation: funding rounds, leadership changes, product launches, or public challenges.
  6. Cross-reference new findings against the existing relationship memory: flag anything that contradicts or updates prior notes (title changes, new priorities, prior commitments made).
  7. Draft the one-page dossier: attendee summaries (role, background, talking points), company snapshot (size, recent news, relevant context), and 2-3 suggested discussion angles tied to the meeting purpose.
  8. Save the dossier with write-file to a clearly named file (e.g. meeting-briefing-<company>-<date>.md) so the human can review it before the meeting.
  9. Call update-memory with any new durable facts learned (role changes, company events, useful talking points) so future briefings on these people or companies start from a stronger baseline.

Failure modes

  • Search returns stale or ambiguous results (common name, multiple companies) — verify identity against the meeting invite details before writing anything into the dossier; if unresolved, note the ambiguity explicitly rather than guessing.
  • No public information exists for a private individual or small company — say so plainly in the dossier instead of fabricating background.
  • Relationship memory conflicts with newly found facts — surface the conflict in the dossier rather than silently overwriting; let the human decide which is current.
  • Any next step implies booking travel, sending payment, or committing budget — this is always human-executed; propose it as a recommendation only and route via send-message, never act on it.

Done when

  • A one-page dossier covering all attendees and their companies has been saved via write-file and shared with the human ahead of the meeting.
  • New durable facts uncovered during research have been captured via update-memory for future reuse.
  • Any ambiguity, missing information, or out-of-scope action (travel, payment) has been explicitly flagged rather than guessed at.