Agent Workflow Designer by Hand vs With an AI Agent

Designing an agent workflow by hand means one engineer turns a fuzzy goal into agents, tools, inputs, outputs and acceptance checks, usually across several documents and review rounds. With an AI agent, the same job starts from the goal: our dw-agent-workflow-designer skill, run by the Orchestration Agent, turns a fuzzy business goal into a concrete, tool-grounded multi-agent workflow with explicit inputs, outputs and acceptance checks. A person still approves the result before anything runs.

Key Takeaways

• •The hard part of workflow design is not drawing boxes. It is making every step name its tool, its inputs, its outputs and the check that says it worked.
• •By hand, that specification work lives in one engineer's head and in documents that drift from what actually runs.
• •The dw-agent-workflow-designer skill produces the specification from a goal, grounded in the tools that are actually connected, so the design matches what can execute.
• •A human still owns the goal, approves the design and decides how much autonomy each domain gets.
• •Evaluate any agent for this job by whether its output is testable: explicit acceptance checks, named tools, and a design you can reject without rework.

Agent workflow designer by hand vs with an AI agent: the job

The job starts with a goal stated in business terms, such as "keep the orders data trustworthy for finance" or "get new sources into the warehouse without a ticket queue." Someone has to turn that sentence into a workflow that several agents, or several people and agents, can execute without guessing. Today that someone is usually a senior data engineer or a platform lead, because the work needs knowledge of the warehouse, the orchestrator, the catalog and the access rules.

The output of the job is a specification, not code. Each step needs a defined input, a defined output, a tool that performs it and an acceptance check. Anthropic's guidance on building effective agents makes a related point: workflows with predefined paths and agents that direct their own tool use are different designs, and the choice between them is a design decision to make explicitly. Making that decision per step is the core of the work.

The manual workflow, step by step

This is the sequence we see teams follow when they design a multi-agent workflow without an agent doing it. The details vary, but the shape is consistent.

• •Clarify the goal. The engineer interviews the requester, because the first statement of the goal is rarely testable.
• •Inventory the tools. They list which systems exist, which have an API or an MCP server, and which are reachable from the environment where the workflow will run.
• •Decompose the goal into steps and decide what each step needs as input and produces as output.
• •Assign each step to a role or an agent, and decide the handoffs between them.
• •Write acceptance checks per step, so a failure is detected where it happens and not three steps later.
• •Review with the people who own the affected systems, then revise.
• •Translate the design into configuration, prompts or code, and keep the document in sync afterward.

Where it breaks is predictable. The tool inventory goes stale, so the design names a step that no connected tool can perform. Acceptance checks get written last and thinly, because the design feels finished once the boxes are drawn. Handoffs stay implicit, so one step's output does not match the next step's expected input. And the design document stops matching reality after the first change to the workflow.

What an agent does instead

We describe the skill only as far as its definition goes. The dw-agent-workflow-designer skill belongs to the Orchestration Agent, the swarm coordinator that delegates work across our other agents. Its purpose is to turn a fuzzy business goal into a concrete, tool-grounded multi-agent workflow with explicit inputs, outputs and acceptance checks.

Each phrase in that description maps to a failure in the manual process. "Tool-grounded" addresses the stale inventory: the workflow is built against tools that exist, not tools the author remembers. "Explicit inputs, outputs" addresses implicit handoffs. "Acceptance checks" addresses the habit of writing them last. Because every Data Workers agent is an MCP server, the same designer runs from Claude Code, Cursor or any MCP-compatible client, so the design is produced where the engineer already works. The Model Context Protocol specification defines how those tools are exposed to a client.

We do not claim a time saving here. We have no attributed benchmark for design time, and effort varies with how well the goal is stated. What changes qualitatively is where the effort goes: less on assembling the specification, more on judging whether it is right.

Manual vs agent, side by side

What still needs a human approval

A generated design is a proposal. Four decisions stay with people, and we would not automate them.

• •The goal itself. An agent can sharpen a fuzzy goal, but only the business owner knows whether the sharpened version is what they meant.
• •Approval of the design before it runs. Our open-source edition is read-only by default, and Pro adds writes with approval workflows and audit trails, so a design that proposes writes passes through that gate.
• •Autonomy per domain. The Autonomous Data Conductor has a per-domain autonomy dial, so a team can let one domain run on its own and keep another on manual approval.
• •Access and PII boundaries. Which agent may touch which data is a policy decision owned by governance, not a by-product of design.

We covered how the Autonomous Data Conductor and its autonomy dial work in a separate post on autonomous data operations. The relevant point here is that the designer decides what a workflow does, and the dial decides how much of it runs without asking.

How to evaluate an agent for this job

Whatever tool you consider, test it on a goal you already designed by hand. You know the right answer, so you can score the agent against it. We use these questions.

• •Does every step name the tool that performs it, and does that tool exist in your environment?
• •Does every step have an input, an output and an acceptance check you could run?
• •Can you reject one step without redoing the whole design?
• •Does it say what it does not know, such as a system it cannot reach, instead of inventing a step?
• •Does it run inside the client your engineers already use, so the design lands in version control and not in a separate dashboard?
• •Do its permissions match your policy, with reads by default and writes behind approval?

If you work in Claude Code, the Claude Code documentation covers how it connects to MCP servers. Our Orchestration Agent plugs into it the same way as the rest of the swarm, and our pages on running Data Workers from Claude Code show the setup.

When doing it by hand is still the right call

Designing by hand is reasonable when the workflow is small, a single agent covers it, or the team is still learning what its own processes are. Writing the specification yourself forces you to understand each step. If the goal touches one tool and has one obvious check, a document is faster than any agent. The case for the skill grows with the number of systems, handoffs and owners involved, because that is where specifications drift and handoffs go missing.

Frequently Asked Questions

What does the dw-agent-workflow-designer skill do? It turns a fuzzy business goal into a concrete, tool-grounded multi-agent workflow with explicit inputs, outputs and acceptance checks. It belongs to the Orchestration Agent, which coordinates our other agents.

Does an agent replace the engineer who designs the workflow? No. The agent produces the specification, and the engineer or data lead approves, amends or rejects it. The goal, the approval and the autonomy level per domain remain human decisions.

How much time does designing a workflow with an agent save? We do not publish a figure because we have no attributed benchmark for design time. The effort shifts from assembling the specification to reviewing it, and you can measure the difference yourself by designing one known workflow both ways.

Can the designed workflow run without approval? Only if you allow it. The open-source edition is read-only by default, Pro puts writes behind approval workflows with audit trails, and the Autonomous Data Conductor lets you set autonomy per domain.

Which clients does it work with? Every Data Workers agent is an MCP server, so it works from Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot or any MCP-compatible client.