https://github.com/agentspan-ai/agentspan which is essentially an agentic SDK layer for Conductor can convert any of your langgraph, openAI, vercel, or ADK agent and makes it durable and adds orchestration with no code changes.
The thesis: agents should not just be an LLM loop running inside one Python process. Once agents touch real systems, you need crash recovery, retries, human approval, distributed tool execution, cancellation, observability, and execution history.
Agentspan is basically applying the Conductor OSS execution model to agents. Conductor made long-running distributed workflows durable. Agentspan tries to do the same thing for agent executions: give every run an ID, persist the state, let it survive process death, pause for approval, resume later, and inspect what happened.
The post is three arguments that together form a new framing for agent runtimes:
The LLM shouldn't execute anything (planning and execution belong on strictly separated planes), signals are the primitive that makes out-of-band cancellation and replanning possible, and the workflow's graph should be synthesized by the LLM at runtime rather than declared by a programmer at commit time. That last one is the load-bearing idea - a Late-Bound Saga.
Agentspan is the runtime that implements it on top of Conductor. Happy to answer about any of these and why I think the `while` loop is the wrong primitive.
I haven't used Conductor, but quickly looking at the README, Conductor lets you define JSON workflows to orchestrate existing microservices. By contrast, DBOS helps you build highly reliable applications--it runs as a library inside your program and helps you build durable workflows that run alongside your code and are written in the same language.
https://github.com/agentspan-ai/agentspan which is essentially an agentic SDK layer for Conductor can convert any of your langgraph, openAI, vercel, or ADK agent and makes it durable and adds orchestration with no code changes.
reply