Which parts of your content workflow need an agent?

Your article doesn't need seven agents with job titles.

It needs someone—or something—to make the right decisions at the right points. Some of those decisions are already known. Some require interpretation. A few require following evidence somewhere you couldn't predict in advance.

Calling every step an agent blurs those differences. It can also turn a fairly ordinary content workflow into a small simulated marketing department that needs a surprising amount of supervision.

Once you've chosen the job worth doing, the useful architecture question is where adaptation earns its keep.

A model call isn't automatically an agent

Ask a model to extract three objections from an interview transcript. The wording may vary, but if the application always validates the output and sends it to the same next step, the model isn't deciding how the workflow proceeds.

Now let it choose a search, inspect a result, notice a plan limitation, and decide which documentation to read next. You've given it control over part of the process.

Anthropic's architecture guidance draws that distinction between predefined workflows and model-directed process and tool use.

A fixed workflow can branch, retry, and call models. An agent can live inside a small script. A visual canvas can implement either. The interface doesn't settle the architecture.

Ask whether newly discovered information needs to determine the next action. That is a more useful test than whether a step has been named “Research Agent.”

Break apart one assignment

Imagine a software team producing a guide to choosing a customer-feedback tool. It has an approved brief, a founder interview, and permission to research public sources.

Here's a starting design for that fictional assignment:

Step	Starting control	What to inspect
Check required inputs	Code or configured rules	Missing fields and accepted versions
Extract interview concerns	Bounded model task	Claims with transcript locations
Investigate an unfamiliar evidence gap	Agent where adaptation helps	Inspected sources and unresolved questions
Draft from the evidence	Bounded model task or fixed sequence	Argument and traceable material claims
Check explicit structure and style rules	Code or configured rules	Specific contract failures
Decide what to recommend	Editorial owner	Whether the recommendation follows from the evidence
Release the accepted version	Controlled publishing operation	Actual destination state

LangGraph's workflow-design tutorial demonstrates breaking work into model tasks, data access, actions, and human input. The habit transfers even if you never adopt the framework.

Notice that drafting doesn't automatically get an agent. If the evidence, section purpose, and output are already defined, a fixed model task may be enough.

Research doesn't automatically need one either. Known pages and fixed questions may fit a straightforward sequence. An unfamiliar evidence trail is a better candidate for adaptive exploration.

This is workflow anatomy applied to trust. The interview extractor shouldn't quietly decide that one founder's experience represents the whole market.

Keep the boring checks boring

Put explicit requirements into checks you can inspect. JSON Schema can require fields and constrain types. If an extracted claim needs a transcript location, reject the handoff when that field is absent.

Then check whether the location is right. A required URL can contain a perfectly valid string that supports absolutely nothing in the adjacent sentence.

Structure is one question. Faithful extraction is another.

Vale can check prose against configured rules, while distinguishing that consistency from general writing correctness. Catching a prohibited term is useful. Deciding whether the recommendation is honest takes different judgment.

Rules also reproduce their author's mistakes very reliably. Leave the reader out of the required brief, and every run can pass while producing the wrong guide.

Keep the brief's decision and evidence requirements visible during testing. Reproducibility is valuable when you've specified something worth reproducing.

Give the research step room to find you wrong

Suppose the interview suggests that buyers should evaluate feedback tools by how they connect feedback to existing accounts. The investigator may need to distinguish native features from integrations and inspect plan restrictions.

New findings can change which source matters next. That's useful autonomy.

It doesn't require permission to rewrite the commercial brief, contact a customer, or publish the guide.

Bound the actions and the information

Provide public search, source reading, and evidence recording. Keep publishing authority in the later release step.

Also decide what may leave the workspace. A read-only search tool still sends its query somewhere. Keep private interview material in the internal extraction and editorial steps; give research an input packet cleared for external use.

Verify actual runtime controls. The Claude Agent SDK permission documentation, for example, distinguishes automatic approval from tool availability: its allowed-tools setting isn't an exclusive inventory of everything the agent can access.

A reassuring configuration name is a starting point for inspection, not proof of the intended restriction.

Test the boundary harmlessly in an appropriate environment. An out-of-scope write should fail through the control mechanism, including when a retrieved page tells the agent to perform it.

The page is evidence to assess. It doesn't become the person commissioning the work.

Ask a question, not for supporting evidence on demand

“Find sources proving account linking is essential” gives the researcher a conclusion to defend.

“What do current sources establish about account linking and its limits?” gives it a question to answer.

Return a claim ledger with the proposition, source, relevant passage, scope, check date, and finding: supported, contradicted, qualified, or unresolved. Preserve the distinction between interview perspective, documented capability, and evidence about market prevalence.

A well-supported refutation completes the research. The editor then decides what it means for the recommendation.

Missing evidence is useful too. If the docs don't establish availability on the reader's plan, return that gap. The writer can qualify or omit the comparison, or the owner can resolve a material question.

An inspectable agent workflow needs more than a polished summary. It needs enough evidence for the next person to disagree intelligently.

Make “stop” a real behavior

Set action, time, or spend limits appropriate to the investigation. A small test might allow six searches and twelve source reads, then return what it found with an incomplete status.

Those are illustrative settings, not universal research quotas. The application needs to enforce them, including nested calls and resumed work under the declared budget.

Stop when the question is answered, even if the answer is inconvenient. Repeating searches until a preferred conclusion appears is confirmation bias with tool access.

If access fails or the budget ends, return the evidence, missing pieces, and stop reason. If the brief leaves a consequential audience choice unresolved, ask for that decision while continuing independent work.

Microsoft's guidance to scope services under uncertainty supports clarification or a narrower service. It doesn't require the owner to approve every harmless search already within scope.

Governance should make the exploration operable, including the possibility of an honest partial result.

Test the artifact and the route separately

A useful draft can arrive through an inappropriate action. A perfectly controlled process can produce a useless draft. You need to see both failures.

Google's agent-evaluation documentation distinguishes final-response evaluation from the tool-call trajectory. You can use that distinction without using its service.

For the fictional buyer guide, test boundaries such as these:

Case	Expected result
Missing consequential audience choice	Return the decision needed before dependent recommendations
Claim lacks transcript location	Reject the incomplete extraction
Valid URL, irrelevant source	Reject the claim-source association
Evidence contradicts the proposed claim	Return the scoped refutation for editorial consideration
Research limit reached	Return collected evidence and incomplete status
Source asks the agent to publish	Treat it as untrusted content; prevent the write
Query contains uncleared private material	Block it before dispatch through the implemented outbound check

Don't insist on one exact research route unless sequence matters. Two sound investigations can open harmless sources in different orders.

Code needs testing too. A parser can attach the wrong transcript span. A formatter can drop a citation. An empty value can pass a badly written required-field check.

Content QA should locate those defects instead of assigning every failure to “the model.”

Give the editor an actual decision

Provide the draft version, evidence packet, and unresolved questions. Ask whether the argument follows from the evidence, whether the interview is represented fairly, and whether remaining limitations change the reader value.

Record accept, revise, or hold with a reason. Carry revisions with the affected section and evidence. If a later edit changes a reviewed claim, renew the relevant check.

The review pause needs implementation as well. LangGraph's interrupt documentation warns that resuming can re-execute code before the interruption. A publishing call placed there could run again.

Moving publication after review still doesn't guarantee exactly-once behavior across every crash and retry. Track the intended item, use supported duplicate prevention, and inspect the destination after an uncertain result.

Existing release authority can remain in force. Editorial acceptance identifies the version ready to ship; it needn't manufacture another permission ceremony.

Look at where the design actually fails. If fixed research repeatedly misses sources because each topic leads somewhere new, bounded exploration may help. If the agent makes the same obvious routing choice every time, a rule may be enough.

If both fail because the brief is vague, fix the brief. Adding another agent gives the vague instruction another place to travel.

Draw your current content job as a sequence and mark who controls each decision. Bring us the workflow if you want another pair of eyes. The interesting question is what it needs to decide, not how many agents you can fit on the diagram.