Memory Lock-In: How Proprietary Harnesses Are Capturing Your AI Governance
You've heard of vendor lock-in. You know it from databases, from cloud infrastructure, from SaaS contract cycles. Memory lock-in in AI governance is the same mechanism. Most procurement teams haven't named it yet.
What a Harness Is
The model is the engine. The harness is everything else — memory retrieval, tool dispatch, state routing, retry logic, identity management, and context window assembly.
What the harness controls:
- Memory retrieval: which prior conversations surface in context
- Tool dispatch: what external systems the agent can invoke
- State routing: how conversation state persists across requests
- Retry logic: how the agent recovers from model failures
- Identity & access: what user, tenant, or security context frames the response
When you ask an AI agent what it remembers about your last conversation, the answer comes from the harness. When you ask it not to surface confidential information in its responses, the enforcement mechanism — if it exists — lives in the harness.
"Asking to plug memory into an agent harness is like asking to plug driving into a car." — Sarah Wooders, co-founder of Letta
Memory is not a feature you add to an agent. It's constitutive of what the agent is. Without memory, there is no continuity, no context, no behavioral pattern to govern.
Most enterprise conversations about AI adoption center on model selection — GPT-4 versus Claude versus Gemini. The harness architecture question rarely appears in procurement reviews or vendor due diligence checklists. That's the gap where lock-in enters — quietly, before anyone has named it as a risk.
Why Governance Lives in the Harness
Governance is behavior under constraints. It isn't a document — it's the set of mechanisms that determine what an agent does, and doesn't do, at runtime.
If the harness controls memory, context retrieval, tool access, and state routing — the harness is where governance either lives or doesn't.
Governance constraints the harness enforces:
- PII masking: filtering personally identifiable information from retrieval results
- Tool access control: which systems an agent can invoke by user role
- Context boundaries: preventing cross-tenant or cross-project memory leakage
- Output constraints: rules that shape what the model can say before response generation
- Audit logging: tracking what the agent accessed and why
- Rate limiting & quotas: preventing resource abuse or cost overruns
You can write a policy that says "agents must not surface personally identifiable information in customer-facing responses." That policy is meaningful only if it's encoded in the harness: as a retrieval filter, a context-assembly rule, or an output constraint.
If the harness has no enforcement mechanism for that requirement, the model will surface PII whenever it appears in retrieved context. Policy documents do not enforce themselves.
This is not a theoretical concern. It's the reason data processing agreements require technical controls, not just contractual ones. AI governance requires the same standard: controls at the layer that actually shapes behavior, not documentation that describes the behavior you'd like to see.
The Proprietary Harness Problem
LangGraph, LangChain, and similar orchestration stacks are extraordinary tools — and they are vendor relationships, not owned infrastructure. This is not a criticism. It's a structural description that most organizations have not explicitly processed as a governance decision.
What proprietary stacks concentrate:
- LangChain: memory store, tool routing, state persistence
- LangGraph: execution flow control, agentic loops, decision branching
- Replicate/Modal: compute, model inference, output caching
- Anthropic Console: memory, tool definitions, system prompt versioning
In each case: capability lives inside the vendor's infrastructure. That's fine — until governance does too.
When your governance substrate lives in a vendor's managed memory store and routing layer, you've made a bet:
- Their governance model stays aligned with yours
- Their pricing remains viable for enterprise scale
- Their ownership doesn't change unexpectedly
Most enterprise software relationships carry that bet implicitly.
What's different with AI harnesses is the governance surface. The harness doesn't just store data — it shapes behavior. That makes the alignment bet higher-stakes than any database vendor.
Harrison Chase, CEO of LangChain , titled his April 2026 post plainly:
"If you don't own your harness, you don't own your memory."
This is an acknowledgment that proprietary harness architecture is intentional — not accidental. The question isn't whether proprietary harnesses exist. The question is whether you've evaluated yours as a governance decision.
The Acquisition Scenario
In early March 2026, Meta acquired Moltbook, an AI agent orchestration platform. Within days, the Terms of Service changed.
What shifted after acquisition:
- Memory ownership: from shared to user-solely-responsible
- Liability model: from partial platform responsibility to complete user responsibility
- Enforcement: ToS updated unilaterally, effective immediately
- Retroactivity: changes applied to all existing deployments without renegotiation
The change was not subtle. In the updated Terms, the following clause appeared in bold, all-caps:
"AI AGENTS ARE NOT GRANTED ANY LEGAL ELIGIBILITY… YOU AGREE THAT YOU ARE SOLELY RESPONSIBLE FOR YOUR AI AGENTS."
The clause was reported by Times of India on March 18, 2026 . The liability that had been at least partially shared was now, retroactively and unilaterally, entirely yours.
The point is not that Meta acted illegally — they probably didn't. Platforms update Terms of Service. The point is that this clause existed to be enforced, and its insertion was unilateral and retroactive.
Any proprietary harness vendor can insert equivalent language. The risk isn't that they will. The risk is that you have no structural defense if they do — because your governance substrate, your memory store, your behavioral rules, live in infrastructure you don't control.
The AGENTS.md Open Standard
The structural response to proprietary lock-in is an open governance substrate. Instructions, constraints, and behavioral rules exist as plain-text files you version-control — not as configuration inside a vendor's platform.
LangChain CEO Harrison Chase validated this framing in his April 2026 post from inside the orchestration ecosystem. The argument isn't that proprietary harnesses are wrong. It's that the choice of harness architecture is a governance decision — and that organizations need to make it deliberately, not by default.
Open governance substrate characteristics:
- Portability: governance constraints port to any stack without rebuilding
- Version control: behavioral rules live in git, not vendor dashboards
- Auditability: every governance change is a committed diff
- No vendor veto: changes don't require vendor approval
- Interoperability: multiple harnesses can implement the same governance file
AGENTS.md is a pattern, not a product. Any team can implement it without adoption of any particular platform or commercial relationship.
An open-format governance file means no vendor can unilaterally modify the rules. You can port your governance constraints — your behavioral rules, your memory architecture, your access controls — to a different stack without rebuilding from scratch. This is not a new idea. It's the same approach taken with open-source databases and open container formats.
How to Audit Your Current Exposure
Audit your harness vendor exposure before an acquisition announcement makes it urgent:
- Where does your agent's memory live — in a vendor's hosted memory store, or in infrastructure you control?
- If your harness vendor updated their ToS tomorrow, would you know within 24 hours — and would you know what it means?
- Can you port your governance constraints — your rules, your memory — to a different stack without rebuilding?
- Does your current AI governance documentation describe harness-layer behavior, or only model-layer behavior?
- Who owns harness vendor due diligence the way someone owns data processor agreements?
These aren't trick questions. They're the same questions a responsible infrastructure team asks about any vendor with access to sensitive data. The framing just hasn't caught up — and that's exactly when exposure compounds.
This is the second piece in the series on AI governance as infrastructure. Part 1 established why governance is an architecture problem, not a compliance checkbox. Next explores what substrate-level sovereignty looks like in practice — and the open-source implementation that emerged from field conditions where ungoverned behavior wasn't an option.
Follow conor on LinkedIn for the live thread.
About the author: conor is the founder of AccessiTech and a practitioner in AI governance methodology, with prior humanitarian deployments including Gisida, UNICEF, and OCHA.