Companies do not only forget what happened or why a decision was made. They forget how work actually gets done, especially when the work crosses people, systems, approvals, and time.
The most important thing a Company Brain can do at the action layer is not act. Most automation systems act because they can. A useful system acts because the context says it should, and stays still when it should not. Doing nothing is a first-class action. The right move is sometimes to wait, sometimes to ask for approval, sometimes to notify someone without touching the underlying system, and sometimes to stop because the action is technically possible but organizationally wrong. If a Company Brain cannot do nothing on purpose, it cannot be trusted to do anything on purpose.
That distinction is what action memory is really about. It is not the memory of workflows. It is the memory of when a workflow should wake up, when it should not, and what should happen at every step in between.
A customer needs a pricing exception. Everyone may know the account, the conversation, and the business reason. That still does not tell the company who approves the exception, whether legal needs to review it, which system gets updated, whether finance needs a note, who tells the customer, or what happens if the discount crosses a specific threshold like fifteen percent where finance approval becomes mandatory and the deal can no longer close on the same day. The same artifact, the same business reason, and a one-percent change in the number triggers a completely different operating path. None of that lives cleanly in a single system, and most companies rediscover it every quarter.
The first layer of a Company Brain is factual memory: what exists, what happened, where it lives, who owns it, and how it connects. The second layer is interaction memory: why something happened, what people meant, what they debated, and what they left unresolved. Action memory is the third layer, and it remembers how the company moves.
Action memory is also different from the first two layers in an important way: it is partly agentic. Factual memory can sit still and answer questions. Interaction memory can preserve the reasoning that led to a decision. Action memory has to participate by noticing that a condition changed, deciding whether something should happen, choosing the right path, respecting the guardrails, and either acting or asking a human to act. That makes it much closer to the nervous system of the company than to a knowledge base, and it is why agents attach most naturally at this layer.
Most workflow diagrams are polite fiction: they show the official process, not the real one. The documented support flow might say: create ticket, assign owner, resolve issue, update customer. The actual flow might be messier: a customer texts the founder, the founder asks product, product remembers a related bug, engineering fixes it directly, and support updates the ticket later. If you only remember the official workflow, you miss how the company actually operates.
The gap gets larger as companies grow. Early on, people route around process because everyone knows everyone. Later, the routing logic becomes tribal knowledge: this customer needs legal, that customer should go through the CEO, this exception is safe under ten percent but needs finance above that, and this integration always breaks when procurement gets involved. None of that lives cleanly in a single system.
Action memory has to remember the actual path, not just the intended one. I find it useful to split that memory into four parts, because otherwise "workflow" becomes too vague.
Procedural memory is how a process is supposed to work. It covers the known paths for onboarding an enterprise customer, issuing a refund, approving pricing, escalating an incident, handling a security review, and all the other work that companies pretend is more standardized than it is.
Trigger memory is when something should happen. A customer mentions churn risk twice, a support ticket sits unresolved for forty-eight hours, a deal crosses a discount threshold, a renewal is thirty days away, a roadmap commitment becomes late, a metric crosses a line, a promise is made in a meeting, or an agent takes an action that needs human review. Each of these is not just an event. It is a condition that should wake something up.
Execution memory is what actually happened in a specific case. It remembers who approved the exception, which step took too long, what workaround was used, which agent sent the email, who corrected it, what handoff failed, and which system became the source of confusion.
Outcome memory is what happened after the action. The customer may renew, the workaround may create technical debt, the escalation may reduce risk, the agent action may need human correction, or the same issue may come back two weeks later. The result matters because the company should not treat every completed workflow as a successful one.
These four pieces matter because action without memory becomes repetition. The company keeps rediscovering the same exception, rerunning the same escalation, and asking the same people how something is supposed to work. Worse, agents begin to automate the surface process without understanding the lived process underneath it.
This is where the three memory layers come together. An agent with factual memory can find the relevant account, ticket, policy, contract, and document. An agent with interaction memory can understand why the work matters, what was promised, what was debated, and what assumptions are still fragile. An agent with action memory can know when something has changed, what workflow should start, who needs to care, what guardrails apply, and whether it should act or escalate. It can draft the follow-up, create the ticket, request approval, notify the owner, update the CRM, escalate the risk, or deliberately do nothing. That is the difference between an agent that has tools and an agent that can operate inside a company without creating more cleanup work than it saves.
Action memory should function as guardrails. A refund, a customer email, a pricing exception, and a production change should not all be treated the same way just because an agent can technically perform them. Some actions are safe to execute. Some require approval. Some affect money or production. Some look similar to precedent but differ in one detail that changes the risk. The system has to remember the difference between "this is routine" and "this only looks routine."
Timing is the rest of the story. A lot of important work does not start because someone asks a question. It starts because a condition changed. A risk appears, a promise is made, a deadline is approaching, a customer repeats an objection, a blocker appears in a meeting, a metric moves, or an agent takes an action that needs review. Action memory is what lets the company say: when this happens, here is who should care, here is what usually happens next, and here is where the system should be careful. It is the difference between remembering a process and noticing that the process has become relevant.
Roles see this layer differently, more than they see the other two. An IC needs the next step and the context to do it well. A manager needs to see where handoffs are failing and where commitments are stuck behind a single reviewer. The CEO question is the most interesting one and the one nobody else can answer cleanly: where is the company repeatedly failing to turn decisions into action? That is not a dashboard of activity. It is a map of the places where the company loses momentum after it has already decided what matters, where the same operating failure keeps showing up under different names, and where strategy is silently translating into nothing. Most CEOs feel this and cannot point at it. Action memory is what makes it pointable.
The loop closes when actions become memory. If an agent drafts an email, creates a ticket, updates Salesforce, escalates a risk, requests approval, or notifies an owner, the system should remember what happened. A successful action becomes precedent. A failed one becomes risk memory. A human correction becomes a signal. A workflow change becomes part of how the company operates next time.
This is how the Company Brain stops being a better knowledge base and starts becoming an operating system for the company. It remembers what happened, understands why it mattered, knows when a condition has changed, coordinates what should happen next, and learns from the result. Without that loop, action stays separate from memory, and the company keeps paying the same coordination tax. The same exception gets rediscovered. The same escalation gets rerun. The same decision gets reopened because no one remembered the tradeoff that closed it the first time.
Factual memory gives the company a record. Interaction memory gives it organizational reasoning. Action memory gives it operational continuity, plus an agentic surface for execution. Each layer is incomplete without the others. The next question is what kind of memory architecture do these exist on simultaneusly.
—-
Part 1: Why most companies have date but no memory
Part 2: Factual Memory
Part 3: Interaction Memory
At Sentra, where we are building enterprise general intelligence: a shared intelligence/memory layer that sits on all communication channels, knowledge bases and agent traces to understand how everyone in an organization actually works as well as how work actually gets done, constructing a living world model of the entire company in near real time.