Meshi / Universal Event Graph

Reference Architecture for Agent-Ready Events

Meshi is an agent-native backend for portable professional identity, event context, evidence-backed intelligence, and explainable matchmaking.

The Universal Event Graph (UEG) is the broader industry model: a common way to make events readable, actionable, and durable for personal agents, organizer systems, and developer applications. Meshi is the current commercial implementation path: it turns messy people, event, and organizer data into a governed intelligence layer that agents and applications can safely use.

This document reflects the current Meshi implementation. It avoids overclaiming: Meshi is strongest today around people, identity, evidence, enrichment, goals, briefs, matching, organizer imports, and agent/API access. The broader UEG object universe is directionally supported, but not all of it is fully standardized yet.

1. The Architectural Thesis

Events are moving from app-centric participation to agent-mediated participation.

In the old model, the organizer built an event app and hoped attendees used it. In the emerging model, attendees, organizers, and sponsors increasingly rely on agents that need structured access to people, goals, sessions, context, permissions, and possible actions.

An agent-ready event is therefore not just an event with an app. It is an event whose underlying data is structured enough that an authorized agent can:

understand who is attending
understand what people want, offer, and need
explain why a connection or action is relevant
act through governed rails rather than free-form automation
preserve useful context after the event ends

Meshi’s core role is to make event participation computable without collapsing trust, identity, provenance, or organizer control.

2. What Meshi Is Today

Meshi is not primarily a branded event app, and not primarily a single assistant. It is an operating layer.

Current Meshi implementation centers on:

portable person identity: a person exists independently of one event, app, organizer, or login account
evidence preservation: imported rows, LinkedIn profiles, web research, documents, and other source records are stored as immutable evidence snapshots
identity-safe enrichment: sources are linked conservatively to canonical people, with review paths for uncertain LinkedIn and web research matches
structured intelligence: traits, timeline records, goals, briefs, embeddings, match scores, and icebreakers are derived from evidence
organizer context: organizations, groups/lists, events/vibes, participants, sessions, invitations, and imports provide event-specific context
agent and API access: REST APIs, MCP tools, OAuth, Coach runtime, voice, and admin surfaces expose the same underlying service layer
asynchronous orchestration: Inngest workers handle enrichment, inference, embeddings, briefs, research, scoring, merge workflows, and recovery

The product can support organizer mode, individual portable mode, and public/agent mode over time. Today, organizer and individual/coach foundations are both present, with the deepest maturity in the identity/evidence/person intelligence substrate.

3. Reference Architecture

Meshi sits between systems of record and agent/application interfaces.

Layer	Current implementation	Role in agent-ready events
Systems of record	Registration lists, CSV imports, CRM-like attendee data, LinkedIn, web research, documents, connected calendars, organizer systems	Remain authoritative for their own data; Meshi does not require replacing them
Organizer context	`org`, `org_membership`, `group`, `group_member`, `event`, `event_participant`, `event_session`, invitation/import tables	Provides event/list/vibe context around canonical people
Canonical identity	`entity`, `person`, `auth_user_person_link`, `person_external_identity`, `entity_relationship`	Separates real-world person identity from login accounts and event-local records
Evidence layer	`source_record`, `source_record_entity_link`, source chunks, timeline source links	Preserves where knowledge came from and why it was linked
Intelligence layer	`trait_claim`, `timeline_record`, `goal`, `canonical_brief`, embeddings, research jobs, pipeline status	Converts evidence into structured profile knowledge and readable summaries
Matching layer	goal-derived needs/offers, values embeddings, brief embeddings, match scores, mutual-fit records, icebreakers	Produces explainable recommendations downstream of identity and evidence
Orchestration layer	domain event outbox, Inngest workers, pipeline sweep, cost/activity tracking	Runs long-running and retryable work outside the request path
Agent/action layer	REST API, MCP server, Coach runtime, approval queue, quests, notifications, integrations	Lets authorized agents read, reason, ask, propose, and act through governed tools
Admin/product surfaces	web app, admin app, pipeline review, person detail, import quality/cost reports	Gives organizers and operators control, review, and observability

The important design point is that Meshi is not “AI over a spreadsheet.” It is an evidence-backed graph and service layer that agents can call.

4. Core Data Model

Entity and person

entity is the universal root. A person is a typed extension of an entity. This allows Meshi to support people now and organizations, events, opportunities, or other subjects later without rewriting the intelligence layer.

Authentication is separate. A Better Auth user is an account principal. A Meshi person is a canonical professional identity. They are linked explicitly through auth_user_person_link.

Sources and provenance

Every meaningful input is stored as a source_record: attendee import row, LinkedIn profile, user connection import, agent contact import, web research result, or manual entry.

source_record_entity_link records which source was linked to which entity, with link basis, confidence, status, and evidence details. This is what allows Meshi to distinguish:

the source itself
the person it was linked to
the confidence of that linkage
whether the source remains active, rejected, or superseded

This is essential for demo trust and long-term auditability.

External identity anchors

person_external_identity stores accepted or observed identity anchors such as LinkedIn URLs, emails, and other strong identifiers. Disputed candidates are retained rather than silently erased.

Traits, timeline, and briefs

trait_claim stores atomic claims such as skills, values, experience, location, and other profile facts. Claims have origin, authority, status, evidence references, and schema-enforced lifecycle rules.

timeline_record stores structured history, currently work and education facts, with source provenance.

canonical_brief is a narrative synthesis. It is downstream derived content, not the source of truth for structured state.

Goals and matching

Goals are first-class records, not just traits. A goal can produce derived needs and offers, which become the primary signal for matching.

Matching is downstream of the substrate. Current matching uses:

goal complementarity
values alignment
general similarity through brief embeddings

This supports explainable matching: not just “these people are similar,” but “this person may help with this goal, and here is why.”

5. Event and Organizer Model

Meshi now has real organizer and event primitives.

Concept	Current implementation
Organization	`org`, memberships, roles, permissions, feature flags
Group/list	`group`, `group_member`, group imports
Event/vibe	`event`, `event_participant`, `event_session`, session participants
Invitation/import	invitation records, import rows, group/event add flows
Organizer access	role-based permissions checked in the service layer

This gives Meshi a working organizer control plane for lists, event participants, and event-like contexts. It is not yet a complete UEG standard surface for every possible session, sponsor, booth, meeting, policy, or event inventory object. The current implementation should be described as an event-ready foundation, not a finished universal event ontology.

6. Current Import and Enrichment Pipeline

For organizer imports and demo datasets, the pipeline is:

Import people into an org group/list.
Create or reuse canonical entity and person rows.
Store the original row as a source record.
Register known identity anchors such as email or LinkedIn URL.
Track progress in person_pipeline.
Discover or confirm LinkedIn candidates.
Fetch LinkedIn profile data when a match is accepted.
Materialize source chunks and timeline records.
Infer traits and goals from trusted evidence.
Run web research where needed.
Store accepted or candidate web sources with evaluation rationale.
Generate embeddings, briefs, match scores, and icebreakers asynchronously.
Surface uncertain cases in admin review queues when configured.

This pipeline is intentionally conservative. Identity integrity beats recall: a fuzzy match that might be wrong is review-grade, not silently canonical truth.

7. Agent and API Surfaces

Meshi is API/MCP-first.

Current access paths include:

Hono REST API for web, admin, coach, organizer, onboarding, contacts, research, pipeline, goals, match, documents, billing, integrations, and profile flows
Better Auth for sessions, Google/email auth, OAuth/OIDC, and Dynamic Client Registration for external clients
MCP Streamable HTTP endpoint at /mcp, backed by direct service-layer tools
scoped MCP tools for onboarding, profile, contacts, groups/lists, events/vibes, traits, goals, search, and matching
Coach runtime with persistent conversations, memory, quests, approvals, notifications, scheduling, voice, and dynamic integration tools
Google Calendar integration groundwork through encrypted integration_connection records and provider-specific tool bundles

The same service layer powers API routes, MCP tools, admin flows, and worker-driven workflows. This is important: agents do not bypass the platform model. They operate through the same permissions, provenance, and domain boundaries as the product.

8. Orchestration and Events

Meshi uses Postgres as the source of truth and Inngest as the orchestration engine.

Domain mutations write durable rows first. When asynchronous work is needed, services write a domain event to domain_event_outbox in the same transaction. The outbox relay sends those events to Inngest and deletes outbox rows only after confirmed handoff.

Current event families include onboarding, enrichment, trait review, goal changes, evidence enrichment, match scoring, icebreaker generation, LinkedIn discovery, person review/no-LinkedIn states, and import events.

Workers handle:

LinkedIn discovery and fetch
enrichment
trait inference
goal inference and needs/offers extraction
source chunking
timeline extraction
brief synthesis
embeddings
evidence/web research
match scoring
icebreaker generation
import pipeline sweep/recovery
profile/event merge workflows
proactive scoring
account lifecycle and invitation workflows

The outbox is a relay, not a job queue. Workflow execution state belongs in Inngest and pipeline/job tables, not on canonical domain records.

9. Trust, Policy, and Explainability

Meshi’s trust model is concrete today in three places:

Source provenance: source snapshots and source-entity links preserve where evidence came from and how it was attached.
Claim authority: traits distinguish imported, inferred, organizer-asserted, user-asserted, and user-confirmed information.
Consumer trust profiles: different surfaces consume different claim sets. A review UI can show proposed and confirmed claims; stricter consumers can require confirmed claims.

The platform also has real permission boundaries:

auth principal and person identity are separate
org membership and role permissions gate organizer actions
MCP tools are scoped by OAuth grants
contact and connection operations enforce ownership
approval queue and quest systems mediate higher-impact coach actions

What should not be overstated: Meshi does not yet have a fully general UEG policy engine for all visibility, consent, sponsor inventory, cross-event sharing, and autonomous action modes. The current implementation is designed so those concerns can become platform-level policy rather than being scattered across one-off workflows.

10. What UEG Means in This Implementation

UEG should be understood as the external standard and readiness model. Meshi is the internal operating layer that can expose UEG-compatible surfaces over time.

The current Meshi implementation already supports several UEG principles:

people are portable across event contexts
event context is layered onto a person, not used as the person’s identity container
sources are preserved rather than discarded
recommendations are explainable through goals, evidence, and scores
agents operate through permissioned APIs and tools
useful context persists beyond one event

The parts still emerging are:

a complete public UEG ontology for sessions, meetings, sponsors, booths, opportunities, policies, and actions
a standardized external capability surface for arbitrary third-party agents
a mature consent and visibility policy engine
a full action rail for introductions, meetings, sponsor activations, and post-event follow-up
cross-event reputation or trust graph semantics

The right framing is therefore: Meshi is architected to implement and expose the UEG, but today’s strongest production-grade implementation is the people intelligence substrate and event/organizer context layer.

11. Value by Stakeholder

Stakeholder	Value
Organizers	Turn attendee lists into enriched, searchable, matchable intelligence without replacing registration or CRM systems
Attendees	Build portable professional context that survives a single event and can support better introductions, follow-up, and goals
Sponsors	Eventually receive better alignment between attendee intent and sponsor opportunities, once action/inventory rails mature
Developers	Build against stable APIs and MCP tools instead of rebuilding identity, evidence, enrichment, and matching infrastructure
Agents	Read governed context, explain recommendations, and take bounded actions through platform tools

12. Design Principles

Identity integrity beats fuzzy recall.
Evidence is preserved before intelligence is derived.
Event context should enrich a person, not trap the person inside one event.
Narrative summaries are helpful, but structured claims remain authoritative.
Matching is downstream of identity, evidence, goals, and context.
Agents should use governed tools, not scrape around the platform.
Policy and consent are platform concerns, even where the full engine is still evolving.
Meshi’s internal canonical model can be richer than any future public standard surface.

13. Current Technical Footprint

Area	Current implementation
Runtime	Deno 2, TypeScript
Database	Postgres with Kysely, generated DB types, migrations in `packages/db/migrations`
API	Hono, Better Auth, OAuth/OIDC, REST routes
Service layer	`packages/core`, shared by API, MCP, workers, and admin flows
Domain package	Pure TypeScript domain types, state machines, normalization, trust profiles, source keys
Workers	Inngest functions plus outbox relay
MCP	Direct service-backed MCP server with OAuth/API-key compatible auth paths
Coach	Runtime, tools, quests, approvals, memory, notifications, scheduling, voice, integrations
Frontends	web app and admin app

14. Shortest True Summary

Meshi is the operating layer for agent-ready professional events. It ingests fragmented event and people data, resolves canonical people conservatively, preserves evidence as immutable source records, derives structured profile intelligence, supports goals and explainable matching, layers organizer/event context on top, and exposes the result through APIs, MCP tools, admin surfaces, and coach/agent runtimes.

UEG is the broader standard direction. Meshi is the implementation path: strongest today in portable people intelligence and event-context foundations, designed to grow into a fuller standard surface for agent-ready events, actions, and cross-event continuity.