Where this came from
This did not start as a theory about agents. It started with a problem I have watched inside enterprises for the last decade of my career.
Organizations lose intelligence constantly: across systems, across teams, and every time someone changes roles or leaves. A strong rep, a veteran solutions architect, an experienced PM or engineer accumulates context over years. They learn what works for this product, within the culture, in this market, against their competitor. Then they move to another team or leave, and that knowledge walks out the door with them. The same is true inside product and engineering orgs. Almost none of it is written down. The tribal knowledge that made the organization good at its job lived in people's heads, and the manual systems built to capture it (the playbooks, enablement decks, and QBRs) mostly failed, because the real intelligence was in the judgment and the propagation to the org.
There is a second loss that happens in real time while everyone is still in their seat. GTM, product, finance, and support each hold a piece of the picture, and the strategy is set once, for the quarter or the year. There is no loop that feeds new data back up, adjusts the strategy, or triggers the next move. The organization keeps acting on last quarter's understanding of itself.
Why agents make this urgent now
These workflows are now being rebuilt with agents, across every one of those functions. That makes closing this loop both important and urgent.
Important, because human judgment still has to be part of this loop. An agent can act correctly and still land on the wrong outcome for reasons no rule captures, and deciding what that means is a person's job, not a score's. Urgent, because of the scale at which agents are about to operate. At that volume, governing the work one action at a time by hand becomes impossible. What is needed is a mechanism that captures the patterns in what agents are doing and gives a person a real way to see them and judge which ones are good and which ones are not. Take the human out without building that mechanism, and the organization stops learning altogether.
The approach
The Organizational Learning Layer is that same learning loop, built into the agentic workflow instead of run by hand. At its center sits the Outcome Context Graph, the memory that automatically captures decisions, actions, outcomes, and corrections, and how they relate. It distinguishes decisions from outcomes, learns what good looks like for a specific organization, and feeds that back into how the agents operate, so the intelligence persists and compounds.
It runs at two altitudes, operating as a single loop. At the operational altitude, a single agent gets better at its task as it accumulates outcomes. At the organizational altitude, what support learns reaches GTM, what the field proves reaches strategy, and what finance sees about churn changes which accounts the agents prioritize. The same captured outcomes feed both levels, and that connection is key. See this claim worked through on one real deal, step by step →
That propagation is not automatic, and it should not be. The function that proves a pattern promotes it; the function that would have to change how it works accepts it, on its own review cadence, the same forums, WBR and MBR reviews, where cross-functional change already gets socialized today. Nobody's workflow changes because another team's system said so. That makes cross-functional learning slower than a fully automated loop would be, and it is the only version of this a real organization would actually run.
Getting one agent to improve at its task is easy, and essential, but it is not where this stops. The harder part is when the workflow improves over time, or what one function learns changes how another function acts. That is what makes an organization smarter over time. As the loop surfaces what predicts right outcomes, it also builds the kind of trust that makes the workflow stick, as the evidence becomes visible.
This is not model fine-tuning, retrieval, or another observability dashboard. Neither the model layer nor the application layer closes the decision-action-outcome-correction loop across an organization's agents and functions. Sharing a solution the moment an agent produces it is belief propagation. Promoting a learning only after outcomes prove it worked, and a human approves it, is organizational learning. See the promotion step itself, running → the trust tiers, the evidence pack, the named-approver gate, and the audit that un-learns a practice when it stops working, each figure produced by a tested engine.
This starts conservative, on purpose. In v1, the system only reads what happened and recommends what to do next. It does not take actions on its own. Later, once a practice has enough evidence behind it, some recommendations can turn into the system acting directly, but not in every case: anything that touches a customer, affects pay, or feeds a financial number still requires a person to approve it, no matter how strong the evidence is. So in practice, a v1 deployment is a recommendation engine first, and only becomes anything more than that later, deliberately. One upside of starting this narrow: because the layer never becomes the only place the learning lives, a company could remove it at any point and keep everything it had already learned.
The architecture, at a conceptual level, is five parts. Capture instruments the execution boundary, the point where an agent's output meets a person, a rule, or a system, so the action and what happened after it are both recorded. The Outcome Context Graph is the living memory that holds decisions, actions, outcomes, and corrections, and the relationships among them. Outcome linkage connects outcomes back to the decisions and actions that preceded them, across enough instances to separate signal from noise; a single outcome proves nothing, the pattern across many is where the learning lives, and this is the hard part, the reason most stacks stop at observability. Governed propagation promotes a validated learning from one team to the organization deliberately, with a human approving what becomes policy, rather than letting it spread unchecked; this is the control point that keeps the loop trustworthy. Agent feedback is where the loop actually closes: once a pattern is promoted, it feeds back into how the agents operate, updated context, reprioritized signals, adjusted scoring, so the same captured outcomes that proved a pattern also become the input that changes what an agent does next.
That loop looks the same for every function, but it does not run on one clock. Zoom into a single decision and three different speeds show up: the agent acting in milliseconds, the engine linking outcomes days or weeks later, and governance reviewing on a cadence measured in weeks or quarters. The boundary between them is where the trust actually gets built.
The market today
The pieces of this exist today, in a scattered manner. Hyperscalers are shipping memory primitives inside their own stacks: Bedrock AgentCore memory, Agent Platform Memory Bank, Oracle's agent memory. A wave of startups (Mem0, Zep, Letta) are building developer memory layers. The closest analogues are still single-purpose: Anthropic's Dreaming reviews past sessions to extract patterns and curate memories within one model; Google created a custom knowledge-and-context graph for a large enterprise seller agent. Fin, formerly Intercom and soon part of Salesforce, resolves over 40 million customer conversations by learning directly from a company's internal content over time, and Velaris markets its own context graph as a living memory of every customer account, both single-surface systems that get one workflow better, not the organization. Databricks Agent Bricks, announced at the June 2026 Data and AI Summit, ships managed memory at the platform level with the weight of its data infrastructure behind it. Newer entrants go further within their slice: Interloom grounds agents in a company's historical resolutions inside single operational workflows, and Engram bakes a team's knowledge directly into model weights. Engram makes the model know your company; the loop makes your company get better. Cisco's Outshift ships CASA, open-source runtime authorization that checks each tool call an agent makes against the intent it started with, and flags or blocks it in real time if it drifts. Each of these approaches the problem from its own surface: model, developer tooling, data platform, or the runtime boundary. What I am building sits above all of them: it takes the outcomes those systems produce, requires enough cases before a pattern counts, and feeds it back so a signal in one function changes how an agent acts in another, with a named person approving the change.
Enterprise workflow platforms have the infrastructure for capturing traces, governing execution, and measuring outcomes across agents. That is the real objection to a neutral layer, and it deserves a direct answer, not a passing mention: a platform that already owns the execution boundary can, in principle, build this. Neutral layers have a mixed history. Most get absorbed once a dominant platform ships the same capability as a feature. A few survive and compound because the substrate they sit on is fragmented by nature, not by accident. Snowflake did not win because platforms lacked data tools; it won because enterprise data was already spread across systems no single application owned, and data gravity mattered more than app adjacency. The same test applies here: does an enterprise's agent activity live inside one platform, or is it already spread across five or more stacks with no shared system of record for what worked? Most enterprises I have worked with run the second kind of environment. That is the argument for a neutral layer, not just an assertion that the window is still open.
One adjacent approach routes to a human the moment an agent gets stuck. That is work I have done by hand. This layer automates it, capturing what worked after the fact and feeding it forward, so the agent needs less intervention over time.
I am starting this in revenue workflows because the value is immediately obvious in dollars, and a wave of new agents is already running there with no layer capturing what happens to their decisions after the fact. Not because the data is cleanest, sales cycles are slower and noisier than support tickets or usage telemetry. But clear value plus urgent risk matters more right now than a statistically ideal dataset. The architecture is meant to generalize past it.
The strategic question
The architectural question the market will resolve over the next 12 to 18 months is whether this becomes platform-native, built into the platform that already holds the context and governance, or a neutral layer that sits across competing platforms and heterogeneous frameworks, because no single platform orchestrates all of an enterprise's agents. I don't think that question is settled yet. Every platform owner assumes their surface wins by default. I am not sure it does, not for an enterprise running five different agent stacks with no single system of record for what actually worked.
There is no organizational learning layer yet. The capture primitives exist. Outcome linkage exists only inside single skills and workflows; governed, cross-functional propagation does not. That is the gap, and the opportunity.
If you are building toward this, I would welcome the conversation.