Essay

Many Conversations, One EMET

Three bands of blue flowing in from the left and converging into a single coral circle

Yesterday I got lost. Not metaphorically. I literally found myself trying to understand where the conversation with Victor and Dora was happening.

We had Telegram groups, topics inside groups, direct conversations, technical discussions, brainstorming threads, and WhatsApp messages. Each space made sense when it was created. Yet together they had started to create something none of us intended: fragmentation.

The irony was hard to miss. We are building EMET to help human teams collaborate with agents — and our own human-agent team was beginning to suffer from exactly the problem EMET is supposed to help solve.

That turned out to be useful. Because it shifted an architectural discussion into a lived experience.

The problem is not memory

For some time, we had been thinking about EMET’s memory. We started to distinguish between different layers: a protected Genome containing the core identity of EMET, Team Memory belonging to a particular team, and Experience that allows EMET to learn more broadly over time.

That distinction is important. But yesterday I realized that memory architecture alone is not enough. A team doesn’t simply need somewhere to store information. Information moves.

A conversation happens somewhere. Something in it becomes significant. A decision emerges. Knowledge needs to be classified. Some of it remains private. Some becomes part of the team’s shared understanding. Some may eventually become reusable learning. Later, someone needs to retrieve it — perhaps from an entirely different conversation.

Conversation → Interpretation → Classification → Promotion → Retrieval → Learning

The important question is no longer just: where does EMET remember something? It becomes: how does knowledge move through a human-agent organization?

We are the domain experts

Victor made an analogy that immediately resonated with me: this is like being a data architect rather than building a database. A database is technology. A data architecture starts somewhere else: What information exists? Who owns it? Where should it flow? What relationships matter? What should remain separated? What should become shared? Only after answering those questions should we decide how to implement them.

The same is true here. We can experiment with Hermes, RAG, databases, agents, Telegram integrations and whatever comes next. Victor is taking responsibility for the first technical iteration partly so that we can develop a better mental model of what the technology can actually do.

But technology cannot tell us what collaboration should look like. That is our job. As the humans experiencing this new form of work, we are the domain experts. We need to define how information, knowledge and learning should flow between people, between agents, between teams, and eventually between organizations.

That may be one of EMET’s most important design problems.

A team needs a home

Then something much simpler happened. I realized I was missing a place where the three of us could simply talk.

Telegram topics are useful because they create structure. But structure has a cost. As different topics become active, the human conversation becomes distributed across them. Even the #general topic doesn’t fully solve this. It is still one topic among many, and can disappear down the interface as other topics become active.

So I suggested creating another Telegram group. Just the three of us and EMET. No topics. One continuous conversation. Victor immediately agreed. We created it.

It seems like a tiny operational decision, but I think it contains an important design principle: humans need a home, not only a filing system.

← All posts

Building AI that works with people, not around them?

Let’s Talk