AI agent orchestration
Orchestrate Agent Harness steps and MCP-operated workflows.
Dagu gives AI-assisted work a production workflow boundary: run Agent Harness steps through `harness.run`, let MCP-capable tools operate Dagu through the built-in MCP server, and keep logs, retries, approvals, and audit history in one place.
name: agent-review
schedule: "0 9 * * 1"
steps:
- id: collect_context
run: ./scripts/collect-release-context.sh
output: RELEASE_CONTEXT
- id: draft_notes
action: harness.run
with:
provider: codex
prompt: |
Draft release notes from this context:
${steps.collect_context.outputs.RELEASE_CONTEXT}
depends: [collect_context]
- id: human_review
run: ./scripts/request-approval.sh
depends: [draft_notes]Explicit external provider runtime
Run Claude, Codex, Gemini, OpenCode, or custom external agent CLIs
Expose workflow operations to MCP-capable tools
Keep human review, logs, retries, and artifacts in Dagu
At a glance
Dagu's role in an agent stack
Configured external CLIs through Agent Harness steps, plus MCP clients over HTTP.
Agent frameworks often couple orchestration to one runtime or model surface.
Schedules, retries, logs, artifacts, approvals, and reruns.
Prompt-only automation leaves these controls to custom scripts and conventions.
Workflow definitions, logs, and execution stay in your environment.
Hosted harnesses can make workflow state, credentials, and costs harder to control.
In depth
Where each tool fits
Use external agent commands, not a hidden runtime
Dagu keeps AI work explicit: workflow steps call the external agent CLI your team chooses through Agent Harness.
- Use `harness.run` for Claude, Codex, Gemini, OpenCode, Aider, or internal agent CLIs.
- Run the provider on the host or inside a controlled container sandbox.
- Swap models and external agent CLIs without changing the workflow engine.
Let MCP-capable tools operate Dagu
Dagu's MCP server remains built into the HTTP server. It lets approved clients inspect state, preview edits, apply DAG changes, and control runs through the same authenticated boundary as the API.
- Expose Dagu state and run controls without handing agents raw infrastructure credentials.
- Use `dagu_read`, `dagu_change`, and `dagu_execute` from MCP clients.
- Attribute MCP requests and downstream actions in audit history.
Keep production controls around AI work
Agent output still needs schedules, dependencies, retries, validation, and human review. Dagu treats those controls as workflow structure instead of prompt glue.
- Add approval steps before generated output reaches production.
- Capture stdout, stderr, artifacts, logs, and run history for review.
- Schedule recurring summaries, triage, cleanup, and QA workflows.
FAQ
Practical questions before adopting Dagu
Where does the agent run?
The agent runs outside Dagu: either as a configured external CLI launched by an Agent Harness step, or as an MCP-capable client operating a running Dagu server.
How is harness different from MCP?
Agent Harness runs the configured external CLI as a workflow step. MCP lets an external AI tool operate a running Dagu server: inspect workflows, preview or apply edits, and start, retry, enqueue, or stop runs.
Can Dagu run multiple agent providers?
Yes. A workflow can call different CLIs or custom harness definitions in different steps, and harness fallback entries can try alternate provider configs when a primary attempt fails.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.