Does AWS Step Functions Remember Between Executions? Inside One Run, Yes. Across Runs, No.

Short answer: inside one execution, Step Functions remembers a great deal. Across executions, it remembers nothing on its own. Each time a state machine starts, Step Functions creates a separate execution, and that execution begins with only the JSON input handed to it at start. What the previous execution learned, decided, or produced is not carried into the next one unless a developer stored it somewhere else and built the step that reads it back.

That split explains a common surprise. A workflow can run flawlessly for a year, pause for a callback, survive a failed task, and resume exactly where it left off, yet the scheduled version of the same workflow on the following morning acts as if yesterday never happened. Both behaviors are the design working as intended.

What one execution keeps

Position and payload, checkpointed as it goes. For Standard workflows, AWS documents that execution state persists internally between state transitions. The service tracks which state is current and threads the JSON output of each state into the next state as input. A Task state calling Lambda, a Choice state branching on a field, and a Wait state pausing for days all share one continuous, service-held picture of where the execution stands.

A full event history for Standard workflows. Every transition is recorded in an execution history that can be read back through the console or the GetExecutionHistory action. That history is capped at 25,000 events and retained for 90 days after the execution closes. It is a detailed audit log of one run: inputs, outputs, failures, retries, and timestamps, in order.

Durability over long horizons. Standard workflows can run for up to a year, follow an exactly-once model for states, and can be redriven after a failure so execution resumes instead of restarting from the first state. A human approval pattern, where a task waits for a callback token, depends on exactly this: the execution holds its place while the outside world takes its time.

A different bargain for Express workflows. Express workflows are built for high-volume, short work, capped at five minutes per execution. Their model is at-least-once, the service does not keep the same persisted execution state between transitions, and there is no execution history to query afterward; results surface through CloudWatch Logs when logging is enabled. Choosing Express is choosing speed over a remembered run.

Where the memory ends

An execution is an instance, not a continuing identity. When it finishes, its final output is returned, its history sits available for inspection for a while, and then the record ages out. The next StartExecution call does not consult any of that. It receives whatever input the caller passes, and nothing else is automatically attached.

In practice, that boundary shows up in four places:

• A nightly state machine that summarizes new support tickets has no built-in way to know which tickets last night's execution already summarized. Without an external record, the safest code path is to process everything again or trust a date filter in the source system.
• An AI step inside the workflow, calling a model to draft a reply or classify a request, receives only the fields the state machine hands it. The reasoning from the previous run, the customer exchange from last week, and the decision a person made in another tool are not in that payload unless someone fetched them first.
• Payload limits shape what can ride along. State input and output are JSON with a 256 KB ceiling, so even inside one execution, large context is normally referenced from a store such as S3 rather than passed state to state.
• The common fix is hand-built. Teams add DynamoDB, S3, or another database, write a step that saves progress, add a step that loads it at the start, and maintain the keys, cleanup, and failure cases themselves. It works, and it becomes one more system to own.

None of this is a flaw in Step Functions. It is an orchestrator: its job is to move one execution reliably through its states. Remembering across executions, across workflows, and across tools is a different job.

Why this matters more once AI steps enter the workflow

A traditional task is mostly deterministic: given the same input, it does the same thing, so a fresh start costs little. An AI step is different. Its output depends on the context it is given, and the valuable part of yesterday's run is often not a field in a database. It is the conversation: what the customer actually said, which option was already offered, why an exception was approved, what a human changed before sending.

If that history lives nowhere the next execution can read, every scheduled AI workflow re-derives it or does without it. The visible symptoms are familiar: follow-ups that ignore a reply, reports that re-announce settled items, and drafts that contradict a decision made in a chat tool the workflow cannot see.

The layer built for the across-runs part

Vilix AI is a hosted memory layer for exactly that second job. An AI step, an agent, or an assistant connects over MCP, reads the shared record before acting, and saves what it decided afterward, so the next execution, in Step Functions or anywhere else, starts with the past included.

It is built around the gaps an orchestrator leaves open:

Cloud-hosted, with zero infrastructure to run. There is no table to design, no store to provision, and no extra service to keep alive inside an AWS account. The memory is hosted, and connecting a tool is the whole setup.

The same memory everywhere. Access runs over MCP, so the record is not trapped inside one state machine or one platform. A Lambda-backed AI step, a workflow in another automation tool, and an assistant on a phone or laptop can all read and write the same shared memory.

Full conversation history, not just facts. Vilix AI stores the actual history, including what was said, decided, and deferred, so a later run can revisit the real exchange instead of working from a single status field.

Free to start, clean to leave. The free plan is free forever. The Pro trial runs for 7 days with no credit card required. Data can be exported or deleted at any time, so the history stays portable.

How the two fit together

Keep Step Functions for what it does best: sequencing, retries, waits, callbacks, and durable execution of each individual run. Then give the work that repeats on a schedule one memory outside the state machine. Before an AI step acts, it checks the shared record for what earlier runs and other tools already settled. After it acts, it writes back what changed. The orchestrator keeps remembering inside the run, and the operation finally remembers between them.