Should ConversationMemory be part of WorkflowDef or runtime input?
I noticed that ConversationMemory is currently serialized into the agent config and then compiled into the generated WorkflowDef.
Current flow:
- The SDK serializes
Agent.memory into agentConfig.memory.
- The server compiler adds
memory.messages into the LLM task messages.
/api/agent/start registers/upserts the compiled WorkflowDef.- Since the generated workflow version is usually the same, the DB keeps one workflow definition per
(name, version) and updates its json_data.
This means conversation history may become part of the persisted workflow definition, rather than being scoped to a single workflow execution.
Is this intentional?
My concern is that ConversationMemory looks more like per-run or per-session state than static workflow definition data. If multiple runs of the same agent carry different memory, the registered WorkflowDef may reflect whichever run updated it last.
Would it be more appropriate for conversation memory to be passed as runtime input instead of being compiled into the workflow definition?
Should ConversationMemory be part of WorkflowDef or runtime input?
I noticed that
ConversationMemoryis currently serialized into the agent config and then compiled into the generatedWorkflowDef.Current flow:
Agent.memoryintoagentConfig.memory.memory.messagesinto the LLM taskmessages./api/agent/startregisters/upserts the compiledWorkflowDef.(name, version)and updates itsjson_data.This means conversation history may become part of the persisted workflow definition, rather than being scoped to a single workflow execution.
Is this intentional?
My concern is that
ConversationMemorylooks more like per-run or per-session state than static workflow definition data. If multiple runs of the same agent carry different memory, the registeredWorkflowDefmay reflect whichever run updated it last.Would it be more appropriate for conversation memory to be passed as runtime input instead of being compiled into the workflow definition?