ConferenceOS runs the entire conference in one self-contained system — website, CFP, schedule, tickets, sponsors, attendees, check-in, communications, support, and the books. It is agent-native: your own Claude or ChatGPT can operate and reshape it, and the traditional console is always right there beside it.
Most event platforms are a good product surrounded by five other subscriptions and a folder of spreadsheets. ConferenceOS is built the other way around.
One system holds the whole conference: the public site, the call for proposals, the schedule, tickets and money, sponsors, attendees, onsite check-in, communications, support, and the report afterward. Not a hub that integrates six products — the products themselves, sharing one database.
No spreadsheet is load-bearingThe AI is not a chat box bolted onto a form. Every capability is exposed as a permissioned tool your own assistant can call, so it can read the live event, complete the work, and reshape the system around how your conference actually runs.
Your AI operates it, not just describes itAsk Claude or ChatGPT to do it, or click through the console yourself — same data, same permissions, same audit trail. You never lose the screens, dashboards, and confirmations you would expect from ordinary software.
Conversation and console, never a choiceEach row is a subscription, a login, an export, and a reconciliation step that stops existing. One database means a speaker, a ticket, and a sponsor are the same records everywhere they appear.
Nothing is load-bearing that you have to maintain by hand. When the schedule changes, the public site, the attendee app, the personal agendas, and the notifications change with it — because there is only one schedule.
Every job can be done by asking your AI or by clicking through the console. Same data, same permissions, same audit trail — so adopting the AI is never a bet you have to make all at once.
“Move the 2pm panel to Room 204 and tell everyone affected.”
Open the schedule builder, drag the session, confirm the notice.
“Which accepted speakers haven’t uploaded a headshot?”
Filter the speaker list by outstanding deliverables.
“Refund order 4471 in full — she broke her ankle.”
Open the order, choose refund, enter the amount and reason.
“What changed since Monday, and what’s blocked?”
Read the activity feed and the readiness dashboard.
The AI does not get blanket access. Every request is grounded in event context, bounded by the role on its key, and captured in the operating history.
The AI reads the live event — sessions, registrations, speakers, money, and the current state of the work — through tools scoped to its role.
An instruction becomes a bounded change: the session moves, the notice drafts, the refund processes, the record updates. Same write path the console uses.
CRM writes come back as a preview before they commit, and every action — human or AI — lands in one audit trail you can read afterward. A blocking approval queue across all write tools is on the roadmap.
Every conference has a rule that does not fit the form — a scholarship track, a weird sponsor tier, a review process with three rounds. Four layers of adaptation, from asking for it to building it yourself.
Ticket tiers, tracks, review criteria, policies, sponsor packages, email templates, and the public pages are all configuration your AI can set up and change on request — not a support ticket and not a release cycle.
A visual theme editor with live preview controls colors, typography, logo, and button style across every attendee-facing page. Save it as a template and carry it to next year’s event.
Every core capability is already here. For the thing that is not, you have two honest options: connect the tool you already use through the REST API, signed webhooks, or a native connector — or have your AI build the missing piece against the same permissioned tools it uses for everything else. Neither one requires database access or a services engagement.
Your own instance, your own database, your own Stripe account and payout schedule, and a configuration backup you control. Leaving is an export, not a negotiation.
Self-contained is not the same as closed. Everything a conference actually needs ships in the box — so integrations are a choice you make, not a tax you pay to reach a working system. When you do want something else, connect it or build it.
No add-on modules and no per-feature upsells — this is the product. The roadmap of what is not here yet is stated just as plainly on the features page.
The same operating model carries decisions and data across every stage instead of resetting at each tool or team boundary.
The business case, the capability detail, the operating model, the architecture, and the honest comparison against what else you could buy.
A four-level benefit ladder from organizer productivity to reusable portfolio operations.
Explore →02 / CapabilitiesEvent setup, programming, ticketing, partners, community, growth, onsite workflows, agents, and the roadmap.
Explore →03 / Operating modelOne connected event graph, role-shaped workspaces, automated handoffs, and governed interfaces.
Explore →04 / ArchitectureThe small required foundation and capability-specific providers that support the full platform.
Explore →05 / Connection layerNative connectors, open interfaces, reliable handoffs, local provider marks, and the adapter roadmap.
Explore →06 / TransparencyThe application’s primary components, resolved versions, licenses, and downloadable CycloneDX snapshot.
Explore →07 / EvaluationA feature matrix against enterprise suites, mid-market platforms, and stitched-together tool stacks across lifecycle, AI access, control, and deployment.
Explore →