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:

  1. AI Agent task — useChatMemory = ${true}, memoryId = ${execution.getVariable('memoryId')}. Map ${output} and ${memoryId} to process variables.
  2. User task — a human reads the agent’s answer and supplies feedback into a variable.
  3. 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 chatMemoryMaxMessages is 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.

On this Page: