# AI agent memory vs structured state: what goes where?

Use memory for recall and structured state for current records an AI agent must inspect, update, and share without guessing.

Use AI agent memory for context that helps the agent interpret a later request:
preferences, prior interactions, learned facts, and relevant episodes. Use
structured operational state for current records the agent must inspect and
change precisely: tasks, contacts, inventory, feedback, content queues, and
approval status.

The boundary is authority. If a user asks, "What is the current status?", one
keyed record should settle the answer. That record should not depend on which
memory a similarity search happens to retrieve.

## The short decision rule

Ask what a human should inspect when two agent runs disagree.

- If the answer is a current row identified by `task_id`, `email`, `sku`,
  `slug`, or another stable key, keep it in structured operational state.
- If the answer depends on relevant context from earlier interactions, keep it
  in memory.
- If the answer is "where did this run stop?", keep it in a workflow checkpoint.
- If the answer is "what happened and who changed it?", keep it in audit history.

This is the **authoritative lookup test**. It prevents a common architecture
mistake: asking one storage layer to handle recall, execution, mutable business
records, and history at the same time.

| Layer | Primary job | Typical lookup | Example |
|---|---|---|---|
| Agent memory | Recall useful context | Semantic or scoped retrieval | "Rasul prefers concise status updates" |
| Workflow checkpoint | Resume an execution | Thread, run, or checkpoint ID | "Continue after the approval step" |
| Structured operational state | Read and change current records | Exact key, filter, or bounded search | "TASK-104 is blocked" |
| Audit history | Prove what happened | Time, actor, event, or version | "The status changed at 14:02 UTC" |

The layers can share infrastructure. A PostgreSQL database might persist all of
them. That does not make their jobs interchangeable.

## What AI agent memory is for

AI agent memory helps an agent carry useful context across steps or sessions.
It answers questions such as:

- What did this user tell me before?
- Which preferences should shape my response?
- Which past experience is relevant to the current request?
- What facts or procedures should I recall in this context?

LangGraph's current memory documentation separates short-term and long-term
memory. Short-term memory is thread-scoped and tracks the ongoing interaction.
Long-term memory stores user- or application-level data across sessions
([LangGraph memory overview](https://docs.langchain.com/oss/python/concepts/memory),
checked July 2026).

That distinction is useful because retrieval is part of the design. Long-term
memory may be fetched by namespace, exact key, metadata filter, or semantic
similarity. The agent does not need every stored memory for every request. It
needs the memories that help with the present context.

For example, a personal assistant may remember that a user prefers morning
flights, avoids overnight connections, and usually travels with a young child.
Those memories improve future recommendations. They do not tell the assistant
whether booking `TRIP-204` is currently approved or whether the ticket has been
purchased.

Memory can also be corrected, summarized, forgotten, or reinterpreted. Those
are sensible behaviors for contextual recall. They are dangerous defaults for a
current task status or product price.

## What structured operational state is for

Structured operational state is the current set of records an agent is allowed
to inspect and mutate as part of a real workflow. It answers different
questions:

- Which task is blocked right now?
- What is the current price for SKU-104?
- When should this contact be followed up?
- Which article slug is ready for review?
- Has this feedback item been linked to a shipped fix?

These questions need explicit fields, stable identity, validation, and an
authenticated write path. A fuzzy recollection is not enough.

PostgreSQL describes a primary key as the column or columns that uniquely
identify a row, with values required to be unique and non-null
([PostgreSQL constraints](https://www.postgresql.org/docs/current/ddl-constraints.html),
checked July 2026). An agent-facing dataset does not need to expose a full SQL
database, but it still benefits from the same core property: one reliable way
to address the record that should change.

In Rowset, a dataset carries headers, an index column, semantic column schema,
instructions, and metadata. Agents can inspect and update it through
[hosted MCP access](/docs/connect-mcp) or the [Dataset API](/docs/dataset-api).
That makes the dataset an operating surface, not a pile of context placed into
a prompt.

If this concept is new, start with [what an agent-managed dataset
is](/blog/agent-managed-datasets). The important point here is narrower:
structured rows hold current workflow truth, while memory helps the agent use
that truth in context.

## Memory and state fail differently

Keeping the layers separate makes failures easier to reason about.

When memory retrieval fails, the agent may miss a preference, retrieve stale
context, or recall an irrelevant episode. The correction is usually to improve
scoping, retrieval, summarization, or memory-writing rules.

When operational state fails, the agent may update the wrong row, create a
duplicate record, use an invalid status, or overwrite a current value. The
correction is usually a stable key, schema validation, bounded permissions,
read-before-write behavior, or a review step.

Those are not the same control problem. A better embedding will not repair a
missing unique identifier. A stricter row schema will not decide which past
conversation matters to a new request.

This also explains why "store everything in a vector database" is an incomplete
answer. Semantic search is useful for finding relevant material, including rows.
It is not a substitute for the canonical record that an update should target.

Rowset's search path makes this boundary explicit. Hybrid vector and lexical
search can find relevant data, but results are hydrated from canonical rows and
Postgres remains the source of truth. The [row operations guide](/docs/work-with-rows)
then directs agents to exact index lookup when a stable business key is known.

## Workflow checkpoints are a third layer

Framework state is often confused with both memory and business data.

A workflow checkpoint records where one execution is and what it needs to
resume. LangGraph's persistence documentation describes checkpointers as
snapshots of graph state, while stores hold long-term data outside the graph
state ([LangGraph persistence](https://docs.langchain.com/oss/python/langgraph/persistence),
checked July 2026).

A checkpoint might contain:

- the messages used in the current run
- tool outputs needed by the next step
- which approval branch is active
- pending writes from completed nodes
- the point from which an interrupted workflow can resume

That is different from a task board. A checkpoint may say, "the run is waiting
for approval." The task board should say, "TASK-104 is blocked, owned by Scribe,
and waiting on a product decision." The checkpoint helps one execution
continue. The task row helps later runs, other agents, and humans see current
work.

Do not make a checkpoint the only copy of a business fact that matters after the
run ends. Write the approved outcome to the operational record, then let the
checkpoint serve its narrower resume-and-recover job.

## MCP is the interface, not the storage model

The Model Context Protocol connects an AI application to external capabilities.
Its server model separates resources, which provide contextual data, from tools,
which can perform actions such as querying a database, calling an API, or writing
a file ([MCP server concepts](https://modelcontextprotocol.io/docs/learn/server-concepts),
checked July 2026).

That separation helps, but MCP does not decide whether a value belongs in
memory, a checkpoint, or an operational dataset. It gives the agent a typed way
to read or act on the system you expose.

For operational state, tool schemas should make the intended action concrete.
Rowset exposes tools for dataset discovery, row lookup, row creation, and row
updates. A connected agent can inspect the live schema before it writes. The
current MCP specification also recommends keeping a human able to deny tool
invocations, especially for sensitive operations
([MCP tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools),
checked July 2026).

Use memory to help the agent decide what the user probably means. Use a typed
tool and a stable record to carry out the approved change.

## A practical design for four common workflows

The same test works across very different jobs.

### Personal CRM

Keep communication style, general interests, and relationship context in memory
when they help the agent interpret a future conversation. Keep the contact's
current company, relationship stage, last interaction date, and next action in
a keyed CRM dataset.

If the user says, "Sam moved to Acme," update the canonical contact row. Do not
leave the new company only in a conversational memory that another run might
not retrieve. Rowset's [personal CRM pattern](/use-cases/personal-crm) uses
`email` or `person_id` as the stable index for this reason.

### Agent task board

Keep reusable preferences about how the user delegates work in memory. Keep
task owner, status, blocker, priority, and completion evidence in structured
state.

One agent may remember that the user prefers small PRs. Every agent still needs
the same authoritative answer for whether `TASK-104` is in `doing`, `blocked`,
or `done`. The [agent task board pattern](/use-cases/agent-task-board) makes
that state visible across runs and handoffs.

### Product catalog

Keep broad merchandising preferences or past campaign lessons in memory. Keep
current SKU, title, price, availability, and source URL in a product dataset.

The price that happens to appear in a retrieved note is evidence, not authority.
The current catalog row should be the value a publishing or purchasing workflow
uses, with `sku` as the stable key.

### Content pipeline

Keep editorial preferences and lessons from prior reviews in memory. Keep slug,
owner, stage, canonical URL, publish date, and review evidence in a structured
content queue.

This lets memory improve the draft while the dataset controls the workflow. An
agent can recall that the house style avoids hype, but it should read the row to
know whether the article is still a draft or has already shipped.

## When one fact appears in both layers

Sometimes the same subject appears in memory and structured state. That is not
automatically duplication.

A CRM row might say `preferred_channel = email`. Memory might contain the
context that the person dislikes unscheduled calls because of their work hours.
The row holds the current actionable setting. The memory supplies nuance.

Trouble starts when both layers claim authority over the same mutable value. If
memory says the task is blocked and the task board says it is done, which one
wins? Decide that in advance.

Use these rules:

1. Give each mutable business fact one authoritative home.
2. Let memories refer to the record rather than copy every current field.
3. Re-read the current record before an important write.
4. Treat retrieved memory as context, not permission.
5. Write approved outcomes back to the operational record.

For Rowset datasets, the index column is what makes that re-read precise. Use
the [index-column decision guide](/blog/choose-index-column-agent-rows) before
building a workflow that will update the same records repeatedly.

## A setup checklist

Use this checklist before giving an agent persistent data access.

### For memory

- Define what is worth remembering and what should expire.
- Scope memories by user, workspace, or workflow.
- Decide whether retrieval is exact, filtered, semantic, or combined.
- Give users a way to correct sensitive or consequential memories.
- Keep secrets and raw credentials out of memory.

### For structured operational state

- Choose one stable index for each dataset.
- Define allowed fields, types, and status values.
- Store instructions with the dataset so future agents see them.
- Use the narrowest useful read/write permission.
- Inspect the dataset and current row before changing it.
- Keep destructive actions behind explicit user intent.
- Provide a human review path.

Rowset public previews are read-only and intended for human review. Private
agent operations stay behind authenticated MCP or REST access. If this is the
boundary you need, follow the [first-dataset guide](/docs/quickstart), then
review [Rowset pricing](/pricing) before the 7-day trial ends.

## FAQ

### Is AI agent memory the same as a database?

No. Memory is a behavior: storing and retrieving context that may help later.
A database is infrastructure that can implement memory, checkpoints,
operational records, audit history, or several of them. The important design
choice is which data owns authority and how it is retrieved and changed.

### Should task status live in agent memory?

Task status should live in structured operational state when other runs, agents,
or people need one current answer. Memory may retain context about why the task
is blocked, but the keyed task record should own the authoritative status.

### Can vector search be used with structured state?

Yes. Vector or hybrid search can help an agent find relevant rows when it does
not know the exact key. Once the target is found, important reads and updates
should use the canonical row and its stable identity rather than a similarity
result alone.

### Does an MCP server replace agent memory?

No. MCP standardizes how AI applications access resources and invoke tools. An
MCP server can expose a memory store, a dataset, a database, or another service.
The protocol is the interface; the connected system still needs a clear data
model and authority boundary.

### When is Rowset the right structured-state layer?

Use Rowset when a trusted agent needs a private, inspectable row store with
stable indexes, schema context, instructions, MCP and REST access, exports, and
optional read-only previews. Use a full application database when the workflow
needs complex transactions, custom server logic, or direct integration with an
existing production schema.