Camunda Remembers the Process Instance. Your Next Run Still Starts Without the Last One.

A recurring Camunda process can run flawlessly for months and still feel strangely forgetful. The timer fires, the tasks execute in the right order, approvals route to the right people, and incidents surface where they should. Then the AI step inside the process reviews a case it reviewed last week and asks the same clarifying questions, misses the exception it handled last time, and proposes an approach that was already ruled out.

Nothing has broken. The process has remembered the workflow exactly as designed. What it has not remembered is the agent's own past work, because in Camunda that past belongs to a finished process instance, and a finished instance does not brief its successor.

One instance has a real memory

Inside a single execution, continuity is genuine. Camunda's AI Agent connector works through an ad-hoc sub-process, calling tools, reading results, and deciding the next move in a loop. That loop carries a short-term conversational memory, so later iterations can build on earlier ones within the same process instance.

The shape of that memory is deliberately bounded. Its context window replays a limited number of prior messages to the model, 20 by default, and its storage can sit in the process itself, in Camunda Document storage, or in a custom external store such as AWS Bedrock AgentCore Memory. Those options solve real problems: surviving a restart, handling a long conversation, or moving large message histories out of a process variable.

Notice the unit in every case. The conversation being preserved is the conversation of that instance. When a user task pauses the process for a day and the agent resumes, the thread can continue. When the instance completes, that continuity completes with it.

Variables remember what the model told them to

Process variables give a process a second kind of persistence. A variable set by an early task remains available to later tasks, gateways can route on it, and forms and connectors can read it. For structured business data, this is exactly the right mechanism.

Agent memory is rarely that tidy, though. Take a weekly vendor review process. The structured output might be a single risk rating. The useful past is wider: which documents supported the rating, which clause caused concern, what the reviewer agreed to check next quarter, and which concern turned out to be unfounded. Unless someone designs variables for each of those points and writes extraction steps to fill them, they live only in the agent conversation of that week's instance. Next quarter's instance gets the rating and none of the reasoning, so the review starts over with a number and no story behind it.

The same gap appears in claims handling, employee onboarding checks, and order exception processes. The more judgment an AI step exercises, the more of its value sits in context that a variable list was never designed to hold.

A perfect record is not a briefing

After an instance ends, Camunda retains the operational record that lets teams inspect what happened. That record supports compliance, troubleshooting, and process improvement. It shows the path taken and the values carried along the way.

A returning agent needs something else: a briefing. It needs last run's conclusions presented as context it can act on, connected to the runs before that, and searchable by the case in front of it now. A history view built for human inspection does not become a briefing just because it is complete. The next instance is never started with the previous instance's agent conversation as its starting context.

There is a cross-tool version of the same problem. Even a well-kept Camunda record stays inside Camunda. The assistant helping draft the follow-up email, or the automation updating the same account in another system, has no shared past with the process, so each tool holds a fragment and no tool holds the whole story.

Give recurring processes a past that outlives instances

The fix is to treat agent memory as its own layer, separate from both process state and engine history. Vilix AI provides that layer as a cloud-hosted service with zero infrastructure to run, so adding it does not mean operating a new memory database beside the orchestration cluster.

Because Vilix AI is reached over MCP, one memory serves every surface doing the work: the agent step inside a Camunda process, scheduled automations on other platforms, and the AI assistant someone opens in chat to follow up. A decision saved by any of them is available to all of them on the next run, in the next instance, and after the process model itself is redesigned.

The content of that memory matters as much as its reach. Vilix AI keeps full conversation history rather than reducing everything to isolated facts, so a future run can revisit what was actually discussed, why a vendor was flagged, what was promised to a customer, and what evidence changed a conclusion. A process can fetch the relevant history before its agent step and save the step's outcome when it finishes, turning each completed instance into preparation for the next one.

Adopting that layer is reversible by design. The free plan stays free forever, the 7-day Pro trial needs no credit card, and memory can be exported or deleted whenever you choose.

The distinction to keep

Camunda remembers the process instance: its agent conversation while the work is live, its variables while the tasks flow, and its record after the work is done. It does not, by itself, remember between runs in the way a recurring agent needs, because each new instance begins a new past. Pair strong orchestration with a shared memory layer, and the next run no longer starts without the last one. It starts with it.