Workflows Are the New Interface for Coding Agents

#ai #productivity #programming #tooling

Claude Code Dynamic Workflows are the clearest signal yet that the coding-agent market is moving past chat.

That is good news. From our own experience using workflows with Atomic for the past few months, it is the only way we work now. A single agent turn is the wrong shape for a migration, a security audit, a repo-wide bug hunt, or a plan that needs adversarial review before anyone trusts it.

That shift matters more than the specific product announcement. The future is not just better models. It is better control planes around models.

Why workflows matter

Software engineering is not one action. It is a sequence of judgment-heavy phases:

understand the system,
choose the work surface,
write or update a plan,
implement in bounded chunks,
verify with tests and reviewers,
leave artifacts the next engineer can trust.

Chat can imitate that sequence. A workflow can enforce it.

Subagents and skills are useful building blocks, but the goal is a workflow that owns the loop: branching, retries, review gates, and intermediate state. Intermediate results should not all be dumped into one context window. Reviews should be independent. Long-running work should be observable while it runs.

But once the plan becomes code, the next question is: who owns that code?

Claude Code Dynamic Workflows: impressive, but Claude-centered

Dynamic Workflows are impressive because they make orchestration feel native: describe a task, let the runtime fan out work in the background, and inspect progress through /workflows. The headline use cases are exactly where workflows shine: codebase-wide audits, large migrations, cross-checked research, and critical plans that need multiple attempts and adversarial review.

But the product shape is still Claude-centered. Claude writes the workflow, Claude runs it, and Claude decides a lot of the orchestration. Public docs also describe real boundaries: research-preview status, higher token use, session-scoped resume, limited mid-run user input, and workflow scripts that coordinate agents without direct filesystem or shell access.

For many teams, that will be enough. For engineers who want the workflow layer to be their own infrastructure, it leaves an opening.

Atomic: workflows as developer-owned infrastructure

Atomic starts from a different premise: the workflow is not an implementation detail of the assistant. It is the interface the developer should own.

The repo describes Atomic as “the workflow layer for coding agents” and a programmable control plane where the model-backed session does the work, but Atomic makes sure it follows the process. Under the hood, Atomic is a TypeScript/Bun monorepo built on Pi packages. The CLI bundles first-party packages for workflows, subagents, MCP, web access, and intercom. That matters because Atomic is not just a prompt convention. It is an extensible runtime.

A workflow in Atomic is a TypeScript module:

import { defineWorkflow } from "@bastani/workflows";

export default defineWorkflow("review-changes")
  .input("target", { type: "text", required: true })
  .run(async (ctx) => {
    const research = await ctx.task("research", {
      prompt: `Map ${ctx.inputs.target}`,
    });
    const reviews = await ctx.parallel([
      {
        name: "correctness",
        prompt: "Review for regressions",
        previous: research,
      },
      { name: "risk", prompt: "Review edge cases", previous: research },
    ]);
    return { reviews };
  })
  .compile();

The important part is not the syntax. It is the contract. Atomic exposes tracked stages, parallel branches, context handoffs, artifacts, human input through ctx.ui, resumable run control, model fallback chains, reusable worktrees, and package distribution. Workflows can live in .atomic/workflows/ for a project, ~/.atomic/agent/workflows/ for a user, settings, or packages. They are inspectable files, not just successful conversations you saved after the fact.

The built-in Atomic loop

Atomic already ships with the workflows engineers usually end up rebuilding by hand:

Workflow	Use it when
`deep-research-codebase`	You need a broad repo investigation with scout, specialist waves, aggregation, and durable research artifacts.
`goal`	You have a bounded change with explicit done criteria, validation, receipts, and reviewer quorum.
`ralph`	You want a larger plan-to-PR loop: RFC, implementation, simplification, infra discovery, review, and handoff.
`open-claude-design`	You are doing UI/design work that benefits from generation, critique, live preview, and quality gates.

The canonical Atomic flow is straightforward, and you can invoke it conversationally instead of memorizing slash commands:

Run deep research to map payment retry behavior across this repo.
Create a spec from research/payment-retries.md.
Use goal to implement the spec and run the focused retry tests.
For larger work, run ralph to plan, implement, review, and prepare a PR for the spec.

That gives engineers a process they can inspect: research files, specs, ledgers, worker receipts, reviewer decisions, final reports. If the work fails, you are not left with “Claude tried.” You have artifacts that explain where it failed.

And if that is not your process, you write your own. Incident response, release readiness, dependency audits, migration scoring, accessibility review, docs QA, benchmark triage: the workflow surface is general-purpose.

The deeper difference: control, visibility, confidence

Claude Code Dynamic Workflows make orchestration easier to ask for. Atomic makes orchestration easier to own.

That distinction shows up in four places:

Concern	Claude Code Dynamic Workflows	Atomic
Workflow authoring	Claude dynamically creates orchestration scripts for the current task; successful runs can be saved back into Claude Code.	Developers can ask Atomic to use a workflow, describe new workflows in natural language for Atomic to scaffold, or version explicit TypeScript workflows as repo-owned code.
Human gates	No mid-run user input; split stages into separate workflows when sign-off is needed.	Developers can define explicit human-in-the-loop gates, attach to running sessions to steer them, and pass or reject gates before the workflow continues.
Cost and scale	Designed for large fan-outs, including tens to hundreds of subagents; Anthropic notes this can consume substantially more tokens than a typical Claude Code session.	You choose the graph and concurrency. Atomic can stay small and deterministic, or scale out when you intentionally design a broader workflow.
Provider choice	Built for Claude Code and Claude-supported surfaces.	Model/provider agnostic through Pi: Anthropic, OpenAI, Gemini, Bedrock, OpenRouter, local OpenAI-compatible servers, custom providers, and more.
Extension surface	Workflow runtime plus Claude Code ecosystem.	Pi packages can add extensions, tools, slash commands, skills, prompt templates, themes, TUI components, and workflows.

There is also a practical supply-chain detail worth saying carefully. Atomic’s published CLI package does not require install lifecycle scripts, and the README explicitly says you can install it with --ignore-scripts. That is a safer default for a tool you install globally.

It does not mean arbitrary third-party Atomic packages are magically safe; Atomic’s own docs warn that packages and extensions run with full system access. The point is narrower and useful: the base tool keeps the core install simpler, while still letting teams review and choose the extensions they trust.

What engineers should internalize

Workflows are not only for giant rewrites. Use them whenever process fidelity matters more than conversational flexibility:

broad research where findings should become durable memory,
risky changes that need independent review,
migrations with repeated file-level work,
tasks where validation must be captured as evidence,
team processes you want every agent run to follow the same way.

Use chat for exploration. Use subagents for delegation. Use workflows when the process is part of the product.

Claude Code Dynamic Workflows validate the category. They show that serious agentic coding requires scripts, background execution, parallelism, and cross-checking. Atomic pushes the same idea one layer closer to the engineer: workflows as open, inspectable, model-agnostic infrastructure you can keep in the repo, modify, package, review, and run again.

That is where coding agents are going. The winners will not be the tools that hide the workflow best. They will be the tools that make the workflow visible enough for engineers to trust.