Rethinking Chat Systems for Events in the AI Era

Key takeaway: When every message sits in a time-sorted stream, AI has to guess what each conversation is about. When conversations are pinned to scheduled activities — as nodes with time, space, and topic context — they form a knowledge graph that AI can actually work with. The architecture of your communication tool determines whether your organization’s collective knowledge grows with each event or drowns in noise.

---

Here is something I think a lot about. When we ask about the projector cables in the same channel as lunch orders or parking questions, how much coordination data is lost when AI tries to learn about your event?

I think we should revisit chat architecture to adapt to the AI era, where your ability to collect contextual data makes all the difference between your organization’s collective knowledge growing with each chat or drowning in it.

I’ve been producing events for two decades, and I’ve also been building event-coordination software with my co-founder for the past four years. One design decision we debated early on was whether conversations in our system should flow in channels (like WhatsApp, Teams, or Slack channels) or sit as nodes pinned to specific scheduled activities. We chose nodes.

It felt less intuitive at first. And people are so used to “channels” that we had to “hide” our architectural concept inside “channels” to make it more familiar to our users.

But the more I work with AI, the more I believe our node-based approach can fundamentally change how teams coordinate and capture data in the era of AI.

“In a complex system, how things connect is more important than what they are.” — Dave Snowden

Events are complex systems. A 10-minute delay in one area can cascade through an entire operation.

If you keep reading, you’ll learn:

• Why events behave as “complex adaptive systems,” and why tools built for “complicated” problems fail in complex environments.
• How communication architecture shapes coordination quality.
• Why node-based communication produces dramatically better inputs for AI than stream-based chat, and what that means for the future of event operations.

Events Are Complex Systems, Not Complicated Ones

There is a distinction I find very useful when thinking about events. It comes from the Cynefin framework, developed by Dave Snowden, and it separates problems into two categories that sound similar but behave very differently: complicated and complex.

A complicated system has many parts, but you can analyze it. You can take apart a Boeing 777 engine, study every component, and reassemble it. The logic is in the design. A complicated system rewards expertise and planning because cause and effect are knowable if you look hard enough.

A complex system is different. You cannot take it apart, put it back together, and expect it to behave the same way. Too much of the information lives in the dynamics — in the relationships between the parts rather than the parts themselves.

Here is where it gets interesting for event professionals. Your event runsheet looks complicated. It has rows, columns, timestamps, and assignments. It looks like something you can decompose and manage piece by piece. But during execution, an event behaves like a complex system. A speaker runs 10 minutes over, which pushes the coffee break, which delays the room flip for the next session, which means the AV crew misses their setup window.

The approach for complicated problems is: sense, analyze, respond. You study the problem, identify the right practice, and apply it. That is what a spreadsheet encodes. That is what a task manager assumes. You break the event into rows and check them off.

The approach for complex problems is different: probe, sense, respond. You try something, watch what happens, and adapt. The tools we use carry assumptions about which world we are operating in. Spreadsheets assume events are decomposable rows. Task managers assume linear sequences. I think these are “complicated-domain” tools applied to a “complex-domain” problem. And based on what I have seen, that mismatch costs teams a lot of coordination energy during execution, exactly when they can least afford it.

How Communication Architecture Shapes Coordination

Marshall McLuhan said something in the 1960s that I keep coming back to: the medium shapes the message. The tool you use to communicate changes the communication itself, often in ways you never notice.

Similarly, Conway’s Law says organizations end up mirroring the structure of their communication tools. If your tool is a checklist, you start thinking in checklists. If your tool is an endless chat stream, you start thinking in real-time reactions rather than structured coordination.

The aviation industry learned this the hard way. In the late 1970s, NASA studied cockpit failures and discovered something that surprised a lot of people. Most accidents were communication failures, not technical ones. Pilots had the skills and the information. What they lacked was structured communication, shared situational awareness, and the protocols to keep everyone on the same page continuously.

What emerged from that research was Crew Resource Management (CRM), a set of communication protocols that transformed aviation safety. The lesson was clear: in high-stakes, time-sensitive operations, the structure of communication determines the quality of coordination.

I think events face the exact same challenge. Research on emergency response has found that complex adaptive systems require a balance between centralized coordination and decentralized adaptability. That sounds abstract, but every production manager knows this feeling. You need a central plan that everyone trusts, and you need the people on the ground to adapt when things change. The tool your team uses to communicate shapes which of those two things is possible.

If WhatsApp is your coordination tool, then chronological order is your organizing principle. Every conversation, regardless of topic, sits in streams that at best have some categorization. But more typically, it’s just organized according to who should speak to whom. Considering how challenging communication can be at events, I suspect the architecture of the tools plays a role.

Channels vs. Nodes: A Design Decision with Big Consequences

When we started building our software at MergeLabs, we had a real debate about how conversations should work. The familiar model is what everyone knows from WhatsApp, Slack, or Teams: conversations flow in channels, sorted by time. The alternative was something we called “nodes” — conversations pinned directly to specific scheduled activities.

We need to understand this: when messages are sorted only by time, the connection between a question and its answer gets broken by whatever else lands in between. Not to mention the ability to understand context when multiple subjects are discussed in the same channel.

Now, this has been improved upon through the concept of “threading,” but at best, you have only one additional point of context: that these messages belong together.

We’ve taken a completely different approach to messaging and built everything as nodes that sit with the activities. That one design decision already gives every conversation time, space, and topic information. But we didn’t stop there. We’ve connected activities with notes, associated them with different schedules and runsheets, and assigned roles and tasks that carry their own status: “ongoing,” “done,” or “blocked.” Soon, we’ll also attach feedback data and conflict results. Each new point of context enriches the others, and the conversation around that activity gets exponentially richer because of it.

We can now switch between the familiar “channel” interface or have the conversation right with the activity. And either way, the context is saved. The underlying architecture is specifically designed to capture more coordination data in a machine-readable way.

Why This Matters for AI

There is a principle in data science that I keep hearing repeated: clean, well-structured inputs produce more accurate outputs. When data is noisy and jumbled, AI models learn errors and inconsistencies alongside the useful information. If garbage data makes it into your system, it can ruin everything.

Clean water in a dirty bucket still produces dirty water.

An event’s activity structure, with its schedules, dependencies, roles, and pinned conversations, is essentially a knowledge graph. Each activity is a node. Each dependency is a relationship. Each conversation carries the context of where, when, and what it relates to. Research has shown that knowledge graphs reduce AI hallucination by providing models with authoritative context to refer back to, rather than having to guess.

A chat log from WhatsApp or a Slack channel is the opposite of that. It is a stream of messages sorted by time, with no inherent structure linking a message to the activity, the schedule, or the dependencies it relates to. When you hand that to an AI system, it has to guess the context. And guessing is where AI produces unreliable results.

Teams using stream-based tools are generating data that is very hard for AI to process meaningfully. We believe our node-based approach will solve this problem and produce a structured knowledge base that AI can process. And this even compounds over time. Every conversation pinned to an activity adds context. Every decision logged against a schedule item becomes retrievable. Each event edition adds to a growing body of operational knowledge that AI can actually work with.

This is the design philosophy behind what we are building at MergeLabs. We chose nodes because they felt right for coordination. But the more we work with AI, the more we realize that the architecture also determines whether your organization’s collective knowledge grows with each event, or gets buried in a stream that nobody will ever search through again.

If you are coordinating events through group chats and spreadsheets, I am curious: has AI been able to reliably analyze all that data at scale for you?

In an upcoming article, I am going to dig into why events have a memory architecture problem, and why the knowledge your team builds edition after edition tends to vanish when the wrong person leaves.