Governed Memory for AI

Two gaps, one missing layer

Large language models are extraordinary and stateless. They process tokens inside a fixed context window and produce output; when a session ends, nothing persists. Separately, as those same models graduate from answering questions to taking actions, a second gap opens: when an AI changes a customer account, issues a refund, or grants access, there is usually no durable, verifiable record of what it did and what authorized it.

These look like different problems. They are the same one. Both are failures of infrastructure around the model, not of the model itself, and both are solved by putting the durable state (what the AI knows, and what it is permitted to do) outside the model and under the user's control.

Context amnesia

For professionals who use AI as a core daily tool, statelessness is a compounding productivity tax. Users spend 10 to 15 minutes per session re-establishing context they have already supplied dozens of times. As one benchmark summarized, LLMs are stateless; they start each interaction without any context or memory, leaving power untapped and insight lost.^[1]

The accountability gap

The moment an agent is allowed to act, a new question blocks every serious deployment: “What did your AI do to my customers' accounts, and who allowed it?” Most agent products answer with a policy page. That is not evidence. Autonomous software that negotiates, refunds, grants access, or edits records needs the equivalent of an employee activity record and an aircraft black box: who authorized the action, what instruction and memory influenced it, which tool was called, and what actually changed.^[4]

The multi-platform compounding effect

Professionals move fluidly between tools. Claude excels at long-context reasoning, GPT has deep integrations, Gemini connects to Google Workspace, and coding assistants such as Cursor, Claude Code, and Codex sit inside the developer toolchain. Every switch resets context. Even if one platform shipped perfect memory, it would not follow the user elsewhere. The problem is structural and cross-platform, so it cannot be solved by any single provider; it has to be solved in a neutral layer the user owns.

This single idea produces two products that share one spine. On the knowledge side, captured context becomes a structured, user-owned memory graph that any AI tool can read. On the action side, that same graph of approved decisions, rules, and permissions becomes the policy an agent must obey before it is allowed to act, and each action it takes is recorded as signed, verifiable evidence.

The memory is not just convenience; it is the governance. What a human has approved into memory is exactly what the agent is permitted to do. That is why Conxt is one company and not two.

Overview

Conxt is a persistent, cross-platform memory layer for AI users. It captures context as you work, classifies it into structured memory, stores it in a user-controlled dashboard, and makes it available in every AI session you open. The model starts knowing who you are, what you have decided, and how you work, every time, on every platform.

Conxt reaches AI tools two ways. A Chrome extension passively captures conversations on Claude, ChatGPT, Gemini, and Microsoft Copilot. An MCP server at mcp.conxt.dev exposes the same memory to tools that speak the Model Context Protocol, including Cursor, Claude Code, Codex, and Perplexity, so the memory is read and written directly inside the developer's workflow rather than only in a browser tab.

The seven memory types

Memory is not monolithic. Different categories of context have different value, shelf life, and retrieval patterns. Conxt classifies all captured memory into seven structured types.

The taxonomy removes noise from the store and ensures retrieval surfaces contextually appropriate memory rather than raw conversation fragments.

How capture works

The extension uses Manifest V3 content scripts to monitor conversation streams on supported platforms. When a sufficient conversational unit is detected, it transmits a session hash and content to the extraction engine, which runs a two-stage pipeline:

Memories are written to Supabase with pgvector embeddings for semantic retrieval alongside structured filtering, and every memory is surfaced in the dashboard for review, approval, and editing before it becomes active. The session hash enables deduplication, so revisiting a conversation does not re-extract it.

Cross-platform injection and ownership

When a user starts a new session, relevant memory is made available to that session, either through the extension or over MCP. The store is platform-neutral and belongs entirely to the user. Memory lives outside any single AI platform, which is the core architectural differentiator and the foundation the governed-action product builds on.

Overview

Conxt Agents lets a company put an AI agent in front of real work (refunds, access changes, data requests) without handing it unchecked authority. The agent does the work; a human approves the decision; the action runs against the company's own system; and a signed receipt is recorded. It is positioned as a governed AI agent, and the durable thing underneath is narrower and stronger: the agent can only act from memory a human approved, and every action leaves a receipt that names why it was permitted.

The governed spine

1. Request arrives→
2. Classified against approved playbooks→
3. Guardrails evaluated→
4. Action proposed→
5. Human approves→
6. Executed→
7. Signed receipt→
8. Audit

Preparation is deliberately side-effect-free: proposing an action changes nothing. Approval tokens are HMAC-signed, bound to the specific action (for example, a specific charge identifier plus subject and parameters), and expire within minutes. Nothing runs without a human approving the exact values, and the record of why it was permitted is produced from the code path, not written by hand.

The policy is in the data

Governance is not buried in code; it lives in the company's own playbooks. Each playbook carries the tools it is allowed to use, the conditions under which it must not act, when it must escalate to a human, and the actions it is prohibited from taking. A playbook that may only read a knowledge base cannot produce a refund button. The engine's classification is a hard gate: security or escalation cases, unmatched requests, and requests missing required information never produce a consequential action. Everything fails closed, and where an action is withheld, the interface says why.

Architecture A: zero standing access

Conxt holds no standing credentials to a customer's systems. To act, it sends a signed, scoped request to an HTTPS endpoint the customer registers and controls. The customer's system performs the change and returns a result; Conxt verifies and audits it.

The result is a security posture a buyer can accept: the most leak-prone credential, the one sitting in a third party's configuration, cannot rewrite policy or reach standing data. A PII-redaction guardrail on the engine keeps customer data out of model output, storage, and logs, except where an identifier is required to resolve the action itself.

The receipt as evidence

Every governed action returns an envelope that names the authorizing playbook, the risk level, the checks the engine actually performed, and the expected result, then records what actually happened from the executing system's own confirmation. At that point the audit trail stops being a log and becomes evidence: a signed token bound to a specific action, a set of checks that each name the step that established them, and a post-hoc confirmation of the change. That is the answer to “what did your AI do, and who allowed it,” delivered as proof rather than a policy page.

The memory graph is the moat, not the agent. The approved memory that governs an action is the same structured graph that syncs across a user's tools over MCP. Three consequences follow:

Shared components

Authentication and identity

Authentication uses Supabase Auth, shared across both products. The engine verifies a Supabase session token or a scoped Conxt API key on every call, so the extension and MCP clients never touch the database directly. Inbound system requests use a separate class of team-owned keys that can submit work and nothing else, isolating the most exposed credential from anything that could rewrite policy.

Privacy and security

Individual memory is useful; shared memory is transformative. When a team works with AI, the context problem multiplies across every member, and knowledge is locked in individual histories no one else can reach. Conxt team workspaces provide a shared memory feed the whole team contributes to and draws from.

The highest-value case is onboarding. A new teammate arrives with the accumulated AI context of the whole team: the decisions made, tools chosen, rules established, and workflows developed. On the governance side, the same shared approval and audit model means a team can see not only what the agent knows but what it has done.

Memory and context

Conxt's position is cross-platform reach (extension plus MCP), a structured seven-type taxonomy that is queryable and human-readable rather than opaque embeddings, and a human-in-the-loop review step that keeps the user in control of what the model knows. The infrastructure players are converging on usable interfaces, so the durable edge is the pairing of neutral memory with governed action, not the UI alone.

Agents and governance

On the action side, the field is crowded with agent platforms and “agentic OS” products (for example, Lyzr) that orchestrate large fleets of agents, usually deployed in the customer's cloud with human-in-the-loop controls as a feature. Conxt does not compete on fleet size or orchestration. It competes on a narrower, sharper claim: a governed approval with a receipt that is evidence, built on an architecture where the vendor holds no standing access to the customer's systems. The win is not being another agent; it is being the layer that makes any agent's actions safe to trust and easy to audit.

Memory: AI-native professionals

The primary market for the memory layer is professionals who use AI as a core daily tool, and especially the heavy users who move across multiple AI platforms. This is a self-selecting, high-intent segment: developers, product managers, researchers, founders, and consultants who already feel the re-context tax every day.

Governance: AI-native teams and regulated functions

The market for governed action is any organization that wants agents to take real actions but must answer for them. “40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% in 2025” (Gartner).^[8] Those agents fail, or never ship, without memory and without accountability. The sharpest early wedges are functions where a human already approves the action today and the result needs proof: support money fixes (refunds, credits, restoring access), IT access grants and revocations, and privacy requests (export, deletion, account lock), where the receipt is the compliance record.

Memory pricing is positioned so the productivity recovered from eliminating context re-establishment pays for the subscription in the first week. Agent pricing is positioned against the cost and risk of the actions the agent governs, not against seats. Full plan details for the memory layer are on the pricing page.

Shipped

Near term

Medium term

The models are extraordinary; the infrastructure around them has not kept pace. Every session starting from zero is a tax on the productivity AI is supposed to unlock, and every action an agent takes without a verifiable record is a risk no serious organization will accept. Both are the same gap: durable state that should live outside the model and belong to the user.

Conxt builds that layer twice over. The memory follows the user across every AI tool, and the governance makes the agent's actions safe to trust and simple to prove. The models will keep improving. Conxt builds the memory that makes that intelligence permanent, and the governance that makes it accountable.

© 2026 Conxt / KPZG LLC. All rights reserved. conxt.dev · conxtagents.com