ConceptMemGoverned State Database
Sign inStart free

For builders

Keep your agents on the same record.

Let a support agent propose a customer update and an operations agent read the accepted result. Connect through hosted REST or MCP, with one model, one set of policies, and a shared change history.

Start freeSee an example
Shared customer contextExample

A preference learned in support is ready for the next task.

Support agent
Proposes email as the preferred channel for customer:crm_1042.
ConceptMem
Consolidates the update under workspace policy.
Operations agent
Reads the accepted channel before contacting the customer.
Your team
Inspects the source and change history in the console.
Illustrative integration. Agents use the workspace connection and credentials you configure.

In practice

One agent writes. The next reads what was accepted.

Each agent connects with its own credentials and calls the same tools. What one agent’s update changed, the next agent reads as current facts, along with the source and the agent that recorded each one.

  1. 01memory_insert

    At 10:32 the CRM sync job sends its batch as a write plan with an idempotency key. The observations commit one at a time, in order, and each gets its own receipt.

    Call
    {
  "idempotencyKey": "crm-sync-2026-09-13T10:32",
  "source": "crm-sync",
  "observations": [
    {
      "entityType": "Customer",
      "entityRef": "customer:crm_1042",
      "data": { "city": "Berlin", "plan": "growth" }
    },
    {
      "entityType": "Customer",
      "entityRef": "customer:crm_1043",
      "data": { "city": "Porto", "plan": "starter" }
    }
  ]
}
    Result
    Entity: customer:crm_1042
  - Created Customer "customer:crm_1042"
  - Asserted "city" = "Berlin"
  - Asserted "plan" = "growth"

Entity: customer:crm_1043
  - Created Customer "customer:crm_1043"
  - Asserted "city" = "Porto"
  - Asserted "plan" = "starter"
  2. 02memory_operation

    If the job loses that response, it does not have to guess. It asks for the receipt by the same key and learns that both observations committed, so it sends nothing twice.

    Call
    {
  "idempotencyKey": "crm-sync-2026-09-13T10:32",
  "profile": "summary-v1"
}
    Result · shortened
    {
  "ok": true,
  "operation": {
    "id": "312bfc8b-7186-458f-9b1a-f63cc0d4d88d",
    "status": "complete",
    "completed": 2,
    "total": 2
  },
  "receipt": {
    "profile": "summary-v1",
    "totals": {
      "operations": { "create_entity": 2, "assert_fact": 4 },
      "skipped": 0,
      "violations": 0,
      "blockingViolations": 0,
      "pendingReview": 0
    }
  }
}
  3. 03memory_insert

    At 11:45 a support agent, on its own connection, learns the customer moved to Lisbon and prefers email. Lisbon supersedes the city the sync recorded.

    Call
    {
  "entityType": "Customer",
  "entityRef": "customer:crm_1042",
  "data": { "city": "Lisbon", "preferred_channel": "email" },
  "source": "support-thread",
  "confidence": 0.97
}
    Result
    Entity: customer:crm_1042
  - Superseded "city": "Berlin" → "Lisbon"
  - Asserted "preferred_channel" = "email"
  4. 04memory_get

    Before contacting the customer, an operations agent reads the record. It gets the accepted values, and each fact points to the source and agent that recorded it.

    Call
    {
  "entity": "customer:crm_1042",
  "profile": "compact-v2",
  "evidence": "summary"
}
    Result · shortened
    {
  "profile": "compact-v2",
  "results": [
    {
      "status": "found",
      "entity": { "canonicalId": "customer:crm_1042", "entityType": "Customer" },
      "facts": [
        { "predicate": "city", "value": "Lisbon", "evidence": { "sourceRefs": ["s1"] } },
        { "predicate": "plan", "value": "growth", "evidence": { "sourceRefs": ["s2"] } },
        {
          "predicate": "preferred_channel",
          "value": "email",
          "evidence": { "sourceRefs": ["s1"] }
        }
      ]
    }
  ],
  "sources": {
    "s1": {
      "source": "support-thread",
      "actor": "support-agent",
      "confidence": 0.97,
      "timestamp": "2026-09-13T11:45:00.000Z"
    },
    "s2": {
      "source": "crm-sync",
      "actor": "crm-sync",
      "confidence": 0.9,
      "timestamp": "2026-09-13T10:32:00.000Z"
    }
  }
}

Calls and results from the ConceptMem MCP tools on a new database, one connection per agent. The service sets actor from the credential behind each connection, never from the call; here each connection is named after its agent. preferred_channel is declared with three allowed values in this example’s schema.

Built into the workflow

Connect the way your application works.

01

TypeScript SDK · preview

Explore ConceptmemClient and typed contracts for observations, queries, and write results. Public npm publication is pending.

02

Hosted REST API

Submit structured observations and query current records from your application using workspace credentials.

03

Hosted MCP

Give a compatible client tools to read context, propose updates, and inspect outcomes over Streamable HTTP.

Propose an update. Read the result. Trace the change.

Follow the MCP guide or explore the TypeScript preview below. The example uses a fresh database, a stable customer reference, and the default policy. Structured observations can be consolidated without hosted AI.

mcp.config.json
{
  "mcpServers": {
    "conceptmem": {
      "url": "YOUR_WORKSPACE_MCP_ENDPOINT",
      "headers": {
        "Authorization": "Bearer YOUR_WORKSPACE_KEY"
      }
    }
  }
}

Use your workspace endpoint and access key from Connections. The MCP guide walks through proposing an update, reading the accepted record, and inspecting its history.

Read the MCP guide

Your agent proposes. The service governs.

Your integration supplies the observation and its provenance. ConceptMem resolves the entity, checks the ontology, and applies policy inside the managed service. Inspect the result before treating an update as accepted.

Read the integration documentation

Common questions

Agent integration, answered.

Didn’t find your answer?Ask the team Read the documentation
How does my application connect?

Use the hosted REST API from application code or connect a compatible client to the hosted MCP endpoint. Create workspace credentials and follow the Connections guide. The TypeScript SDK and public types are in preview; public npm publication is pending.

Do agent writes follow the same rules as console writes?

Yes. Every observation, regardless of the client it came from, passes through consolidation with the same ontology checks, policy resolution, and provenance requirement.

Can several agents share one memory?

Yes. Authorized agents in the same workspace can propose updates and query shared current records. Use stable source-system IDs and decide which source owns each field. Your integration maps and submits the data; automatic identity merging and CRM synchronization are not provided.

How do I know whether a write actually landed?

Inspect the write result: applied operations, skipped writes, violations, and any pending review. Request success alone does not mean every field was applied. A skipped field stays out of the update, and a held proposal needs a review decision.

Keep exploring

Explore how the record works.

07 — MCP

MCP

Give your MCP client tools to query records and propose updates.

Explore MCP 01 — Ontology

Ontology

Define shared entities, fields, and relationships, with constraints you choose.

Explore Ontology 02 — Consolidation

Consolidation

Keep records current as new information repeats or changes existing facts.

Explore Consolidation

Start with one shared record

Give your next agent
the current record.

Create a database on the free plan, connect an agent over MCP or REST, and propose your first update.

Start free See how it works