opiniateddev

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/...

Conductor was moved here: https://github.com/conductor-oss/conductor Maestro uses conductor as its core.

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

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

An abstraction on top of Conductor: https://github.com/Netflix/maestro/blob/main/maestro-engine/...

Conductor was moved here: https://github.com/conductor-oss/conductor

This has been there for a while and is supported on all three clouds.

Orkes | Backed and Front-end Engineers | Full Time | Remote or Bay Area | https://orkes.io/careers/

Orkes offers cloud hosted version of Netflix Conductor (https://github.com/Netflix/conductor). We are the core developers and founders of Conductors prior to founding Orkes.

We are looking for engineers who are interested in building the platform used by many fortune 100 companies to build their distributed stateful applications.

In this role, you will constantly push the boundaries of what is possible in a distributed system and developer experience.

This is/was an awesome resource which helped me understand the basics of Linux installations, distributions. Used it to build really minimal distros.

We use Airflow at scale, I am kind of wondering why do we need something different to manage workflows. The advantage I see with Airflow is that its simple, BashOperator allows me to execute my code in any language that I have written and the DAG is very simple to understand and reason about. Not to mention the dependency management aspect of it.