Every suggestion this platform makes has to name its reason
EventfullyManaged is AI-native the unglamorous way: one connected event graph, engines that compute over it, and a written reason attached to every score they produce. What is model-backed and what is arithmetic is labelled, not blurred.
An event is not a pile of records — it is a graph. One event owns sessions, each with a room and a time window; sessions link to speakers; ticket types produce registrations; registrations resolve to attendees; attendees scan in and out at stations; attendees opt into networking profiles that carry interests and asks; profiles pair into matches that become meetings. EventfullyManaged holds all of that in a single workspace-scoped subgraph. That is the precondition for any useful intelligence, and it is why so much event software cannot do this: when the schedule lives in a spreadsheet, the registrations in a ticketing vendor and the badge scans in a rented scanner, nothing can reason across them.
So we built on the graph first, and we shipped the honest layer. Two capabilities are live today, and neither one calls a language model. The matchmaking engine scores every opted-in pair at an event from the interests, asks and industry those people actually filled in, and writes a plain sentence next to the number — shared interests, complementary fit, same industry. A pair with no overlap scores zero and is never written at all, so the match list never fills with confident-looking noise. The agenda scan reads every session's room and time window plus every speaker assignment and returns the clashes: the same hall booked twice, one speaker on two stages. Both are deterministic. Both are auditable. Both are better for it — arithmetic never misses a conflict and never invents one.
The reason they are deterministic is written into the source code, not into a marketing decision. The shared platform runtime that will give this product real model access — a multi-model gateway, a model catalog and a ledger of every agent run — is not built yet, and no per-product model key exists. The choice was to defer matchmaking indefinitely, fabricate an AI-authored reason with nothing behind it, or ship an explainable scorer against the interface the model-backed version will eventually fill. We chose the third. So on this page, shipped means code you could read; in progress means built but ungoverned or ungrounded; and roadmap means a ticket, named. The forecasting, the scheduled briefs and the model-backed scoring are all roadmap, and they say so.
Every capability on this page is labelled with what is actually built in EventfullyManaged today — shipped, in progress, or on the roadmap.
AI-native by architecture, not bolted on
Four architectural choices that make AI a first-class part of EventfullyManaged rather than a chat window on the side.
One event graph, not seven vendors
Sessions, rooms, speakers, ticket types, registrations, attendees, badge scans, networking profiles, matches and meetings live in one workspace-scoped subgraph. Intelligence needs to read across all of them at once — which is impossible when the schedule, the ticketing and the scanner belong to three different companies.
No score without a reason
The match engine returns a number and the sentence that justifies it, built from the same overlap it scored. A pair with no signal is never written at all rather than persisted with an empty explanation. Two attendees can read why they were introduced before deciding whether to message.
Authority lives at the gateway
There is no privileged AI path into your data. Every field carries an access directive the API gateway enforces from the composed schema, and the workspace boundary is applied inside the service before any query runs. An assistant or an agent reaches exactly what its operator reaches, and every call lands in the audit trail with personal data masked.
Deterministic now, model-backed behind the same contract
The scorer sits behind a single function signature and writes to fields the model-backed version will write to as well. When the shared multi-model runtime lands, the scoring function is replaced and nothing above it changes — not the resolvers, not the persistence, not the interface. Shipping honestly today does not mean rebuilding tomorrow.
From intent to a governed action
Walk the path a request takes. Select any stage to see what happens there and what backs it.
Stage 1 of 6 · Signal
The event graph collects the inputs
Everything the engines read is already being captured by ordinary use of the product.
A networking profile records interests, what the person is looking for, their industry, their role and their visibility. A session records its room, its start and end time, and its capacity. A speaker assignment links a person to a session. A check-in record stamps every scan with a direction and a timestamp. None of this is AI-specific instrumentation bolted on for a feature — it is the operational data model, which is why the intelligence has something real to stand on.
How it works: Prisma models NetworkingProfile, EventSession, EventSpeaker, CheckInRecord in wspace-eventfullymanaged-svc/prisma/schema/schema.prisma
What the AI in EventfullyManaged actually does
Filter by delivery status, then open any capability for the detail and what backs it. No capability is listed as shipped without something in the product behind it.
Where the AI shows up
The places AI meets the work in EventfullyManaged — and how far each one has actually got.
Networking match engine
ShippedThe organizer-facing engine on the Networking page: pick an event, generate matches, read the reason on each row, book the 1:1 yourself.
- Scores every opted-in pair at one event and ranks them strongest first
- Writes nothing for a pair with no overlap — no reason-less rows
- Refuses to run below five opted-in profiles instead of forcing weak pairings
- Private profiles are excluded by the engine's own query, in both directions
- Re-running refreshes scores without resetting an accepted or declined match
See it as a real scenario
Every AI capability above shows up in a concrete EventfullyManaged story. Open one to read the full walk-through.
Suggest who should meet — and say why
Score every opted-in pair at an event and get ranked suggestions back, each carrying the shared interests, complementary fit and industry that produced its score. Live today.
Read the storyCatch the double-booked room before the programme goes out
Overlapping sessions in one room and speakers on two stages at once, flagged on the session form while the scheduling decision is still open. Detection ships; suggested fixes are roadmap.
Read the storyAsk the console instead of hunting through it
A page-aware assistant on every screen of the event workspace, bound by the same permissions as the interface. Event-domain grounding is still being built.
Read the storyLet your own AI client run the event back office
An MCP server exposing 67 event-domain tools, four resources and two guided workflows to the AI client you already use. Destructive-action confirmation is still on the roadmap.
Read the storyRight-size the room before registration closes
Forecast arrivals against registrations, predict no-shows per session, and turn both into capacity and staffing decisions. Roadmap — the inputs exist, the engine does not.
Read the storyA brief at T-30, T-7, T-1 — and a watch on the door
Scheduled planning briefs before the event and live check-in anomaly alerts during it, with an explicit line between what the platform may do alone and what it must ask about. Roadmap.
Read the storyAI you can actually let near your data
An AI-native product has to be governable. Here is where EventfullyManaged stands on each control — including the parts still being built.
The workspace boundary is applied before the query
Every engine and every read resolves the caller's workspace and asserts the event — and where relevant the attendee — belongs to it before any row is fetched. Cross-workspace access fails at that assertion, not at a filter over results.
Permissions enforced at the gateway, not in the prompt
Every query and mutation carries an access directive that the API gateway enforces from the composed schema; the service never validates tokens itself. An assistant or agent session reaches exactly what its operator reaches — there is no AI-only path into the data.
Opting out of networking means never being scored
A profile marked private is excluded by the matching engine's own database query, in both directions: it is not offered as a candidate to anyone and it receives no suggestions. Requesting suggestions for an opted-out attendee returns an empty list rather than an error, so opting out is not even detectable as a refusal.
The platform suggests; a person decides
Matches are created as suggestions and stay that way; regeneration never overwrites an accepted or declined decision. No meeting is booked by an engine, no session is moved by the conflict scan, and no announcement or campaign is sent without an explicit human action.
Audited operations with personal data masked
Every operation is recorded with its actor, workspace, fields and outcome, with attendee, speaker and lead personal data masked on the way in against an explicit token list covering emails, phone numbers, names, dates of birth and national identifiers. The trail is useful without becoming a second copy of your attendee list.
Evaluation sets and AI cost metering
Not built yet, and named rather than implied: there is no usage metering on AI-driven operations, no evaluation set scoring suggestions against real outcomes, no citation trail on generated content, and no defined fallback when the assistant is unavailable. These are launch requirements for the model-backed layer, not follow-ups.
Models
No language model is wired into EventfullyManaged today, and we would rather say that than imply otherwise. The two intelligence capabilities that ship — match scoring and agenda conflict detection — are deterministic computations over your own event graph, which is why every score arrives with a written reason and every clash names both sessions. The assistant in the console runs on the shared Burdenoff assistant runtime, and the MCP server lets you bring whichever AI client you already use. Model-backed scoring, forecasting and the autonomous ops loop are all gated behind the shared platform AI runtime — a multi-model gateway, a model catalog and a ledger of every agent run — which is not built yet. The scorer already sits behind the contract that runtime will fill, so a model can be swapped in without changing a resolver, a stored field or a screen. Bring-your-own-key is a stated intent in the pricing material, not a wired capability, and we are not going to describe it as one.
The honest answers
No. The match engine that ships today is a fully deterministic scorer over the interests, asks and industry each attendee entered on their networking profile. That is a deliberate, recorded decision: the shared platform AI runtime this product will use is not built yet and no model key exists for it, so the choice was to defer matchmaking indefinitely, fabricate an AI-authored reason with nothing behind it, or ship an explainable scorer against the same interface a model will later fill. We shipped the scorer. Every match therefore arrives with a reason you can read and check.
Put EventfullyManaged’s AI to work
EventfullyManaged is AI-native the unglamorous way: one connected event graph, engines that compute over it, and a written reason attached to every score they produce. What is model-backed and what is arithmetic is labelled, not blurred.