Does Conductor Remember Between Runs?

No. Conductor remembers everything inside one workflow execution and nothing carries into the next run on its own. Each task's inputs and outputs are stored, so a failed or paused execution can resume where it stopped. A new execution starts with only the inputs it was given. It does not load the previous run's outputs, decisions, or reasoning before it begins.

That boundary is easy to miss because Conductor feels durable. A workflow can pause for a human approval, survive a worker crash, and finish days later. Surviving inside one job is different from remembering the last job.

What is Conductor built to remember?

Conductor is a workflow orchestration engine, first built at Netflix and now developed as open source and as Orkes Conductor. Workflows are defined as a sequence of tasks. Each task is either a built-in type Conductor runs itself, such as an HTTP call, a JSON transform, or a wait, or a SIMPLE task handed to a worker you write.

As an execution runs, Conductor stores it. The workflow's inputs, each task's input and output, its status, and its retries become the execution record. Later tasks in the same execution can read earlier results directly, using references to a task's output.

That record is why retries work the way they do. If a task times out, Conductor can redeliver it. If an execution is paused, it can resume later from the stored state. If a workflow fails partway through, it can be retried or rerun from the recorded steps instead of starting blind.

Why do Conductor workers remember nothing?

Orkes states the worker model plainly: workers do not remember anything. A worker has no idea which workflow it belongs to, what happened in the step before it, or what comes next. Every task starts fresh with just the input it was handed. The official word for this is stateless.

Workers poll Conductor for work, claim a task with its input data attached, run your code, and report back with a status and output data. Conductor stores that output and moves the workflow on.

Stateless workers are a strength for scaling. You can run five copies of the same worker and Conductor will spread tasks across whichever ones are polling. If one copy dies, the task waits in the queue for another copy. None of that requires the worker itself to hold a past.

It also means the worker is never the place where yesterday's learning lives. Anything the worker knew during one task exists only in the output it returned to that one execution.

What belongs to one execution?

Every memory mechanism in Conductor is scoped to a single execution, identified by its workflow ID.

Task outputs answer one question: what did this execution do, step by step? They exist so the same execution can finish reliably, and so you can inspect it afterwards. A completed execution stays stored and searchable, but nothing promotes its outputs into the next execution's starting context.

Pause and resume show the same boundary. A workflow waiting on a human task or a timer is still the same execution continuing. A schedule or a caller starting the workflow again creates a new execution, with a new workflow ID and its own record.

What does the next run not get?

A new execution receives the inputs it was started with, and nothing else automatically. It does not receive the previous run's task outputs as context. It does not receive the list of items the last run already handled, the branch the last run chose, or the reason it skipped something.

Take a scheduled agent workflow that runs every morning: check new orders, ask an LLM task to flag exceptions, and route the flagged ones to a person. On Monday the workflow works out that one customer is on a manual hold, so their orders should be routed differently. If that finding exists only as a task output inside Monday's execution, Tuesday's execution starts without it. The orders are still there, the hold is still in place, and the new run can route the same customer the standard way. Conductor executed both runs correctly. Tuesday simply began without Monday's memory.

Reading old executions back is possible. Execution history can be searched and a previous workflow's outputs can be fetched by ID, then passed in as input to a new run. That is a hand-built bridge between two executions of one workflow in one codebase. It carries the values someone chose to fetch, in the shape that code expects. Decisions made in a chat tool, a coding assistant, or a second agent on a different platform never enter that bridge at all.

For agentic work, outside comparisons make the same point. Long-term memory for an agent running in Conductor is described as an external layer, such as a vector database, that you select, integrate, and operate around the orchestration core. Conductor provides the workflow. The long-term memory store is separate.

How is an execution record different from memory?

The execution record is genuinely useful. Status, inputs, outputs, and retries for every run can be inspected, which makes debugging and auditing direct: which run failed, at which task, with what output.

Memory for a recurring agent has a different job. It has to be loaded before the agent acts, not only inspected after it acted. It has to hold decisions and the context behind them, not only task return values. And it has to be reachable from every tool taking part in the work, not only from code that shares one workflow definition and one Conductor server.

An execution history covers the first job for one workflow. It does not cover the assistant that reviewed the output, the agent in another framework that handles the next stage, or the same workflow after the team moves it to a different orchestrator.

How do you give Conductor workflows a shared memory?

That shared memory is what Vilix AI provides. Vilix AI is a cloud-hosted memory layer for AI tools and agents, with no infrastructure to run or maintain. Connected tools reach the same memory over MCP, so a Conductor workflow, an agent in another framework, and a person checking the work in chat can all start from one shared history instead of separate execution records.

A built agent connects with an API key as a Bearer header to https://api.vilix.ai/mcp and gets full memory with zero memory infrastructure. Vilix AI stores full conversation history, not just extracted facts, and retrieval uses both semantic search and keyword search, so exact names and IDs are matched literally as well as by meaning. For recurring work, the decision and the discussion behind it are both there for the next run to load.

Trying it carries little risk. There is a free plan that stays free forever, and a 7-day Pro trial that needs no credit card. Data can be exported or deleted at any time, so control stays with the owner of the memory.

How should you design around this boundary?

1. Use Conductor's stored execution state for what it is designed for: finishing one execution reliably, with retries, pauses, and a full record.
2. Assume every new execution starts with only its inputs, and confirm it by running the same scheduled workflow twice and comparing what the second run knows.
3. Write down what tomorrow's run must know before it acts: settled decisions, items already handled, holds and exceptions, and open questions.
4. Give that knowledge a home the next run actually loads at the start and updates at the end, through a shared memory layer reachable over MCP.

Frequently asked questions

Does Conductor store workflow history?

Yes. Conductor stores each execution's inputs, task outputs, status, and retries, and completed executions remain available for inspection. That history is a record of a run, not context loaded into the next run.

Can a Conductor workflow read a previous run's output?

Yes, if you build it. Your code can fetch a previous execution by its workflow ID and pass selected outputs into a new run as inputs. Nothing does this automatically, and it only carries values you choose to fetch.

Are Conductor workers stateful?

No. Workers are stateless by design. A worker receives one task's input, returns its output, and keeps nothing between tasks. Conductor holds the workflow state, scoped to that execution.

Conductor gives a workflow a solid record of itself. Scheduled agents become dependable across days when each new run is also given what every run before it learned.