Service-Scoped Memory
Configure service-scoped memory dimensions, opt eligible conversations into processing, and verify versioned observations and views before using them.
Service-scoped memory turns eligible completed sessions into source-linked observations, dimension views, and a combined model. It is an optional processing path identified by workspace, service, and an application-supplied memoryid. Each conversation contributes to one memory subject; the pipeline does not aggregate memory for multiple people in the same conversation.
Before creating a dimension, confirm that memory processing and an authorized reader are provisioned for your application. Dimensions define what to extract; using the results in later conversations requires a reader tool, as described below. This path is separate from existing person-enrichment memory and does not migrate it. See Memory.
Prerequisites
A configured service and a credential with
Service.updatepermission in its workspace.Provisioned memory processing and an agreed reader for its outputs. Coordinate any transition from existing memory processing rather than running overlapping paths unintentionally.
A stable application mapping between the human speaking and the memory identifier. This memory describes the speaker; an operator discussing a patient does not make it the patient's memory.
A declared string context key named exactly
memoryid, supplied when the conversation starts.
memoryid is application input, not identity verification or authorization. Scope access in the application and reader; do not let an untrusted caller select another person's memory.
Create or Revise a Dimension
Define a dimension around information that changes how a later interaction should be handled. For example, describe communication preferences and changes to them instead of asking for a generic transcript summary.
API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.
Successful Response
No content
Validation Error
POST /v1/{workspace_id}/memory/dimensions HTTP/1.1
Host: platform.api-us.concurrence.com
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 87
{
"service_id": "123e4567-e89b-12d3-a456-426614174000",
"key": "text",
"description": "text"
}No content
Example request body, using a synthetic service identifier:
The operation checks that the service belongs to the workspace and returns 201 with no response body. Each successful request appends the next definition version for that workspace, service, and key, including when the key already exists. It is not an idempotent replacement: reconcile an ambiguous result with the implementation owner before repeating the request. The public API has no companion list, update, or delete operation for dimensions.
Opt a Conversation Into Processing
Follow Pass Context to Tool Parameters to add memoryid to the service's accepted_context and send a value in the conversation-create request's context map. Preserve the service's other accepted keys when updating the list. Reuse the identifier only for the same intended person within that service and workspace.
Processing uses completed production sessions linked to a conversation and configured service dimensions. Sessions without the identifier, conversation linkage, or dimensions remain pending. Voice extraction uses the full call transcript; a text conversation that spans sessions uses the interval after the preceding session end through the current end. Verify this path with an eligible production session using synthetic data; simulation results alone do not exercise it.
Processing and Definition Versions
Extract
Uses the session transcript, current dimension definitions, and existing views to produce source-linked observations classified as new information, confirmation, or contradiction.
Consolidate
Combines a dimension's current view and new observations under its latest definition, then appends a new view version.
Synthesize
Combines every current dimension view with the definition version that produced it. The previous combined model is not an input.
Changing a definition does not retroactively regenerate existing views, combined models, or historical observations. New observations make consolidation eligible; synthesis follows changed view versions. Different dimensions can therefore contribute views produced under different definition versions. A broader definition may need new sessions to obtain the missing evidence.
Processing is asynchronous and model-generated. Failed or invalid generations remain pending, valid empty extraction marks a session processed, and successful no-op reruns do not create additional output versions. Extraction can miss information, and there is no guaranteed time by which a session's results will be available.
Verify Before Using the Outputs
For agent recall, configure an authorized reader tool and bind its memoryid parameter from conversation context. The graph must expose that tool and instruct the agent when to call it; empty results are a normal first-session outcome. Reader names and access are deployment-specific. The dimension-creation operation alone does not install readers or add them to a graph.
Use synthetic sessions with a new preference, a later correction, and no relevant information. Through the provisioned reader, verify the workspace/service/memory scope, source conversation, definition versions, changed views, and combined model. Check that the correction reaches the intended application before assuming a later session can use it.
Keep structured clinical facts in their authoritative retrieval path. Generated memory remains interpretive evidence; it does not replace clinical records, prove identity, or guarantee recall. If processing or reads are unavailable, use the workflow's established fallback and retain the session identifiers for reconciliation.
Last updated
Was this helpful?