Solo Agency Pipeline: Where Agents End and You Begin

Most write-ups of an agent-run agency describe the stack first and the seams last. This one starts at the seam. What follows is a single operator’s content-to-delivery pipeline — she sells written content and small automation builds to B2B clients — mapped by who actually owns each stage, and where the routing between stages produces the errors.

The pipeline, stage by stage

The setup is unremarkable: one person, a chat window with a frontier model, a workflow tool for the client-facing automations, and a folder per client. She picked one orchestrator early and stopped migrating, which is the argument made in the automation framework guide and the reason her prompts stay stable long enough to be worth tuning.

The pipeline runs from discovery call to delivered asset plus a short handover document. Each stage has exactly one owner at a time, because shared ownership is how work gets dropped.

The last column is the point. On paper every stage is covered. In practice the failures cluster at the transitions, not inside the stages — which is exactly what a division-of-labour diagram hides.

Where the handoffs break

Three failure modes recur often enough to design around.

Acceptance criteria that exist only in the prompt. The brief agent produces something reasonable; the draft agent reads it and fills every unstated decision with a default. Defaults are not wrong, they are just unpriced. The fix is a schema the agent must fill and a program can reject before anything expensive runs.

{
  "client": "northwind-freight",
  "deliverable": "onboarding-email-sequence",
  "acceptance": {
    "length_per_email_words": [120, 180],
    "tone_source": "discovery-transcript.md",
    "required_claims": ["pricing page URL", "support hours"],
    "banned": ["discount figures", "delivery-date promises", "competitor names"]
  },
  "agent_may_decide": ["subject line variants", "section order"],
  "human_must_approve": ["claims", "pricing mention", "final send"],
  "approved_by": null
}

That file is the contract. The draft agent is not allowed to run until approved_by holds a name, and the banned list is checked by code, not by the reviewer’s attention.

Regeneration instead of editing. Ask for a fix and most agents return a whole new file. The reviewer then re-reads the entire artifact rather than the change, and any earlier decision the prompt did not restate quietly disappears. Force patches, keep the previous version, and review the diff.

Silent tool substitution at build. During the automation build, an agent will reach for whatever tool it has credentials for, even when the brief names a different one. This is the same class of problem described in builder vs plain script: the choice is a decision, not an implementation detail, and it belongs to the operator.

A gate script keeps all three honest before the expensive run:

#!/usr/bin/env bash
set -euo pipefail
brief="$1"

jq -e '.approved_by != null' "$brief" >/dev/null \
  || { echo "FAIL: brief not approved"; exit 1; }
jq -e '.acceptance.required_claims | length > 0' "$brief" >/dev/null \
  || { echo "FAIL: no verifiable claims listed"; exit 1; }
jq -e '.acceptance.banned | length > 0' "$brief" >/dev/null \
  || { echo "FAIL: no banned list"; exit 1; }
jq -e '.acceptance.length_per_email_words' "$brief" >/dev/null \
  || { echo "FAIL: no length bound"; exit 1; }

echo "OK: generating"

Run it as the first step of the pipeline, not as a note in a checklist. A gate you have to remember is not a gate.

Review is the line item the playbook underweights

Every division-of-labour diagram assigns review to the human in one clean box. The box is where the schedule actually dies, for three reasons.

First, reading is not verifying. Verification means opening the transcript page or the client’s pricing page and checking the claim yourself. The agent cannot do that check for you, because the agent has already asserted the answer; asking it to confirm its own output tests consistency, not truth.

Second, review cost scales with the number of claims, not the length of the output. Four hundred words containing six factual assertions cost more to clear than fifteen hundred words of opinion. This is why “the agent writes faster” rarely shortens the delivery date — it moves the bottleneck to the end of the pipeline, where the deadline is.

Third, agents hand you rewrites when you want edits. If the diff includes paragraphs you already approved, you are reviewing from scratch and paying twice for the same decision.

import difflib, pathlib

old = pathlib.Path("v1/deliverable.md").read_text().splitlines()
new = pathlib.Path("v2/deliverable.md").read_text().splitlines()

diff = list(difflib.unified_diff(old, new, fromfile="v1", tofile="v2", lineterm=""))
print("\n".join(diff) if diff else "no change")
# If the diff is much larger than the change requested, reject and re-prompt.

What actually helps is moving the review earlier and narrowing the artifact. Approving a structured brief takes a fraction of the time of repairing a draft, and it is a decision-shaped task rather than an edit-shaped one. Logging input, decision and output for each stage — the pattern in adding observability to a workflow — makes the second review of the same artifact cheaper, because you can see what changed and why.

The division of labour, corrected

The playbook’s core claim holds up: keep the human at decisions, hand transformation to agents, and keep the loop short enough that a mistake is cheap to unwind. Scope, claims, credentials and the send button are human. Drafting, transcription, scaffolding, formatting and log assembly are agent work. The orchestrator choice matters less than picking one and staying on it long enough to know its failure modes.

Where any solo-delivery playbook underestimates the problem is review. Agent capacity is not the constraint, and adding another agent to the pipeline does not add review capacity — it adds artifacts, each with its own verification floor. A pipeline that produces more deliverables per week produces proportionally more claim checks, and those do not compress with better prompting.

The honest correction is to treat review as a scheduled stage with its own budget, counted in claims verified rather than hours estimated, and to reduce the number of artifacts that need a fresh read by making the brief airtight and the revisions diff-shaped. The pipeline does not fail because an agent cannot write. It fails because the operator plans for writing time and pays for review time.

What to do next

1. Write the brief schema this week, with approved_by, a banned list and at least one field a program can validate. Every downstream agent reads that file and nothing else.
2. Move the gate into code. Put the jq check above in front of your generation step so an unapproved brief fails loudly instead of producing a draft you will not send.
3. Force diffs on every revision. If the returned diff covers more than the requested change, reject it and re-prompt with the specific sections to touch.
4. Count verifications, not hours. For each deliverable, list the factual claims and note who confirmed each one against a source. If nothing was confirmed, the review did not happen.
5. If you want the written version of this loop, The One-Person Studio is a 5-page PDF playbook for running an AI automation studio solo — mindset, core stack, orchestrator choice and the solo delivery loop — for $12 one-time at https://slashmaster6.gumroad.com/l/one-person-studio. Read it for the loop structure, then add the review budget it does not spell out.

Get The One-Person Studio

The One-Person Studio — $12, one-time payment, instant download. See the full breakdown on the review page.

Related reading

• The Ultimate Guide to AI Automation 2026
• How I Built a 10-Product Digital Business
• Building an AI Content Factory