Modular Agents Need a Drainable Work Graph, Not Just Better Prompts

This article extends Shipping a Drainable Workflow: Why Agent Work Should Have a Clear End with a component-level view: how to split a modular agent system so that unfinished work remains visible, reviewable, and safe to resume.

The module boundary is a work boundary

A common modular-agent design starts with roles: researcher, planner, writer, verifier, and publisher. That division is useful, but role names alone do not make a system modular. The important question is what crosses each boundary.

A good boundary carries a small work record:

• the input it accepted;
• the decision or transformation it performed;
• the artifact it produced;
• the next action, if any;
• and the reason it stopped.

That record turns a module from an opaque call into a drainable unit. The next module does not need to reconstruct what happened from chat history or hidden state. It can inspect the handoff and either continue, request review, or close the item.

This is especially important when modules are implemented with different tools. A research component may return citations, a writing component may create a markdown file, and a publication component may need a human approval. The interface between them should describe those concrete outcomes rather than merely saying “done.”

Prefer one-way progress with explicit holds

Modular systems often become tangled when every component can call every other component. A verifier can rewrite the draft; the writer can restart research; the publisher can ask the planner to change scope. The result is activity without a reliable end state.

A calmer design gives the work graph a mostly one-way shape:

1. collect or receive the source material;
2. transform it into a draft artifact;
3. verify the artifact against the task;
4. place external effects behind a review gate;
5. publish or close the work.

A module may return a hold instead of forwarding work. A hold is not an error. It is a durable state saying that progress depends on a missing fact, a human decision, or a failed check. The important property is that the hold is visible in the same place as successful handoffs.

For example, an article generator should be able to stop with “no sufficiently new source material found” rather than filling the draft directory with a generic essay. A publisher should be able to stop with “approval required” without attempting deployment. These stops preserve the integrity of the graph.

Give every edge a restart rule

A modular agent graph is only operationally useful if a partially completed item can resume without guessing. Each handoff should answer three practical questions:

• What has already happened?
• What must not happen again?
• What is the smallest next step?

The answers can live in a markdown artifact, a structured receipt, or a queue record. The format matters less than its durability and discoverability. A restarted worker should find the artifact by path or identifier, not by searching an unbounded conversation.

Idempotency is part of the restart rule. If the writing step already created articles/drafts/modular-agents-2026-09-14.md, a retry should verify or revise that file according to policy; it should not silently create three near-duplicates. Likewise, a publication step should distinguish “draft exists” from “publication completed.” Similar words must not collapse different states.

This is where modularity meets operations. A component can remain small and independently replaceable when its output is inspectable. Without that output, replacing the component requires reverse-engineering its hidden assumptions.

Keep review at the effect boundary

Not every module needs the same level of approval. Internal transformations can often run automatically when their outputs are bounded and verifiable. External effects deserve a separate boundary because they change the world outside the work graph.

A practical split is:

• prepare: generate a proposed message, file, or deployment payload;
• check: validate recipients, destination, format, and policy;
• review: obtain approval when the effect requires it;
• execute: perform the external action and record the result.

This lets modular agents move quickly through preparation without pretending that a draft is a send, or that a local file is a publication. It also keeps the approval decision attached to the exact proposed effect rather than to a vague promise that “the agent handled it.”

The same pattern works for a content pipeline. The article module may write a draft. A later site-publish job may move an approved copy into the published lane. The publish step can then record the URL or deployment result. Each module remains understandable because it owns one transition.

Measure the graph by what it leaves behind

A modular architecture should be evaluated by its residue, not its apparent autonomy. After a run, an operator should be able to answer:

• Which work items were completed?
• Which are waiting for review?
• Which stopped because evidence was missing?
• Which artifacts are safe to resume?
• Which external effects actually occurred?

These questions favor quiet, useful telemetry: paths, statuses, timestamps, identifiers, and concise reasons. They do not require a transcript of every model thought or a stream of speculative updates.

A small work log can be more valuable than a large dashboard if it links the outcome to the artifact that proves it. In practice, this also makes failures cheaper. A failed verifier can point to the draft and its failed check; a later run can address that specific gap instead of starting the entire workflow over.

Conclusion: design modules that can stop cleanly

The next step for a modular AI agent is not necessarily another role or a larger prompt. First make each existing boundary explicit: define the handoff, persist the artifact, state the stopping conditions, and separate preparation from external effect.

Then test interruption deliberately. Stop after research, after drafting, and before publication. Resume from the recorded state and confirm that the system does not duplicate work or skip review. Finally, inspect the work graph as an operator: completed, held, failed, and awaiting approval should be distinguishable at a glance.

Modular agents earn their flexibility when their parts can be replaced without losing the work. A drainable graph is the contract that makes that possible.