How it works

From sign-in to sponsor report, in four stages.

Four steps take a delegate from a name on a list to a meeting you can prove happened. Here is each one — and how far along it is today.

Step 1 · OnboardShipped

Sign in, and you're match-ready in under a minute.

A delegate signs in with LinkedIn and public enrichment pre-fills most of the profile. Three to five questions that actually move a match — what they're seeking, what they offer — finish it. No long form, no blank profile to stare at.

  • LinkedIn sign-in plus public enrichment
  • 3–5 questions that change a match, nothing that doesn't
  • A confirmed, match-ready profile in under a minute

An agent onboards a delegate from one identity handle — enrichment fills the match inputs, so there is no form to script.

Step 2 · MatchLive

The five people in the room worth meeting.

The engine projects the whole room over stated intent and reciprocal fit, then ranks the counterparts who move each delegate's goal forward — with one plain-language reason on every match, not a directory to sift.

  • Ranked by seeking ↔ offering complement
  • One-line reason a delegate believes
  • Every match is tracked, with the reason on the record

Ranking is deterministic and pure — same inputs, same order — so an agent can cache, diff, and explain a match without a second model call.

Event match feed: a current delegate and their ranked counterparts, each with a seeking/offering reason and a request-intro action.
Matches · ranked counterparts with reasons
Step 3 · IntroduceShipped

From “worth meeting” to “we met.”

A match only matters if the meeting happens. Consented, double-opt-in introductions are tracked from requested to met — nobody gets spammed, and every accepted intro becomes part of the record.

  • Double-opt-in — both sides say yes
  • Tracked from requested to we met
  • Identity-bound: only the named counterpart can accept
Event introductions surface tracking outgoing and incoming introductions through their consented lifecycle.
Introductions · consented, tracked to met
Step 4 · ProveIn progress

Show a sponsor the meetings you delivered.

Relationship movement, introductions requested, introductions that converted — the record turns a two-day event into something you can put in front of a board or a sponsor. Meetings that happened, not booth scans.

  • Introductions requested vs. converted
  • Movement against the accounts a sponsor cares about
  • A record that outlives the event

Every outcome is machine-checkable, so an evaluating agent can verify what happened instead of trusting a dashboard.

Event analytics showing relationship movement and meeting outcomes for sponsor ROI.
Analytics · outcomes you can show a sponsor
Under the hood

The engines and components every stage above runs on.

For technical evaluators and agents: the reusable engines, shared interface kit, and platform behind the journey — each standalone, each usable by any app, with an honest status on what's running in production versus rolling out next.

  • 4reusable engines
  • 7interface components
  • 7product modules
  • 1live deployment

Reusable engines

Standalone engines Event composes — each usable by any other app.

4
  • Built & testedengine

    Matching engine

    Ranks each delegate's counterparts by complementarity and mutual fit — who needs what someone else offers.

    Deterministic, pure ranking — same inputs return the same result, with an rcp_ receipt per match.

  • Built & testedengine

    Enrichment engine

    Turns a sparse identity into a match-ready profile from public web and company data.

    Pre-fills the match inputs so an agent onboards a delegate with one identity handle, not a form.

  • Built & testedengine

    Agent-surface generator

    Auto-generates the API, CLI, and MCP surface for an engine from one definition.

    This is why every app is agent-native by construction: the MCP/OpenAPI/CLI are generated, not hand-written.

  • Built & testedplatform

    Integrations platform

    Four connectors (email, Eventbrite, LinkedIn, Stripe) with OAuth2, webhooks, vaulted secrets, and SSRF guards.

    Outbound integrations run through a guarded boundary (vault + SSRF protection), so agent-initiated actions stay inside policy.

Shared interface components

The shared interface kit every app wears — the same shell, themed per vertical.

7
  • Built & testedcomponent

    Rail

    The icon rail and primary navigation that gives every app one identity.

  • Built & testedcomponent

    Voice

    Voice-input affordance with a recording pulse and reduced-motion fallback.

  • Built & testedcomponent

    Search

    Command-palette search over sections and entities (⌘K).

  • Built & testedcomponent

    Chat

    Streaming concierge chat surface with typed message lifecycle.

  • Built & testedcomponent

    Table

    Dense, accessible data table for delegates, matches, and introductions.

    A notes panel built from the Starlight component system
    Real capture · Starlight panel/table component capture
  • Built & testedcomponent

    Form

    Form primitives with labels-above-inputs and full error/disabled/loading states.

  • Built & testedcomponent

    ChecklistRow

    Onboarding checklist row used to drive the profile-completeness flow.

    An onboarding checklist built from the Starlight component system
    Real capture · Starlight onboarding-checklist component capture

Starlight design language

The token system and component catalog the shared shell is built on. Still being formalised.

2
  • In progressdesign-system

    Primitives & tokens

    The buttons, inputs, badges, and color/space tokens that compose every Event surface.

    A catalog of Starlight UI primitives
    Real capture · Starlight primitives capture
  • In progressdesign-system

    Data & usage components

    Higher-order components — usage meters, panels — for analytics and account surfaces.

    A credit-usage meter built from the Starlight component system
    Real capture · Starlight credit-usage component capture (design reference, not a live Event screen)

Event product modules

The modules that make up the product. Shipped; app screens not yet captured.

7
  • Shippedmodule

    Onboarding

    LinkedIn sign-in → enrichment → a confirmed, match-ready profile.

  • Shippedmodule

    Matches

    The match feed a delegate sees — the ranked five, each with a plain-language reason.

    Reads directly from matchmaking-engine output; every row exposes its rcp_ receipt id.

  • Shippedmodule

    Introductions

    Identity-bound, consented introduction loop tracked from interested to met.

  • Shippedmodule

    Concierge

    A Chat-driven concierge that finds matches and requests introductions through guarded tools.

  • In progressmodule

    Agenda

    Per-delegate personalized agenda over the event programme.

  • In progressmodule

    Organizer CRM

    The organizer console — room health, curation, and sponsor relationships.

  • In progressmodule

    Analytics

    Relationship movement and meeting outcomes — ROI the organizer can show a sponsor.

Platform, distribution & proof

The platform that makes the above reusable, discoverable, and verifiable.

3
  • Built & testedtemplate

    Landing template

    This template — one config drives a search- and agent-first landing for any app.

    Emits llms.txt, a JSON-LD graph, and a /.well-known product manifest from the same config as the page.

  • Livesurface

    Live customer deployment

    A branded single-tenant skin — live, with people-matching running in production at an invite-only executive summit.

  • Shippedproof

    The outcome record

    Every match, introduction, and outcome is kept as a record you can revisit — the proof layer behind sponsor ROI.

    The audit layer — an integrating agent verifies outcomes instead of trusting them.