Describe the bug
When executing a workflow using @voltagent/core, the context object does not have a default value, and assignments made to context within workflow steps do not persist or reflect in downstream agent/tools. However, initializing context during the initial .run() call does populate it as expected. This makes it unclear whether this is intended behavior or a design flaw.
Full example:
import { Agent, createTool, createWorkflowChain } from "@voltagent/core";
import _ from "lodash";
import { z } from "zod";
import { Output } from "ai";
const checkContextTool = createTool({
name: "check_context",
description:
"Checks the number of keys present in the agent's context and returns the count.",
parameters: z.object({}),
execute: async (args, options) => {
return `Found ${options?.context?.keys().toArray().length} keys in the context.`;
},
});
const agent = new Agent({
name: "Demo Agent",
model: "openai/gpt-5-mini",
instructions: "",
tools: [checkContextTool],
});
const result = await createWorkflowChain({
id: "demo_workflow_0001",
name: "Demo Workflow 0001",
result: z.any(),
}).andThen({
id: "step_1",
execute: async ({ data, state }) => {
state.context = state.context ?? new Map();
state.context?.set("new_key", "new_value");
console.log(
`Keys in context: ${state.context?.keys().toArray().join(", ")}`,
);
return data;
},
}).andAgent(
"call check_context tool to check the number of keys in the context",
agent,
{ schema: Output.text() },
(output) => ({ output }),
).run({});
console.log(result);Logs show the new_key exists during the step, but downstream agents/tools do not see it.
Steps To Reproduce
- Set up an agent and tool using
@voltagent/core (see provided sample code for full context).
- In a workflow step, attempt to create or mutate the
context (e.g. state.context?.set(...)).
- Observe in the logs that the new key is present in the step.
- When a tool/agent runs after this step, inspect the
context—the keys added in the step are missing. However, if context is set in .run(), it is visible.
Sample output:
Keys in context: new_key
{
executionId: "c127d985-5d21-420c-bb79-20c91ca52da8",
workflowId: "demo_workflow_0001",
startAt: 2026-01-30T07:27:23.241Z,
endAt: 2026-01-30T07:27:28.997Z,
status: "completed",
result: { output: "There are 0 keys in the context." },
usage: { promptTokens: 222, completionTokens: 13, totalTokens: 235 },
suspension: undefined,
cancellation: undefined,
error: undefined,
resume: [AsyncFunction: resumeFn]
}
Expected behavior
Either:
- The workflow should provide a default context, and/or assignment(s) to context within workflow steps should persist to downstream agents/tools (preferred),
- Or, documentation must clarify that context is only meant to be set during initial
run, not modified in steps, and explain the designed lifecycle and mutability.
Assignments in workflow steps should be visible to later agents/tools if supported.
Packages
- @voltagent/core
- lodash
- zod
- ai
Reproduced using a basic agent and tool registration with workflow logic as in Demo.
Additional Context
Sample code and logs are available above. Is this a design choice or a bug? Please clarify the intended workflow context lifecycle and mutability.
Describe the bug
When executing a workflow using
@voltagent/core, thecontextobject does not have a default value, and assignments made tocontextwithin workflow steps do not persist or reflect in downstream agent/tools. However, initializingcontextduring the initial.run()call does populate it as expected. This makes it unclear whether this is intended behavior or a design flaw.Full example:
Logs show the new_key exists during the step, but downstream agents/tools do not see it.
Steps To Reproduce
@voltagent/core(see provided sample code for full context).context(e.g.state.context?.set(...)).context—the keys added in the step are missing. However, if context is set in.run(), it is visible.Sample output:
Expected behavior
Either:
run, not modified in steps, and explain the designed lifecycle and mutability.Assignments in workflow steps should be visible to later agents/tools if supported.
Packages
Reproduced using a basic agent and tool registration with workflow logic as in Demo.
Additional Context
Sample code and logs are available above. Is this a design choice or a bug? Please clarify the intended workflow context lifecycle and mutability.