When Memory Becomes the Operating Model

I have a confession to make about my day-to-day workflow: the primary reason I stick with ChatGPT for pressure-testing business strategy at The CTO Advisor comes down to its persistent memory.

Over months of working together, the platform has learned how I analyze infrastructure markets, how I evaluate vendor claims, and how I structure commercial deliverables. Even when I export those memories as raw text or JSON, seeding that state into a rival platform like Gemini or Claude doesn’t close the gap. The challenge isn’t transferring the memory records. It’s reproducing how another platform’s agent harness retrieves, interprets, assembles context from, and applies them.

That level of friction exists in a solo business.

Now scale that mechanism across an enterprise. Google’s Gemini at Work announcement introduces an architectural question that goes well beyond model selection and agent orchestration.

During the keynote, Google demonstrated Dream Mode learning how an employee works without being explicitly instructed. Gemini inferred the employee’s role, communication preferences, and working habits. In a recurring email workflow, the agent reviewed the employee’s edits and incorporated those observations into subsequent work.

Google described the improvement as compounding.

That’s precisely what makes the architecture compelling. It’s also what makes it difficult to replace.

The system of operational record

An enterprise’s operating model isn’t limited to its documented standard operating procedures (SOPs). It includes how employees recognize exceptions, resolve ambiguity, prioritize competing objectives, and exercise judgment. Much of that knowledge is never written down, yet it’s what distinguishes one company from its competitors.

If a persistent agent delivers on its promise to learn that behavior and apply it to future work, the accumulated memory becomes more than a productivity feature.

It becomes an unofficial system of operational record.

When that record exists primarily inside a proprietary agent harness, the enterprise faces a different kind of switching cost: behavioral lock-in.

This isn’t an entirely new concern. Oliver Wyman’s research on agentic vendor lock-in identifies accumulated agent memory as one of the most consequential sources of switching cost. Among programs at scale, only 23% store most or all of that record in a neutral schema. Identity and security architect Karl McGuinness argues in The Company’s Memory Must Be an Enterprise Record that an agent’s learned knowledge must remain governable and recoverable across suppliers rather than captive to a specific harness. Google’s Dream Mode makes those concerns concrete by showing how operational behavior can be inferred directly through ordinary usage.

Hyperscalers correctly point out that foundation models are swappable. You can swap one large language model (LLM) for another under a unified policy stack. But swapping the model doesn’t swap the agent harness.

If an enterprise attempts to migrate platform runtimes in three years, the challenge isn’t recovering the underlying data. It’s achieving comparable fidelity, reliability, and cost when reproducing years of learned operational behavior on a new platform.

Formal authority vs. practical control

Through the lens of our Decision Authority Placement Model (DAPM), this shift exposes how authority gets quietly reallocated at Layer 2C, the agentic and reasoning plane.

When an enterprise adopts a persistent agent harness, it begins by delegating authority within defined governance boundaries. Administrators control identities, permissions, API gateways, and execution policies.

However, those administrative controls don’t necessarily govern the operational judgment the agent accumulates through procedural and episodic memory.

Architectural dimension	What happens as memory accumulates
Formal authority	Enterprise identity and access management (IAM), policy enforcement, and approval controls remain intact.
Operational judgment	The agent develops increasingly useful representations of how work gets done.
Behavioral portability	Reproducing learned execution patterns on another harness becomes complex and expensive.
Effective authority	The enterprise keeps the right to revoke the service, but may lose the practical ability to replace it without disrupting how decisions get made.

Consider an enterprise whose agents have spent three years learning how purchasing exceptions are handled across dozens of global business units.

The enterprise still holds formal authority. It can disable those agents, revoke their identities, terminate the service, and enforce its formal procurement policies. But doing so could severely disrupt operations, because the organization no longer has an independently executable representation of that accumulated judgment.

That’s where delegated authority risks becoming effectively ceded. Not because the vendor strips away administrative controls, but because the judgment required to operate efficiently has become inseparable from the vendor’s proprietary harness.

The enterprise still has the authority to turn the system off. The question is whether it can afford to.

Observed isn’t authorized

This dynamic creates two distinct architectural risks:

1. The behavioral governance problem: unauthorized promotion of learned habits into operational execution.
2. The architectural dependency problem: the inability to recover and port learned operational capability independently of the harness.

The governance problem comes down to one question:

Who has the explicit authority to convert an observed behavior into an approved business procedure?

Consider an employee who repeatedly overrides a recommended vendor or skips a standard step because of an uncodified commercial relationship or a local workaround. An observing agent may infer that shortcut as an effective procedure. Repetition isn’t authorization. It isn’t compliance, and it isn’t best practice.

An enterprise has to explicitly distinguish between three states of operational knowledge.

Without clear governance separating these states, unvetted employee habits can silently become codified enterprise policy.

Four tests before you commit

Enterprise teams rarely need to build custom LLMs or orchestration frameworks from scratch. They do need to keep authority over their operational judgment.

Before committing to a persistent agent environment, apply four DAPM diagnostic tests:

Governance layer	The test
Authorization boundaries	Does the system require explicit human sign-off before an inferred behavior is promoted into a system-wide autonomous procedure?
State exportability	Can the enterprise export structured procedural and episodic memory, including provenance, approval status, and dependencies, in a format another agent harness can consume?
Behavioral traceability	Can an autonomous agent action be traced directly to the specific episodic memory or inferred policy that influenced the decision?
Memory independence	Can the enterprise independently govern, preserve, and reconstruct operational memory without depending exclusively on the original agent harness?

Who owns what the agent learns?

The industry is standardizing how agents access enterprise systems far faster than it’s establishing how enterprises keep ownership of what those agents learn.

The goal isn’t to resist persistent agent memory. The operational advantages are too compelling to ignore. The goal is making sure that as machines learn how our businesses run, the resulting operational judgment stays an enterprise asset, independent of any single platform harness.