Events and Entities: How a Business Becomes Machine-Readable

The previous piece said a context layer “organizes what it hears” into a picture of your business. This piece explains how. There is one idea at the center of it, and once you see it, you will see it everywhere in your company.

Everything in a business is one of two things: something that happened, or something that exists.

Things that happened: events

A meeting ended. An email arrived. A deal moved to “negotiation.” Someone posted “let’s go with the annual pricing” in Slack. A support ticket closed.

These are events. They have a timestamp, they involve people, and, this is the important property, they never change. The meeting on March 4th will always have happened on March 4th. Events are the raw history of the company, and a context layer records them as an append-only log: nothing is ever edited, only added. That gives you something most companies have never had: a single, trustworthy timeline of what actually occurred, across every tool.

But a timeline alone is a terrible memory. Nobody answers “what should I know before this client call” by re-reading six months of raw history. You need the second half.

Things that exist: entities

Your client Meridian Freight exists. Sarah, their operations director, exists. The Q3 renewal deal exists. The decision to drop the monthly tier exists. The commitment to send them a revised proposal exists, at least until someone fulfills it.

These are entities: the durable things in your business. Unlike events, entities change over time. Sarah gets promoted. The deal advances. The commitment gets fulfilled. Each entity is a living record with a type, and the types are worth listing, because they are close to a complete inventory of what a business is made of:

Type	What it holds	Example
Person	who they are, role, how you know them	Sarah, ops director at Meridian
Company	the account and its running story	Meridian Freight
Meeting	what was discussed and what it changed	the Mar 12 quarterly review
Task	a commitment: owner, counterparty, due	”send revised proposal, Fri”
Decision	what was chosen, why, alternatives	”annual-only pricing for new logos”
Note	durable reference knowledge	the account’s deal-context narrative
Journal	the running story of each day	”Tuesday: pricing shipped, Meridian call…”
Identity	who you are: voice, mission, principles	your brand as infrastructure

Two things make this more than a filing scheme. First, entities link to each other: Sarah links to Meridian, which links to the renewal deal, which links to the pricing decision, which links to the call where it was made. Second, the types are opinionated: a task is not a sticky note, it is a structured commitment with an owner and a counterparty, which is why “what do we owe this client?” is a precise query and not a vibe.

That web of typed, linked records is what “machine-readable business” actually means. It is the difference between an AI that can search your documents and an AI that can answer: “What are the open commitments to Meridian, who owns them, and what decision were they based on?” The first is retrieval. The second is understanding, and it only works because the structure exists.

Events become entities

Here is how the two halves connect, using one concrete event. A call transcript arrives from your recorder. The layer reads it and:

• enriches the meeting entity for that calendar slot with a summary of what was discussed;
• updates the people who attended (and creates, provisionally, the one attendee it has never seen);
• captures the decision made on the call, with its rationale, as its own entity;
• captures the two commitments, one yours, one theirs, as task entities linked to their owners;
• patches Meridian’s running account note: momentum, the new objection, the updated next step.

One event, five entity updates, and every one of them traces back to the transcript that caused it. That traceability is the trust mechanism of the whole system: when an AI tells you “we promised Meridian a revised proposal,” it can cite the call, on the day, where the promise was made. No black box, no hallucinated history. You will see this resurface as a design rule in every workflow we build, from pre-meeting briefs to the self-writing decision log: cite or omit, never invent.

Notice also the word provisionally. Facts the machine inferred, a new contact, a commitment heard in a transcript, enter the record flagged as provisional until a human confirms them in a quick daily review. Machine diligence, human judgement, clear boundary between the two.

The overnight pass: memory that stays healthy

One more mechanism matters, because it is the difference between a memory that lasts and a pile that grows. Raw history accumulates fast: a busy team generates thousands of events a week. A layer that just stores everything becomes a swamp within a year, slow, contradictory, and full of stale fragments. This is, incidentally, the fate of most “record everything” systems, from shared drives to unlimited chat history: total recall, zero recollection.

So a good context engine consolidates on a schedule, the way you do. Every night it compacts the day’s fragments into a clean journal entry: what happened, what changed, what emerged. Days roll up into weeks, weeks into months, months into quarters. The full raw history stays available for audit, but the working memory, what agents actually read from, stays compact and current. Twelve months in, the engine is as fast and trustworthy as it was in week one.

The nightly pass has a second job: noticing. While consolidating, the engine looks across time and across entities for structure no single event shows: a theme recurring in your meetings, a tension between a decision and what is actually happening, an account gone unusually quiet. What it notices is surfaced as suggestions with evidence attached, and, an unusual property worth naming, each one carries the conditions under which it should be considered wrong, and retracts itself if they come true. Memory that reasons about itself, carefully.

Why this concerns you and not just engineers

Three practical consequences fall straight out of the structure.

Auditability. In a well-built engine, this whole structure lives as plain, readable, versioned files. You, or an auditor, or a different tool entirely, can open the record of your business and read it without the engine running. Your company’s memory should not be an opaque database; it should be legible, because you may one day need to read it without anyone’s permission.

Precision. Vague questions get vague answers everywhere. But the structure means precise questions get precise answers: open tasks, by owner, past due, for this account, with the decisions behind them. Every report your company assembles by hand is a query someone could stop assembling.

Leverage. Once your business exists in this form, typed entities plus a trustworthy event history, everything downstream stops being magic and starts being plumbing. Briefs, digests, self-updating CRMs, handover-proof client records: each is just a different question asked of the same structure. Companies that get this layer right do not build ten AI projects. They build one memory and ask it ten questions.

The structure also explains the next piece’s claim: that many average agents sharing this memory beat a genius agent without it. The agents are replaceable. The structure is the asset.