Hi Conductor team 👋
Conductor is a battle-tested workflow orchestration engine with serious production credentials. I want to propose a different angle: not replacing Conductor, but showing how GNAP could serve as a lightweight coordination layer for AI agent sub-tasks within Conductor workflows.
The scenario:
Conductor excels at durable, event-driven workflow execution. But AI agent tasks within those workflows often need intra-agent coordination — multiple AI agents collaborating on a single Conductor task. Today that's typically handled ad-hoc (in-process, custom APIs).
GNAP fills the intra-agent gap:
When Conductor dispatches a task to an "AI agent worker," that worker might spawn sub-agents (researcher, writer, reviewer). GNAP provides a standard way for those sub-agents to coordinate without any new infrastructure:
Conductor Task → AI Worker → GNAP coordination
├── researcher agent
├── writer agent
└── reviewer agent
↓
Result → Conductor
Why GNAP + Conductor:
|
Conductor |
GNAP |
| Scope |
Macro workflows |
Agent micro-coordination |
| State |
PostgreSQL/Redis |
Git |
| Actors |
Workers/services |
AI agents + humans |
| Infrastructure |
Required |
Zero (just git) |
Together they cover the full stack: Conductor handles the durable workflow, GNAP handles AI team coordination within each workflow step.
Would love to discuss whether this layered architecture makes sense for Conductor's AI/agent use cases.
GNAP spec: https://github.com/farol-team/gnap
Hi Conductor team 👋
Conductor is a battle-tested workflow orchestration engine with serious production credentials. I want to propose a different angle: not replacing Conductor, but showing how GNAP could serve as a lightweight coordination layer for AI agent sub-tasks within Conductor workflows.
The scenario:
Conductor excels at durable, event-driven workflow execution. But AI agent tasks within those workflows often need intra-agent coordination — multiple AI agents collaborating on a single Conductor task. Today that's typically handled ad-hoc (in-process, custom APIs).
GNAP fills the intra-agent gap:
When Conductor dispatches a task to an "AI agent worker," that worker might spawn sub-agents (researcher, writer, reviewer). GNAP provides a standard way for those sub-agents to coordinate without any new infrastructure:
Why GNAP + Conductor:
Together they cover the full stack: Conductor handles the durable workflow, GNAP handles AI team coordination within each workflow step.
Would love to discuss whether this layered architecture makes sense for Conductor's AI/agent use cases.
GNAP spec: https://github.com/farol-team/gnap