inference + recall, one API

Your agent
remembers at
query time.

Drop-in recall layer for AI agents. Store what happened, retrieve only what the next step needs — no re-stuffing the whole history into context.

Start building Read the quickstart
your agent any loop inra recall layer mem.add · write what happened mem.recall · only what this step needs
quickstart.py 
from inra import Memory

mem = Memory(api_key="inra_...")

# remember an interaction
mem.add(
    agent="support-bot",
    user="u_123",
    text="prefers email over phone",
)

# recall only what this step needs
ctx = mem.recall(
    agent="support-bot",
    user="u_123",
    query="how should I reach them?",
)
print(ctx)  # → ["prefers email over phone"]
3
lines to integrate
Python · TS · Go
SDKs
Apache 2.0
open core

Quickstart

Install, add a memory, recall it. That's the whole surface.

$ pip install inra
The problem

Agents forget the moment the context window fills.

A model only knows what's in its prompt right now. Conversations run long, sessions restart, and useful detail scrolls out of the window. Stuffing the whole history back in is expensive and dilutes what matters — and generic RAG over a document store rarely returns the one fact the current step needs.

inra is the layer in between: a place to write what happened and pull back only what's relevant, keyed to the agent and user it belongs to.

older detail scrolls out ↑ "deploys on Fridays only" context window fixed size earlier turn earlier turn current question new turn arrives ↓pushes the oldest out write it down inra · outside the window holds what scrolled out recall at query time → returns just the relevant piece not the whole history
The window is finite — as turns pile up, older detail scrolls out. inra keeps it and returns only what the current step needs.
AI-generated material metaphor: one amber fragment selected from layered glass plates, not a live memory system.
Conceptual selection metaphor · AI-generated, not a live system architecture
How it works

add → store → recall.

One write path, one read path. Recall happens at query time, so the model sees only what the current step needs.

mem.add()

Write what happened

Hand inra a string plus the agent + user it belongs to. It embeds and stores the memory — you don't manage vectors or an index.

store

Kept under scope

Memories live inside a scope, so one user's context never leaks into another's, and each agent keeps its own knowledge.

mem.recall()

Read at query time

Pass the current query. inra returns only the matching memories, ranked by relevance — drop them straight into the prompt.

your agent support bot · copilot any loop inra · recall layer embed → scope(agent, user) one user's context never leaks into another's rank by query → top matches returns the fact this step needs, not the whole log mem.add(text) write what happened mem.recall(query) read only what's relevant, at query time
Two calls behind your agent loop — write once, read only what the current step needs.
current query "what did we decide?" embed stored memories · compared by meaning the metric decision why we chose it lunch preference an old greeting unrelated note top matches into the prompt the rest stays out
Recall ranks by meaning against the query — the closest memories go into the prompt, the rest stays out. No keyword match, no whole-log dump.
Capabilities

What the recall layer gives you.

scope

Namespace isolation

Memories are scoped by agent and user, so recall never mixes one end-user's context with another's.

recall

Semantic recall

Retrieval ranks by meaning against the current query — you get the relevant fact, not a keyword match or the whole log.

add

Incremental writes

Add one memory at a time as the conversation happens. No batch reindex, no pipeline to babysit.

any loop

Framework-agnostic

Two calls behind whatever agent loop you run — a tool-calling agent, a graph, or a plain request handler.

Under the hood

What "scoped" and "at query time" mean in practice.

memories scoped by (agent, user) scope(agent, user_A) A: on the enterprise plan A: prefers email over calls recall(query, A) searches here only → returns A's memories scope(agent, user_B) B: on the free tier B: only used it once ✕ never crosses
Namespace isolation: recall runs inside the caller's scope(agent, user) — one end-user's context is never mixed with another's.
the conversation happens → turnmem.add(one) turnmem.add(one) turnmem.add(one) turn ✕ no batch reindex · no pipeline to babysit
Incremental writes: add one memory at a time, as it happens — there is no batch reindex step to schedule.
mem.add(text, agent, user) inra — managed for you embedturn text into a vector store under scopeindexed for recall you don't manage vectors or an index
One write path: hand inra a string plus its (agent, user) — it embeds and stores under scope. You don't manage vectors or an index.
How teams use it

Where a recall layer earns its keep.

The pattern repeats wherever agents run long enough to forget. These are the shapes the tool is reached for — described by the job, not a logo.

// support automation

A team running a dozen support agents stops re-stuffing whole transcripts into every prompt. The agent pulls back the two or three facts a reply actually needs — a customer's plan, their last issue, that they prefer email over phone — and leaves the rest in the store.

// coding copilots

A copilot that spans sessions keeps a project's conventions between them: the test runner, the naming style, the one directory it's told never to touch. Recall makes those survive a restart, so the assistant isn't relearning the codebase every morning.

// illustrative usage patterns — inra is early; these describe the job, not named customers.

Who it's for

Developers building AI agents that need to remember across turns and sessions — support bots, copilots, assistants — without hand-rolling a vector store and a recall pipeline.

Get started →