Chat Memory
By default each AI Agent invocation is stateless — the model sees only the current message.
Chat memory makes a service task part of an ongoing conversation: prior turns are replayed before
each call, so a process can hold a multi-turn dialogue across BPMN steps — most often across a
human-feedback user task.
Enabling memory
In the Memory group:
| Field | Parameter | Default | Notes |
|---|---|---|---|
| Use chat memory | useChatMemory |
${false} |
Set to ${true} to activate. |
| Memory ID | memoryId |
new UUID | Conversation identifier. Shown only when memory is on. |
| Chat memory max messages | chatMemoryMaxMessages |
20 |
Sliding window; older messages are dropped. |
How memoryId behaves:
- Leave it empty to start a new conversation. The connector generates a UUID and returns it via
the
${memoryId}output — persist it into a process variable so you can pass it back later. - Set it (e.g.
${memoryId}) to continue a known conversation. - In a loop, use
${execution.getVariable('memoryId')}: it’s empty on the first iteration (new conversation, ID returned) and reuses the stored ID on later iterations.
Map the memory ID output (${memoryId} → e.g. memoryId) so the conversation can be resumed.
Human-in-the-loop pattern
The canonical use is a review loop:
- AI Agent task —
useChatMemory = ${true},memoryId = ${execution.getVariable('memoryId')}. Map${output}and${memoryId}to process variables. - User task — a human reads the agent’s answer and supplies feedback into a variable.
- Gateway — loop back to the agent (feeding the feedback as the next
message) until the human is satisfied, then continue.
Because the same memoryId is reused, the agent sees the whole prior exchange on each iteration and
refines its answer rather than starting over. See the human-in-the-loop.bpmn demo in
Examples.
The memory store is JVM-local
Warning
Chat memory is held in a JVM-wide store that defaults to an in-memory implementation. This has two consequences you must design around:
- It does not survive an engine restart. Conversations in flight are lost when the JVM stops.
- It is not shared across nodes. In an HA / clustered deployment, a resumed task that lands on a
different node will not find the conversation, and
chatMemoryMaxMessagesis enforced per JVM.
For single-node deployments and conversations that complete within one engine lifetime, the default
is fine. For HA or durable conversations, the backing store can be replaced at application startup
with a persistent implementation (database, Redis) via AgentChatMemoryStore.setStore(...); a
helper AgentChatMemoryStore.clear(memoryId) forgets a single conversation. See
Developer Guide and Limitations.
Note
If you don’t need conversation history, leave useChatMemory off — stateless invocations avoid the
store entirely and sidestep the clustering caveat.