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 core. On the knowledge side, captured context becomes a structured, user-owned memory that any AI tool can read. On the action side, a company's playbooks, rules and permissions are governed memory too: proposed, approved by a person and versioned, and an agent must stay inside them before it is allowed to act. Each action it takes is recorded as signed, verifiable evidence.

The memory is not just convenience; it is the governance. What a person approved 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 three ways. A Chrome extension passively captures conversations on Claude, ChatGPT, Gemini, and Grok. An MCP server at mcp.conxt.dev exposes the same memory to tools that speak the Model Context Protocol, including Claude, Cursor, Claude Code, Codex, and Windsurf, so the memory is read and written directly inside the developer's workflow rather than only in a browser tab. And a memory plugin, listed in the Hermes plugin catalog, lets several Hermes agents share one memory, each memory attributed to the agent that wrote it.

Each tool connects with its own key, so a user can see which tool read which memory and switch one tool off without touching the others.

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. A personal memory is usable straight away and can be edited, archived or deleted at any time from the dashboard. A memory saved to a team waits in a review queue until a person approves it, so nothing reaches a whole team's AI sessions unreviewed. 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

conxtagents builds and runs agents that do a company's real operational work: cut the release branch, give a new hire access, pay an approved vendor invoice, run the weekly check, triage an incident, issue a refund. The agent is the product; control is how it is built. Every action follows the playbook the company wrote, is approved before it runs, is checked against the real system afterwards, and leaves a receipt naming the playbook that allowed it and the checks it passed.

What the agents do is chosen by the company's playbooks, not built into the product. A company can run several specialised agents (a billing agent, an access agent, a deploy agent), each with its own playbooks, connections and owners, behind one front door: a request arrives once and is routed to the agent whose playbook covers it, or held for a person when none or several do.

The governed spine

1. Request arrives→
2. Matched to an approved playbook→
3. Guardrails evaluated→
4. Action proposed→
5. Approved (a person, or an earned policy)→
6. Executed→
7. Checked against the system→
8. Signed receipt

Preparation is deliberately side-effect-free: proposing an action changes nothing. Approval tokens are HMAC-signed, bound to the specific action and its exact values, and expire within minutes. The record of why an action was permitted is produced from the code path, not written by hand.

Autonomy is earned, per action

Every action starts as “ask a person”. An action earns the right to run on its own only when the owner allows it and its own track record stays clean, and it loses that right after any run that is declined or cannot be confirmed. High-risk actions can stay on “always ask” for good. Either way the receipt names who or what approved the action: a named person, or the owner's standing policy and the record that earned it.

The policy is in the data

Governance is not buried in code; it lives in the company's own playbooks: the steps, the tools each may use, the values and limits, when to stop, and when to hand to a person. A playbook that may only read a knowledge base cannot produce a refund button. Unmatched requests, escalation cases and requests missing required information never produce a consequential action. Everything fails closed, and where an action is withheld, the interface says why.

The people who know the work own the playbooks, and they do not start from a blank page. The agent drafts a first playbook from a connected system's tools, drafts new ones from requests no playbook covered, and drafts the step plan; a person reviews and approves every draft before it governs anything.

How work arrives

Requests come from the company's own systems, by email, from a person in the workspace, or from another AI agent over MCP. Every route goes through the same door, so a request from an outside agent is matched, approved and receipted exactly like one from a person.

No standing access to the customer's data

Conxt never holds access to a customer's database. To act, it calls a connection the customer registers and controls: an HTTPS endpoint, or the customer's own MCP server. The customer's system performs the change and returns a result; Conxt reads the change back, verifies it, 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, an OAuth sign-in from an MCP client, or a scoped Conxt API key (one per tool, revocable on its own) 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. Shared memory is reviewed before it is shared: a team memory waits for a person to approve it, and the dashboard shows which tool read it afterwards.

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. conxtagents does not compete on fleet size or orchestration. It competes on agents a company can actually hand real work to: they act only inside the company's own playbooks, earn autonomy one action at a time, never hold access to the customer's data, and prove every action with a receipt that is evidence rather than a log line.

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.

Agents: companies handing over routine operational work

The market for conxtagents is any company that wants agents to do real work in its systems but must answer for what they do. Gartner predicted that 40% of enterprise applications would feature task-specific AI agents by the end of 2026, up from less than 5% in 2025.^[8] Those agents stall, or never ship, without control and without proof. The sharpest early uses are routine work where a person already approves each action today and the result needs a record: releases and deploys, access grants and revocations, vendor payments, recurring checks, incident triage, and refunds and order changes.

Memory pricing is positioned so the productivity recovered from eliminating context re-establishment pays for the subscription in the first week. Agent plans are priced by how many agents a company runs, not by seats: start with one agent on one workflow and add more as it earns trust. 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 conxtagents' agents do a company's real work inside its rules and prove every action they take. The models will keep improving. Conxt builds the memory that makes that intelligence permanent, and the agents that make it accountable.

Version 2.1, October 2026. Status and roadmap are accurate as of this date and may change. © 2026 Conxt / KPZG LLC. conxt.dev · conxtagents.com