Skip to content

GNAP: git-native agent coordination as a lightweight complement to Conductor workflows #866

@ori-cofounder

Description

@ori-cofounder

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions