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. It comes down to one simple idea, and it applies across your whole 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, most importantly, 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 brings in the second kind of thing.

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 tab in Memories draws those links. Second, each type has rules. A decision must carry its rationale: if you cannot say why, it is a note. A task is a commitment with an assignee and a due date, which is why “what do we owe this client?” has a precise answer.

That set of typed, linked memories is what “machine-readable business” means in practice. An AI tool that can only search your documents finds the pages that mention Meridian. With this structure, it can answer: “What are the open commitments to Meridian, who owns them, and what decision were they based on?” That answer is only possible because the structure exists.

Events become entities

To see how the two connect, follow one 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 changed five memories, and each one is labelled with who saved it and with which tool: “Claude · Deniz”, say. That record is what lets you trust the 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. The same rule runs through every workflow in this academy, from pre-meeting briefs to the decision log: cite or omit, never invent.

What an AI tool saved, a person can correct. Open any memory in the app to edit it, archive it if it should not be there, or move it to the engine where it belongs. The tool does the routine saving, and you make the final call.

Keeping the memory healthy

One more mechanism decides whether the memory stays useful as it grows. A busy team saves a lot. A memory that only accumulates becomes a swamp within a year: slow, contradictory, full of stale fragments. That is what happens to most “record everything” systems, from shared drives to unlimited chat history: everything is kept, and little can be found.

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 a tool tries to save something whose title matches a memory already there, the save is refused and the tool is pointed to that memory to update instead. Lookalikes, such as “Meridian” and “Meridian Freight Ltd”, are reported back to the tool that saved them, and a person can archive the extra one.

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

The structure has three practical consequences.

Legibility. Your company’s memory should be something you can read yourself. 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.

Precision. Because memories are typed and linked, precise questions get precise answers: open tasks, by assignee, past due, for this customer, with the decisions behind them. You can ask in any connected AI tool, and anyone on the team can ask the same question in Ask. Many reports your company assembles by hand could become a question instead.

Reuse. Once your business is kept this way, as typed memories with an honest history, the things you build on top are ordinary questions. Briefs, weekly reports, account records that survive a handover: each is a different question asked of the same memory. Instead of ten separate AI projects, you 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 can be swapped; the structure is what lasts.