Skip to content
Start free
← All solutions

AI agents

Give the next turn
something to remember.

Keep run state, useful memories and tool outcomes in one database. Retrieve the context your agent needs, with records you can inspect.

Start free Build agent memory

Follow one turn, from recall to record.

Your agent runtime controls the loop. OriginChainDB stores the state and context it reads and writes along the way.

Inspect a support agent's turnInteractive illustration
Application-designed workflowA support agent’s next turn
session-84 / run-12

Your runtime starts the next turn.

OriginChainDB · example recordagent.memories
Record ID
memory-03
Session
session-84
Observation
Customer prefers weekly updates.
Recall matching memory IDs, then load their source records before building the next prompt.
Linked by application IDs
  • Run state
  • Memory records
  • Tool events

Rows, embeddings and text indexes use separate writes.

Illustrative records. Select a stage to inspect its role; no agent or tool is executed.

A suggested data model

Separate the state.
Keep the relationships.

Use session, run and record IDs to connect observations with their source. These are application tables you define, not a required agent framework.

01

Run state

Current step, status and checkpoint data.

run_id · session_id · status
02

Memory

A focused observation with its time and source.

memory_id · agent_id · text
03

Tool event

The attempted action and recorded outcome.

call_id · run_id · outcome

Add embeddings and full-text entries under the memory's ID. Row, vector and text writes are separate calls; track which steps have completed.

See the memory schema and writes

Recall by the question
you need to answer.

Use structured lookups for state, similarity for related memories, keywords for exact terms and graph references for provenance.

SQLWhat is this run waiting for?VectorHave we seen a similar request?Full-textWhere did error AX-7 appear?GraphWhich source produced this memory?

Tools with a clear contract

Let the agent ask.
Inspect what it runs.

Expose focused database tools through your application. ASK accepts a question, table scope and optional plan inspection, then returns database rows.

It is a query interface. Your runtime still chooses tools, calls models and decides whether an action needs approval.

Read the ASK contract
Example requestPOST /v1/tenants/:tenant/ask
{
  "nl": "agent.memories where session_id = 'session-84' limit 5",
  "schemas": ["agent.memories"],
  "show_plan": true
}

Scope the request to the memory table and review its returned plan.

Make retries and retention explicit.

Durable records are the starting point. Define how your application handles partial writes, stale context and access to each session.

Retry deliberately
Keep stable memory and tool-call IDs. Retry failed index writes without treating a repeated tool request as a new external action.
Expire the whole memory
When retention ends, remove the row and its vector and text entries. Row deletion does not automatically remove those indexes.
Scope every lookup
Use database access controls and validate agent/session scope in your service. Carry agent metadata into retrieval indexes; filters do not replace authorization.

Build on memory you can inspect.

Start the memory example Explore the database