Build or Buy? Own the Event Object.

For years, enterprise technology strategy has started with a familiar question:

Build or buy?

I think that is increasingly the wrong place to begin.

Especially with AI.

Most organizations are going to do both. They will buy specialist systems that already perform specific functions well. They will build capabilities that are unique to their organization. They will connect platforms, providers, data sources and increasingly AI agents that were never designed as one system.

So before asking what to build and what to buy, I think Event Owners should answer a more important question:

What do we intend to create and own?

For enterprise Events, my answer is the Event Object.

A persistent, governed representation of the Event that can carry its operational intelligence across systems, people, suppliers, locations and editions over time.

Not another application.

Not another spreadsheet.

Not another dashboard.

Not another vendor's version of your Event.

Your Event Object.

The Event Industry Does Not Have a Software Shortage

CRM knows the customer.

Registration knows the attendee.

Finance knows the financial commitment.

The venue knows the space.

The production company knows the production plan.

Transportation knows where the truck is.

Legal knows the contract.

The hotel knows the room block.

The event platform knows engagement.

Individual suppliers may know labor, power, rigging, freight, food and beverage, security, signage or dozens of other specialized parts of the Event.

Those systems can be very good at what they do.

That is not the problem.

The problem is that each generally sees the Event from its own perspective.

The Event Owner is left trying to assemble those perspectives into something resembling a complete picture.

For decades we have often done that with people.

And spreadsheets.

And email.

And meetings.

And institutional memory.

Five people can spend weeks working inside what everyone believes is the current spreadsheet.

Version 14.3.

Then version 15.

Then somebody discovers version 19.

A formula was broken three revisions ago.

Finance has different information.

The venue has another document.

Legal has the latest contract.

Registration changed the attendance projection.

A producer made an operational decision two weeks ago that never made it into the spreadsheet.

Everybody has a boots-on-the-ground view from their own foxhole.

Almost nobody has the bird's-eye view of the Event.

That is not a failure of the individual systems.

It is evidence that something is missing between them.

A Single Source of Truth Is Not Enough

“Single source of truth” has become common enterprise language.

But I think Events requires something more specific.

The objective is not to copy every byte from every application into one enormous database.

EventOS does not need to own the CRM, registration system, venue platform, production software, ERP or transportation system.

It needs to know:

Where does the relevant information reside?

Which system is authoritative for it?

Who has permission to access it?

When does that information matter to this Event?

What does it mean when combined with everything else we know?

EventOS is designed to call upon the appropriate specialist system when its information is required, retrieve the authorized event-relevant data, and compose that intelligence within the governed Event Object. Relevant data need not all be duplicated or permanently imported; the object can preserve authoritative references, decisions, and context while retrieving source information when needed.

The Event Object becomes the common operating context.

And sometimes the most valuable discovery may be that the required information doesn't exist at all.

That matters.

Missing data is itself operational intelligence.

If nobody can answer what an Event historically spent on a recurring service, what a supplier actually charged across five editions, why a budget category consistently overruns, when a contractual decision was made, or what lesson was learned three years ago, identifying that absence may eventually save thousands or millions of dollars.

Or reveal an opportunity to generate them.

You cannot improve what the organization cannot see.

The Event Should Outlive the Event

This is where I think the industry has accepted an unnecessary limitation.

An Event happens.

The doors close.

Invoices are reconciled.

A debrief is held.

People move on.

Next year, much of the process begins again.

But why?

Consider a conference that has existed for decades.

Or more than a century.

Imagine the value of a persistent Event Object connecting its history across every available edition.

Not simply nostalgic photographs and old programs, although those have value too.

Imagine its evolving attendance, venues, budgets, suppliers, production designs, contracts, speakers, decisions, pricing, outcomes, issues, solutions, audience behavior, operating rules, lessons learned and institutional knowledge.

Year after year.

The next edition would not begin from a blank document.

It would inherit what the organization already knows.

A lesson learned once could become available wherever else that lesson matters.

Patterns invisible within a single event could become obvious across ten, fifty or one hundred editions.

Institutional knowledge would no longer depend primarily on whether the person who remembers the answer still works there.

The event ends. The Event Object doesn't.

That is a very different concept from an event-management application.

It is organizational memory becoming operational.

The Real Moat Is Automated Continuous Improvement

But preserving the Event's history is only the beginning.

The greater opportunity is what happens when AI can continuously examine that history, recognize patterns, identify opportunities and determine where those lessons might improve other Events.

Consider an enterprise portfolio of 120 Events.

Suppose an AI-native operating system identifies a meaningful operational improvement opportunity in just 1% of those Events on an average day.

That's an illustrative 1.2 improvement opportunities per day across the portfolio, before accounting for validation, duplication or applicability.

The individual improvements may seem modest.

A better labor scheduling rule.

A recurring supplier expense that can be avoided.

A contract clause that should be reviewed before the next venue negotiation.

A production dependency that consistently creates overtime.

A more effective way to forecast attendance.

But the real advantage isn't limited to the Event where the improvement was discovered.

What if one lesson could improve 20 other Events? Or 50? Or the entire portfolio?

An AI-native operating system could evaluate that discovery against other Event Objects, identify where the lesson applies, flag conflicts or exceptions, and recommend appropriate changes.

Authorized leaders would review and approve changes before they became operational rules.

The approved improvement could then be applied wherever relevant, with its source, decision history, effective date and measured results preserved.

That is a fundamentally different operating model.

Instead of 120 event teams independently discovering and rediscovering improvements, the portfolio begins to learn as one governed system.

And the benefits can compound.

An improvement identified today may inform tomorrow's production decisions, next month's supplier agreements and next year's planning assumptions.

Learn it once. Govern it once. Apply it everywhere it matters.

The moat isn't simply the accumulated data.

The moat is the persistent, governed Event Object and the organization's ability to turn its accumulated intelligence into continuous, measurable improvement.

That is the power of an AI-native Event Operating System.

Whoever Owns the Event Object Owns the Memory

This is why ownership matters.

Event Owners pay for the Event.

They assume the business risk.

They build the audience.

They fund the suppliers.

They live through the decisions.

They absorb the mistakes.

They earn the lessons.

So I think the Event Owner should ask a very simple question:

Why wouldn't we own the Event Object that preserves what our Events taught us?

That does not mean excluding agencies, venues, producers or suppliers.

Quite the opposite.

They may contribute some of the most important intelligence associated with an Event.

But the Event Owner should not have to surrender continuity every time the venue changes, a production company changes, an agency changes, an employee leaves or a software contract ends.

The industry's existing commercial and technology structures do not consistently enable agnostic operational transparency, continuity and Event Owner data ownership across those changes.

The result is predictable.

Knowledge fragments.

History fragments.

Accountability fragments.

Continuous improvement becomes difficult to achieve at portfolio scale because the organization repeatedly reconstructs what it already knew.

That is one reason the familiar responses persist:

“This is the way we've always done it.”

Or:

“Every event is custom.”

Both can become excuses for repeatedly rebuilding operating knowledge that should have been retained.

Custom Events do not require institutional amnesia.

AI Changes the Stakes

There is another reason this matters now.

Context.

In the traditional software era, fragmented data created inefficiency.

In the agentic era, fragmented context can create risk.

We are moving beyond applications that simply store information and generate reports.

AI systems can interpret information.

Recommend actions.

Identify patterns.

Coordinate workflows.

And increasingly act.

Those agents may operate inside CRM, finance, procurement, registration, transportation, production and countless specialist platforms.

But an agent operating within one system sees the Event through the context available to that system.

Transportation knows the truck is late.

Finance knows the commitment changed.

Registration knows attendance increased.

Production knows rigging starts at 2:00.

Legal knows a contract provision limits the available action.

Those facts become much more valuable when something understands what they mean together.

The truck is not merely 47 minutes late.

It may threaten the 2:00 PM rigging milestone.

That may affect labor.

Which may create overtime.

Which may change the budget.

Which may require an approval.

Which may affect another supplier's scheduled access.

That is Event context.

And that is why AI makes the Event Object more important, not less.

The organization that can compose its operational intelligence into governed context can ask questions and discover relationships that no individual specialist system can see alone.

The organization that cannot may simply automate fragmented thinking faster.

Interoperability Is the Imperative

This is why I have changed the way I think about Build versus Buy.

You will probably build.

You will probably buy.

You will almost certainly connect.

The question is whether those capabilities will remain a collection of isolated systems or become participants in a governed operating environment.

So:

Build or Buy is a sourcing decision.

Interoperability is the operating imperative.

Creating and owning the Event Object is the strategic decision.

The Event Owner does not need to own every system.

It needs to own the Event.

Built by Event Owners, for Event Owners

There is an important opportunity hiding inside that distinction.

The event industry has spent decades building excellent specialist capabilities.

Production companies know production.

Venues know venues.

Registration companies know registration.

Agencies know campaigns and experiences.

Technology providers know their particular applications.

But the Event Owner is the only participant whose interests naturally extend across the entire Event and across every provider involved in delivering it.

That makes the Event Owner uniquely positioned to define the missing operating layer.

Not to damage the provider ecosystem.

To make the ecosystem work better.

An Event Owner can establish the Event Object while continuing to use the best available venues, agencies, producers, suppliers and technologies.

Each participant gets to remain excellent at what it specializes in.

The Event Owner gains continuity across all of them.

That is why I increasingly believe the strongest version of an Event Operating System may ultimately be:

Built by Event Owners, for Event Owners.

The opportunity is not to replace the event industry.

It is to give the Event Owner an operating environment capable of learning from it.

A New Category of Operating Intelligence

AI appears to be pushing enterprise technology toward increasingly domain-specific operating layers.

Different industries have different terminology, workflows, decision rights, risks, data structures and institutional knowledge.

Events are no different.

They contain logistics, finance, procurement, marketing, sales, legal, production, hospitality, audience data, suppliers, assets, contracts, schedules and human judgment, all converging around one temporary moment in time.

The visible Event may last three days.

The intelligence required to produce it can span years.

And the knowledge created by it should last much longer.

That is my thesis behind EventOS.

Not that Events need another piece of software.

They need a governed operating layer capable of understanding the Event across the software that already exists.

A persistent Event Object owned by the Event Owner.

One that gets smarter as the portfolio learns.

One that preserves context as people, suppliers and systems change.

One that gives AI enough governed context to be genuinely useful.

And one that ensures the knowledge created by the Event remains with the organization that paid to create it.

So perhaps the next enterprise Events technology strategy should not begin with:

What should we build?

Or:

What should we buy?

It should begin here:

What do we intend to create and own?

My answer is the Event Object.