Events and Entities: How a Business Becomes Machine-Readable

The previous piece said a context layer keeps what your AI tools save in order, as a picture of your business rather than a pile of notes. 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 said “let’s go with the annual pricing” on a call. A support ticket closed.

These are events. They have a date, they involve people, and, this is the important property, they do not change. The meeting on March 4th will always have happened on March 4th. Events are the raw history of the company, and most of that history is noise: nobody answers “what should I know before this client call” by re-reading six months of email.

So a useful memory does not try to store every event. It keeps what each event changed, and it keeps an honest record of who changed it and when. That is the second half.

Things that exist: entities

Your client Meridian Freight exists. Sarah, their operations director, 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 commitment gets fulfilled. In Context Engine each entity is a memory 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
Customer	the company and its running story	Meridian Freight
Meeting	what was discussed and what it changed	the Mar 12 quarterly review
Task	a commitment: open or done, assignee, due date	”send revised proposal, Fri”
Decision	what was chosen, and the rationale	”annual-only pricing for new customers”
Note	anything worth keeping that is none of the above	the account’s deal context
File	a document, its text searchable	the signed Meridian contract
Identity	who you are: purpose, values, voice	your brand as infrastructure

Two things make this more than a filing scheme. First, memories link to each other: Sarah links to Meridian, Meridian links to the pricing decision, the decision links to the meeting where it was made. The Map in Memories draws exactly that web. Second, the types are opinionated. A decision must carry its rationale: if you cannot say why, it is a note. A task is not a sticky note; it is a commitment with an assignee and a due date, which is why “what do we owe this client?” is a precise question and not a vibe.

That web of typed, linked memories 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. The Meridian call ends. You give the transcript to your AI tool, or it reads it through its own connector to your recording app, and you say “save what matters from this call.” The tool:

• saves the meeting, with a short account of what was discussed;
• saves the person it has never seen before, the new attendee from Meridian’s finance team;
• saves the decision made on the call, with its rationale;
• saves the two commitments, one yours, one theirs, as tasks with an assignee and a due date;
• updates Meridian’s running note: momentum, the new objection, the next step;

and links each of them to Meridian and to the meeting.

One event, five memories changed, and every one of them is labelled with who saved it and with which tool: “Claude · Deniz”, say. That traceability is the trust mechanism of the whole system. Every change is recorded with who made it, with which tool, and what it was before. When you use Ask in the console, the answer names the memories it came from. When an AI tool tells you “we promised Meridian a revised proposal,” you can open the task and see who saved it, when, and from which meeting. You will see this resurface as a design rule in every workflow in this academy, from pre-meeting briefs to the decision log: cite or omit, never invent.

What a machine saved, a human can correct. Open any memory to edit it, archive it if it should not be there, or move it to the engine where it belongs. The machine does the diligence; you keep the judgement.

Keeping the memory healthy

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

Context Engine works against that in three ways.

Summaries. The engine writes a plain account of each day from what was saved, then rolls days into weeks and weeks into months. A tool, or a person, can read last month in a page instead of a thousand memories.

Duplicates. When two tools save the same thing, identical memories are merged with both histories kept, and you can undo the merge. Similar ones are asked about on Home, so you decide whether “Meridian” and “Meridian Freight Ltd” are the same customer.

History. Nothing is overwritten silently. Every version is kept, so a wrong edit is a step back, not a loss.

Why this concerns you and not just engineers

Three practical consequences fall straight out of the structure.

Legibility. Your company’s memory should not be an opaque database. You can export an engine at any time as a ZIP of Markdown and JSON that opens without us. Here is an illustration of what the decision above might look like in that export, a plain text file with YAML frontmatter:

---
type: decision
title: Annual-only pricing for new customers
rationale: >-
  Monthly customers churned before they covered onboarding costs.
  Annual terms let us onboard properly and keep the price flat.
alternatives:
  - Keep monthly with a setup fee
tags: [pricing, meridian]
---
Agreed on the Meridian quarterly review, Mar 12. Existing monthly
customers keep their terms until renewal.

You, an auditor or a different tool entirely can read that without the engine running. Piece five explains why that matters more than it looks.

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

Leverage. Once your business exists in this form, typed memories with an honest history, everything downstream stops being magic and starts being plumbing. Briefs, weekly reports, account records that survive a handover: each is just a different question asked of the same structure. Companies that get this right do not build ten AI projects. They build one memory and ask it ten questions.

Build this yourself

1. Create an engine with a purpose that names the kinds of things it should hold: “Customers, the people there, what we decided with them and what we owe them.”
2. Connect your AI tool with Can read and save.
3. After your next customer call, say: “Save the meeting, any decisions with their reasons, and any commitments as tasks with an owner and a due date. Link them to the customer.” Then open Memories and look at the Map.

Start free, or see plans.

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.