Name things once
Define entity types, fields, and relationships your agents can reuse. Declared field aliases let incoming names resolve to the same field.
01 / Ontology
Give every agent the same model.
Define what a customer, project, or case means in your application. Share field names and relationship types across writers, then choose which constraints must refuse an update.
A project means the same thing to every agent.
- Class
- Project
- Allowed status values
- planned · active · completed
- Owner
- A relationship to a Person
- Strict mode
- Refuse undeclared fields and invalid values
In practice
Declare a rule once. Every writer meets it.
The schema lives in the database, not in a prompt. Whichever agent proposes an update, the same definition decides what is accepted, and the result says why.
- 01
ontology_defineGive Customer two fields. plan accepts three values and is enforced; the class itself stays open to new fields.
Call{ "class": "Customer", "predicates": [ { "name": "city", "valueType": "string" }, { "name": "plan", "valueType": "string", "allowedValues": ["starter", "growth", "scale"], "enforced": true } ] }ResultOntology class **Customer** defined. Predicates: 2 created, 0 updated, 0 unchanged. created: city, plan Relation types: 0 created, 0 already declared. Schema revision: 1a95679e9f73380cd0c7a0e8f31572b4 - 02
memory_insertThe CRM sync has already recorded plan: growth. A sales call proposes a plan the schema does not allow, so nothing is written and the receipt names the rule.
Call{ "entityType": "Customer", "entityRef": "customer:crm_1042", "data": { "plan": "enterprise" }, "source": "sales-call", "confidence": 0.6 }ResultEntity: customer:crm_1042 - (nothing written) NOT WRITTEN: ! plan: Value "enterprise" is outside the declared domain of "plan"
Calls and results from the ConceptMem MCP tools on a new database, shown as the agent receives them.
Built into the workflow
A shared vocabulary. Boundaries you choose.
Choose your boundaries
Start with open classes, close a class with strict mode, or enforce one field’s type and allowed values. Apply stronger constraints where your workflow needs them.
Set policy where it matters
Set class defaults and field overrides for update and conflict decisions. Related classes inherit definitions and policy from their parents.
Evolve the model with a preview.
Schema changes are proposals too. Preview a change against the complete model, inspect warnings about existing data, and use a revision check to prevent stale updates.
See the setup workflowWhat does the ontology actually control?
The ontology is your shared model: entity types (classes), fields (predicates), value types, cardinality, and typed relationships. Enforcement depends on the constraints you choose. Open classes allow additional fields; strict classes refuse undeclared fields and non-conforming values or relationships.
What is the difference between an open and a strict class?
An open class accepts undeclared fields. Type, allowed-value, and relationship mismatches are reported without blocking unless the field is enforced. A strict class refuses those mismatches and undeclared fields. Strictness is inherited. Missing required fields are advisory in both modes.
Can I enforce one field without closing the whole class?
Yes. Marking a single predicate as enforced makes its value type and allowed values binding even on an open class, without requiring every other field on that class to be declared.
How does cardinality change what gets stored?
A single-value field holds one current value, which can itself be an array. A multi-value field stores each array element as a separate fact and deduplicates current values. An ordered list also records positions; submitting an array replaces the whole list, and an empty array clears it.
Do I have to design the whole ontology up front?
No. Start with one type and a few fields, or explicitly apply the starter vocabulary in free mode. You can later adopt a template in model-driven mode and control whether agents may change the schema. Human schema administration requires authenticated user access.
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.