Summary
Two complementary developer experience features that make Conductor workflows easier to author and observe:
-
A standard skill kit for authoring Conductor workflows — a curated library of pre-built skills (sub-workflows, validation helpers, scaffolding tools) that help users or AI agents create, debug, and iterate on Conductor YAML definitions.
-
An MCP server exposing Conductor's own state — so external AI agents can query JSONL event logs, inspect node I/O, gather session/state information, traverse the plan's logical tree, and interact with running or completed workflows.
Motivation
Authoring skill kit
Creating Conductor workflows today requires manually writing YAML with knowledge of the schema, agent types, routing semantics, and context flow. An AI agent helping a user write workflows has no structured tooling — it's working from docs alone. A standard skill kit would provide:
- Starter scaffolds — common workflow patterns (review loops, fan-out/fan-in, gated pipelines) as reusable sub-workflows
- Validation skills — a skill that validates a workflow definition, checks for common pitfalls (unreachable agents, missing context keys, infinite loop patterns)
- Debug/dry-run helpers — skills that trace execution paths or simulate routing without invoking providers
Sub-workflow support (#79) provides the runtime mechanism. The proposed registry design (docs/design/registry.md) provides the distribution channel. This feature request is for the content layer — the actual skills themselves, designed to be consumed by both humans and AI agents.
MCP server for introspection
Important distinction: Conductor today consumes MCP servers as a client (docs/mcp-tools.md). This proposes Conductor exposing an MCP server so external agents can query Conductor itself.
Today, understanding what happened in a workflow run means manually parsing JSONL log files (as evidenced by the debugging approach in #116, and the log attribution needs in #16). A Conductor MCP server would formalize this as structured tool calls:
- Log querying — search/filter JSONL event logs by agent, event type, time range, iteration
- State inspection — get current workflow state, node statuses, context values for a running or completed session
- I/O inspection — retrieve agent inputs, outputs, rendered prompts, tool calls for any node
- Plan tree traversal — navigate the workflow's logical structure (agents, routes, parallel groups, for-each groups) with the ability to drill into any node
- Session management — list sessions, compare runs, identify regressions
This would enable powerful AI-assisted debugging: "Why did the reviewer loop 20 times?" becomes a question an agent can answer by querying the event log and plan tree, rather than requiring a human to grep log files.
Suggested MCP Tool Surface
# Log queries
conductor_events(session_id, filters?) → filtered event stream
conductor_agent_history(session_id, agent_name) → all events for an agent
# State / I/O
conductor_session_state(session_id) → current context, node statuses
conductor_node_detail(session_id, agent_name) → inputs, outputs, prompt, tools used
conductor_sessions(filters?) → list/search sessions
# Plan tree
conductor_plan_tree(workflow_path) → logical structure with agent types, routes, groups
conductor_plan_node(workflow_path, agent_name) → node definition + connections
Prior Art & Cross-References
Environment
Summary
Two complementary developer experience features that make Conductor workflows easier to author and observe:
A standard skill kit for authoring Conductor workflows — a curated library of pre-built skills (sub-workflows, validation helpers, scaffolding tools) that help users or AI agents create, debug, and iterate on Conductor YAML definitions.
An MCP server exposing Conductor's own state — so external AI agents can query JSONL event logs, inspect node I/O, gather session/state information, traverse the plan's logical tree, and interact with running or completed workflows.
Motivation
Authoring skill kit
Creating Conductor workflows today requires manually writing YAML with knowledge of the schema, agent types, routing semantics, and context flow. An AI agent helping a user write workflows has no structured tooling — it's working from docs alone. A standard skill kit would provide:
Sub-workflow support (#79) provides the runtime mechanism. The proposed registry design (
docs/design/registry.md) provides the distribution channel. This feature request is for the content layer — the actual skills themselves, designed to be consumed by both humans and AI agents.MCP server for introspection
Today, understanding what happened in a workflow run means manually parsing JSONL log files (as evidenced by the debugging approach in #116, and the log attribution needs in #16). A Conductor MCP server would formalize this as structured tool calls:
This would enable powerful AI-assisted debugging: "Why did the reviewer loop 20 times?" becomes a question an agent can answer by querying the event log and plan tree, rather than requiring a human to grep log files.
Suggested MCP Tool Surface
Prior Art & Cross-References
docs/design/registry.mddocs/design/registry.md— Proposed registry system: natural distribution home for the skill kitEnvironment