Orchestrators with persistent state

[mirek-capgemini]

Docs are covering different types of orchestration. https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-orchestration/?pivots=programming-language-python
I want to store conversation state persistently so i can came back to conversation later, or from different instance of agent. Maybe creating own runtime is the way to go, but i cannot find docs how i could create one.

[moonbox3]

We would like to gently suggest for you to have a look at our predecessor framework - Microsoft Agent Framework - in place of SK's "Agent Framework" orchestrations: https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/. GitHub repo is: https://github.com/microsoft/agent-framework

[musaabhasan]

I would avoid starting with a custom runtime unless you need distributed workflow scheduling. For most production cases, it is cleaner to persist three separate things and recreate the agent/kernel when the conversation resumes:

1. Conversation transcript: user/assistant/tool messages, preferably compacted after a threshold.
2. Orchestration checkpoint: orchestration type, current step, completed steps, pending tool calls, retries, and schema version.
3. Long-term memory: vector records or domain facts that are not the same thing as the active conversation state.

On resume, create a fresh kernel/agent instance, load the transcript or compacted thread summary, load the checkpoint, then continue from the next incomplete orchestration step. The important point is that the persisted state should describe the workflow, not the in-memory Python object.

A useful checkpoint shape is something like:

{
  "conversation_id": "...",
  "orchestration": "sequential_orchestration",
  "state_version": 1,
  "current_step": "review_answer",
  "completed_steps": ["retrieve_context", "draft_answer"],
  "step_outputs": {
    "retrieve_context": {"artifact_id": "ctx_123"},
    "draft_answer": {"artifact_id": "draft_456"}
  },
  "pending_events": [],
  "retry_count": 0
}

For reliability, make each step idempotent: give it a stable step_id, store its output before advancing the pointer, and on resume return the cached output if the step already completed. That prevents duplicate tool calls, duplicate emails, or repeated paid API calls after a worker restart.

If you later build a custom runtime, the same structure still applies. The runtime mainly adds scheduling, leases/locks, and retry policy; it should not be the only place where the conversation state exists.