opiniateddev

OSS Conductor does not support idempotency keys. Orkes Conductor which is an enterprise SaaS does however, support idempotency keys.

The open source continues to live: https://github.com/conductor-oss/conductor

A software SDLC harness that can run complex long horizon coding projects.

https://github.com/conductor-oss/conductor-agents/tree/main/...

Open for collaboration, still in early dev.

Given the recent history of outages, I wonder how many are seriously considering moving off GitHub for anything other than code hosting. I mean actions / workflows.

for our production we use Redis for queues but have seen users using both Postgres and MySQL for queues as well.

Conductor OSS does this quite well https://docs.conductor-oss.org/devguide/ai/index.html

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.

I'm working on Agentspan: https://github.com/agentspan-ai/agentspan

It's a durable runtime for AI agents.

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.

Do you want to work on distributed systems? We are building the stack for running agents in production.

https://github.com/agentspan-ai/agentspan

Apply: https://job-boards.greenhouse.io/orkes/jobs/4998231008

https://job-boards.greenhouse.io/orkes/jobs/4894213008

https://job-boards.greenhouse.io/orkes/jobs/5203462008

All the roles are in in-office in Sunnyvale, CA

Why not just use https://github.com/conductor-oss/python-sdk provide durability, distributed and orchestration.

Agentic guardrails should be deterministic and algorithmic as opposed to using LLM or relying on LLMs.

The moment you rely on LLM to be a guardrail, well you are risking it to fail.

Author here, built Netflix Conductor.

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.

Repo: https://github.com/agentspan-ai/agentspan

Runtime for agents https://github.com/agentspan-ai/agentspan Built on top of Conductor OSS - https://github.com/conductor-oss/conductor

take a look at https://github.com/conductor-sdk/conductor-python which is easier and will not force you to write with specific framework.

how is it different from Conductor? https://github.com/conductor-oss/conductor

Maestro is a domain specific implementation for ML and data pipelines that uses Conductor as its core

https://netflixtechblog.com/orchestrating-data-ml-workflows-...

https://github.com/Netflix/maestro/blob/main/maestro-engine/...