Agentspan: a durable runtime for AI agents, now folded into Orkes Conductor
Agentspan is now part of Orkes Conductor
At a glance
- What is it?
- Agentspan wraps an existing agent loop in Conductor's durable execution engine so a crashed worker resumes at the last completed step. The repository is archived and the project has moved into Orkes Conductor, so the decision is now about migrating rather than adopting.
- Who is it for?
- Agentspan is the wrong starting point for a new project: the README states the repository is archived and directs new users to the Conductor agent quickstart. It is still the right thing to read if you already have agentspan code in production, because the migration guide describes the change as one install line plus one import path, and pip install agentspan remains installable at 0.2.1.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 25 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Agentspan targets: agents that lose their place
An agent loop that lives inside a single process has a simple failure mode. The process dies, and everything the agent had done so far dies with it. For a chat turn that costs nothing. For a workflow that has spent forty minutes calling tools, waiting on a human approval, or holding a partially filled order, the cost is the whole run.
Agentspan's answer is to move the agent's progress out of the worker process and into a server. The README frames this as the project's one-line pitch: agents that do not die when your process does. The README states there is no timeout by default, that a run can last minutes or hours or wait for a human, and that if the worker crashes the server resumes from the last completed step when a new worker connects.
The audience follows from that. This is not aimed at someone prototyping a prompt. It is aimed at a team that already has an agent working in a demo and now needs it to survive a deploy, a pod eviction, or a three-day approval queue. The README also positions Agentspan as an execution layer rather than a framework replacement: it says you can pass an existing LangGraph, OpenAI Agents SDK, or Google ADK agent to runtime.run() and gain crash recovery, human-in-the-loop pauses, and execution history without rewriting the agent definition.
How the durable execution actually works
The mechanism is Conductor underneath. Agentspan is described as a durable runtime built for Conductor, and the README is explicit that Agentspan runs on Conductor, which is why every event source Conductor supports is available to agents. That single sentence explains most of the architecture: the agent is the new part, the durability, retries, and history are inherited.
There are three named pillars. Long-running agents are the crash-recovery story above. Dynamic agents use Strategy.PLAN_EXECUTE: the README says the planner emits a JSON plan once, and the server then compiles that plan into an immutable Conductor sub-workflow, so orchestration, retries, and parallelism contain no further LLM randomness. That is a deliberate trade: you give up the model's ability to re-plan mid-execution and get deterministic replay in return. The README also notes dynamic agents can call existing Conductor workflows as steps, which is the bridge to automation a team already has.
The third pillar is event-driven agents, triggered from cron schedules, Kafka topics, SQS queues, AMQP messages, webhooks, and database events. The README's example is a weekday-morning cron schedule passed to deploy(), and it states each trigger is a durable execution with full history. The repository layout matches the story: separate cli/, sdk/, server/, ui/, and deployment/ directories, with the SDK surface spanning Python, TypeScript, Java, and C#.
Installing Agentspan and running a first agent
The README's quickstart is a single install script. On macOS or Linux the documented command pipes the install script from the repository into sh:
curl -fsSL https://raw.githubusercontent.com/agentspan-ai/agentspan/main/cli/install.sh | shThe README also lists alternatives: an npm global install of @agentspan-ai/agentspan, a PowerShell script for Windows, a batch file for CMD, and building the CLI from source with go build inside cli/. It mentions agentspan doctor as a setup check.
For the SDK, the README installs a package named conductor-agent-sdk, not agentspan:
pip install conductor-agent-sdkThat naming is the migration in miniature, and it is the detail most likely to trip up someone following an older tutorial. The README's own note says pip install agentspan stays installable but that the final version on that name is 0.2.1.
Next you export a provider key and start the server, which the README says runs on localhost:6767 with a UI:
export OPENAI_API_KEY=sk-...
agentspan server startThen a complete agent, which the README says to run with python hello.py:
from conductor.ai.agents import Agent, AgentRuntime, tool
@tool
def get_weather(city: str) -> str:
"""Get current weather for a city."""
return f"72F and sunny in {city}"
agent = Agent(name="weatherbot", model="openai/gpt-4o", tools=[get_weather])
with AgentRuntime() as runtime:
result = runtime.run(agent, "What's the weather in NYC?")
result.print_result()The import path is conductor.ai.agents, and the model string is provider-prefixed. The README lists fifteen-plus providers in that format, from openai/gpt-4o to ollama/llama3, each with its own environment variable. Opening http://localhost:6767 is what shows the execution UI and, by implication, the step history the durability claim rests on.
Where Agentspan is the wrong tool
The most concrete limitation is the one the README leads with: the repository is archived and read-only, and the project merged into Orkes Conductor as of August 17, 2026. The final release is v0.4.4. Release assets remain downloadable and the PyPI name stays installable, but the README routes issues and contributions to conductor-oss/conductor. A team choosing a runtime today would be adopting a codebase that is no longer receiving changes here.
The second limitation is structural rather than administrative. Durability comes from running a Conductor server. That is a real operational component to run, monitor, and upgrade, and it is the reason a single-process agent library feels lighter. If your agent is one prompt and one tool call inside a request handler, the server is overhead you will never amortize.
The third is the Plan-Execute trade-off. Locking a plan into an immutable sub-workflow buys deterministic retries and parallelism, and it costs the ability to change course mid-run. An agent that needs to discover its own steps as it goes is fighting the design. The README also does not document rollback of a partially executed plan, and it does not state what happens to in-flight runs during a server upgrade; those are questions to take to the Conductor documentation rather than assume an answer for.
Agentspan versus LangGraph and Temporal
Two comparisons are worth making, because they are the ones people search for.
LangGraph is a graph-based agent framework. You define nodes and edges in Python or JavaScript, and the durability story is checkpointer-based within that framework's own runtime. Agentspan's README takes the opposite position on ownership: it calls itself the execution layer, not the replacement, and says you can pass a LangGraph agent to runtime.run() unchanged and gain crash recovery and history. So the honest difference is not which one writes better agent code. It is whether orchestration, retries, and history live in the framework or in a separate engine you can point other workloads at. If you already run Conductor for non-AI automation, Agentspan's event triggers and its ability to call existing Conductor workflows as steps make it the more natural fit. If you do not, LangGraph keeps the component count lower.
Temporal is the closer architectural relative: both make a workflow engine responsible for durable state and replay. The difference visible here is where the model sits. Agentspan's Plan-Execute path deliberately compiles the LLM's plan into a deterministic sub-workflow so the model is not in the retry loop, and its event-driven path reuses Conductor's handler ecosystem. Temporal's own AI integrations are a separate question this repository does not address, and the README makes no direct comparison, so treat that as something to evaluate against Temporal's documentation rather than against this README.
Maintenance, migration cost, and the MIT licence
The repository is not archived in the sense of being abandoned without a successor; it is archived because the work moved. The last push was on 2026-08-21, and the releases listed are v0.4.2, v0.4.3, and v0.4.4, all in July 2026. The README states the final release is v0.4.4 and that the Python package name agentspan stops at 0.2.1 while conductor-agent-sdk is the package to install.
For existing users the README describes the migration as small: one install line plus one import path for most code, with MIGRATION.md in the repository root as the detailed guide. That claim is worth verifying against your own code rather than trusting, because the size of the change depends on how much you touch. An agent that imports conductor.ai.agents and calls runtime.run() is close to the described case. An agent that reaches into Plan-Execute internals, or that depends on a specific release asset, has more surface to check.
The licence is MIT, per both the README badge and the LICENSE file in the repository root. MIT is permissive and permits commercial use and modification. It does not by itself tell you anything about the licence of the Conductor server you will run alongside, or about the terms of any hosted Conductor offering, so if your deployment depends on a managed service, read that service's terms separately. Nothing here is legal advice.
Upgrade cost going forward is the interesting part. Once you are on conductor-agent-sdk, your upgrade cadence follows Conductor, not this repository, and the README's pointer to conductor-oss/conductor/issues is where that conversation now happens.
Editorial conclusion
Agentspan is the wrong starting point for a new project: the README states the repository is archived and directs new users to the Conductor agent quickstart. It is still the right thing to read if you already have agentspan code in production, because the migration guide describes the change as one install line plus one import path, and pip install agentspan remains installable at 0.2.1. Before touching anything, open MIGRATION.md, confirm which SDK package your code imports today (conductor-agent-sdk versus the older agentspan package), and check whether your agent uses Strategy.PLAN_EXECUTE, since that is the feature whose behaviour you need to re-verify against Conductor rather than assume carries over.
Frequently asked questions
What is Agentspan?
It is a durable runtime for AI agents built for Conductor, described in the README as having three pillars: long-running agents, dynamic Plan-Execute agents, and event-driven agents. The repository is now archived and the project merged into Orkes Conductor.
What is agent architecture in AI?
The README does not define the term generally. It shows one concrete architecture: an agent defined in code, run through AgentRuntime, with the LLM emitting a JSON plan that the server compiles into an immutable Conductor sub-workflow for deterministic execution.
What is an agent in Python, in Agentspan's terms?
In the README's example it is an Agent object constructed with a name, a provider-prefixed model string such as openai/gpt-4o, and a list of tools decorated with @tool. It is then passed to runtime.run() along with the user prompt.
Community notes