Notifications
Clear all
Topic starter
06/06/2026 11:29 am
TL;DR: AI tools that keep session state local create brittle, non-portable context, so outages, device changes, and provider switches can erase working knowledge and disrupt multi-agent workflows, according to WorkOS. The governance lesson is that AI context now behaves like an identity asset: if it is not externalized, it is neither durable nor governable.
NHIMG editorial — based on content published by WorkOS: How to preserve your AI context across devices, outages, and model providers
By the numbers:
- MiniMax M2.5 costs 20x less than Claude Opus for some use cases, showing how routing choices affect operating cost.
Questions worth separating out
Q: How should teams preserve AI context across devices and model providers?
A: Store project knowledge, task state, and agent instructions in durable systems such as markdown files, git repos, and governed task platforms instead of keeping them inside chat sessions.
Q: Why does local AI session state create governance risk?
A: Local session state is risky because it is not portable, not reviewable, and not recoverable across tools or devices.
Q: What do security teams get wrong about AI memory and context?
A: Teams often assume built-in memory is equivalent to managed knowledge, but it is usually just product-specific storage.
Practitioner guidance
- Move operational context into durable files and repos Store project notes, decisions, and instructions in markdown files under version control so they can be reused across tools and restored after outages.
- Treat MCP connections as governed access paths Review every MCP server as a connector with read and write authority over context stores, then scope permissions to the minimum needed for the task.
- Separate model choice from source-of-truth storage Keep task state, knowledge, and automation inputs in systems you control, then let routing layers or different clients consume that state.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for Obsidian, Linear, git, and MCP-connected workflows
- Example repository structures for CLAUDE.md, AGENTS.md, and custom agent skills
- Provider failover configuration through OpenRouter and other routing layers
- Practical examples of switching clients without losing project context
👉 Read WorkOS's guide to preserving AI context across devices and providers →
AI context portability: what it means for agents and IAM teams?
Explore further
06/06/2026 12:18 pm
Context portability is now an identity governance problem, not just a productivity preference. When AI work depends on local session state, the organisation has no durable control over what was seen, edited, or carried forward. That creates a governance gap across auditability, recoverability, and delegation because the context is trapped inside a single client. Practitioners should treat context as a managed asset, not a chat transcript.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: What should organisations do when AI workflows depend on multiple tools?
A: Define one source of truth for context, then allow each tool to read and write only through approved connectors. That reduces drift between agents, keeps task state aligned, and prevents a single client from becoming the hidden owner of the organisation's AI working memory.
👉 Read our full editorial: AI context portability is becoming a core identity governance issue
