Context-aware memory. Versioned skill distribution.
Capture a thought in one project — a decision, a preference, running context — and find it again weeks later by what you meant, not the words you typed, from a different repo or a teammate's own AI client entirely. Skills work the same way: write a working practice once, version it, and every tool your team or enterprise org runs — Claude Code, Claude Desktop, or anything else speaking MCP — pulls that same version.
Built on DFENS Mind, our MCP server. By DFENS AI Ltd, the team behind dfens.ai.
// context id resolved earlier via list_contexts() capture_thought( context: "proj-9f2…", content: "Retry Odoo checkout on 503, not just timeout", topics: ["billing", "odoo"] ) // → saved. three weeks later, different repo: search_thoughts( context: "proj-9f2…", query: "why does checkout retry" ) // → semantic match, same thought, no re-explaining
Every project, one shared memory — not one silo per repo.
Claude, Claude Code, or any MCP-speaking harness.
Data residency: EU, US, and APAC.
Federated sign-in, no shared secrets.
Remembering isn't the hard part. Sharing it is.
Your AI tools already keep context inside a session — some carry it across sessions now too. What none of them do is hand it to a teammate. So the same decision gets re-explained, the same working practice gets reinvented, person by person, project by project.
Individual heroics
Whoever figured it out first becomes the only one who knows it. It doesn't reach a teammate — even one sitting next to you, even using the exact same AI tool.
Repo-scoped memory
Context a session builds up still lives and dies with that session, or that repo. Move to a different project and you're explaining it all again — even to yourself.
Vendor silos
Standardize on one AI harness and every other one falls behind — or you hand-copy the same instructions into each tool's own format.
Contexts are the unit of memory.
Every thought lives inside a context — an opaque id, not a name you
can guess. A context belongs to one organization and is either open to every
member, or restricted to an explicit grant. Every person also gets one private
personal context automatically.
List your contexts
list_contexts() returns every context you can access — id, name,
and description. It's the only way to get a valid context id;
there's no default and no way to guess one.
Capture and recall
capture_thought saves a note. search_thoughts finds it
again by meaning, not just keywords — embedded with Vertex AI's
gemini-embedding-001. browse_recent and
view_stats round out day-to-day use.
Org membership gates access
Every context belongs to an org. org-visibility contexts are open
to every member automatically; restricted ones need an explicit
grant. Owners and admins manage both.
A shared memory, built for teams — not just one session.
Semantic recall
Search by meaning, not exact phrasing. A thought captured about "checkout retries" surfaces when you later ask why Odoo keeps retrying.
- capture_thought / search_thoughts / browse_recent
- update_thought / delete_thought / view_stats
Real multi-tenancy
One shared deployment serving many organizations, walled off by row-level ownership in Postgres — from a two-person team to an enterprise org, not a separate deployment to run per company.
- owner / admin / member roles
- org-wide or per-user restricted contexts
Skills across harnesses
Write a working practice once and every AI tool your team runs pulls the same version — instead of copying instructions into each harness's own format by hand. Works from a human session or an org API key, so an unattended harness can pull skills on its own too.
- Versioned, with bundled scripts/references/assets
- Issue and revoke API keys for more harnesses yourself, from the portal or the MCP client
Data source connectors — Enterprise
Connect data sources, including Google Drive, SharePoint and OneDrive,
and keep them current in the background. Their content becomes
searchable through the same search_thoughts call, each hit
linking back to its source — no one has to remember to write it
down.
- Google shared drives and folders; SharePoint sites (every document library) and OneDrive
- Each source maps to one context, so that context's existing access rules decide who can search it
- Optional AI distillation turns source content into focused notes, billed from prepaid credits
Everything a session can call, in one table.
A thin MCP layer over Postgres and pgvector. No hidden defaults: every tool but
list_contexts requires an explicit context id.
| Tool | Purpose |
|---|---|
list_contexts() | Every context you can access — the only way to get a valid id. |
capture_thought | Save a new thought, with optional topics and people. |
search_thoughts | Semantic search within a context. |
browse_recent | List recent thoughts, optionally filtered by topic. |
view_stats | Total count, top topics, most recent thought. |
update_thought / delete_thought | Revise or remove an existing thought. |
buy_seats / start_checkout / subscription_status | Manage your plan and seats from the MCP client, via a hosted checkout. Owner/admin only. |
create_skill / get_skill / list_skills | Versioned, shared working practices scoped to a context — usable from a human session or an org API key. |
Org-management tools (membership, roles, context grants) sit behind
owner/admin role checks. Thoughts synced from Drive or SharePoint carry a
source object (provider, link, version) and are read-only to
update_thought/delete_thought — the connector owns that content. Full reference: documentation.
One memory server, any MCP client.
Claude.ai, Claude Desktop, and the Claude API — anywhere Claude can reach a remote MCP server.
Add it under mcpServers in your project config; every session
gets the same shared memory, no per-repo setup.
Streamable HTTP, standard OAuth 2.1 + PKCE. No proprietary SDK — if it speaks MCP, it can read and write here.
Federated sign-in. Row-level isolation. No shared secrets.
- Federated OIDC sign-in. Google, Okta, Microsoft Entra, or a self-hosted
identity provider — any standards-compliant issuer works via
.well-known/openid-configurationdiscovery. Enterprise orgs can connect their own provider themselves from the portal, and email/password sign-in is available where no provider is mapped. - Our own OAuth 2.1 authorization server. Dynamic client registration and the standard authorization-code + PKCE flow, minting RS256-signed JWTs as the access/refresh tokens clients actually use.
- Postgres + pgvector, row-level tenancy. Every context and thought
carries an
org_id; access checks run on every call. - Data residency.
europe-west1,us-central1,asia-northeast1— set per organization at creation. Embeddings and AI distillation run in your org's region too.
// _require_access, server.py bearer → email (RS256 JWT, verified) check → org member? yes check → context restricted? → grant on file? yes // no membership or grant: forbidden
Start free on Individual.
Sign in through the customer portal and create your organization — Individual is active immediately, no card needed. Ready for a team? The same portal upgrades you to Team through an Odoo-hosted checkout; we never see your card. Prefer the API? Two plain HTTP calls do the same bootstrap — see the full walkthrough on documentation.
hello@integratedai.co.uk