AI Workflow Automation: When to Split the Work, and When Not To

The worst failure I have had with a folder full of helpers did not announce itself. It reported success.

Late July 2026. I had a batch job to run across 167 existing articles — insert one bridging paragraph into each, ten helpers working in parallel. The job finished. Green all the way down. Nothing on the live site had changed.

The file finder had taken the first recursive match. Dot-prefixed directories sort before letters, so a dead archived copy shadowed the real file. Every one of those helpers had written its paragraph into a file nobody reads, and every one of them returned a success code for doing it.

That batch turned up six bugs in one night. Five were the ordinary kind — a paragraph landing above a summary block instead of below it, a duplicate-detection check that misjudged already-processed articles, ten phantom entries that were archived drafts wearing live filenames. Those you find because the output looks wrong.

The sixth is the one worth building a folder structure around, because you cannot find it by reading the output. The output was fine. It went to the wrong place.

I hit the same shape again a few weeks later in a different tool. A fleet-control utility had an older backend still wired in as a fallback. If the lookup for a target missed, it would quietly fall back, deliver the message into an empty shell with nothing attached to it, and return 200. I had kept that fallback deliberately, as an emergency safety net — and an emergency is exactly when it would have fired, silently, and told me it worked. I deleted all twenty fallback branches. A missing target now fails loudly.

The rule I wrote down after the second one: do not judge a fallback by whether it will ever be reached. Judge it by what happens if it is. A silent downgrade wearing a success envelope is worse than a hard error.

That is what this piece is about — and it is where most ai workflow automation advice sends you in exactly the wrong direction. The advice, almost universally, is: split it up. Intake to one helper, delivery to another, a third for the books. Everybody gets a lane, nobody trips over anybody.

It sounds obviously right. It is often wrong, and the people best positioned to know have published the numbers.

Anthropic's engineering team, describing the multi-agent system behind Claude's Research feature, put it plainly: "agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." Their conclusion in the same paragraph: "For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance." Tokens are the unit these things are billed and rate-limited in — roughly, chunks of text going in and coming out. So that is the company that builds the thing, telling you its own arrangement costs fifteen times as much to run and only pays off on certain kinds of work.

So the honest version of this piece has two halves. Here is how to organise a folder that has outgrown five files. And here is how to tell whether your particular job is one of the ones that actually earns a split — because most of them are not.

By the end you will have a full folder layout you can copy, one complete job written out with every step's input and output nailed down and the human sign-off written in as a step of its own, and a three-condition test you can run in about ninety seconds before you add anything.

What "organised" means to something that reads top to bottom

One thing about how these tools actually behave, because getting it wrong is what makes folders rot.

It does not browse. It does not walk into your filing room, form an impression and pick the most relevant document. What it does is dumber and far more predictable: something puts text in front of it, and it reads that text. If a file's contents are in front of it, that file exists. If they are not, that file does not exist — no matter how carefully you wrote it or how obviously relevant its name is.

So "organised" here does not mean tidy. It means: for each thing you might ask, the right files are in front of it and the wrong ones are not.

Two mechanisms decide that, and it is worth knowing which one you are leaning on.

The first is the always-on file. Nearly every serious tool now agrees on a single convention: one Markdown file at the top of the folder that gets read first, every session, no questions asked. The name most of the industry settled on is AGENTS.md — released as an open format by OpenAI in August 2025 and donated in December 2025 to the Agentic AI Foundation, a fund under the Linux Foundation. Markdown here just means a plain text file where # makes a heading and - makes a bullet; you can write one in Notepad. There is no schema, no required fields, no version number. The official FAQ says so directly: "No. AGENTS.md is just standard Markdown." Twenty-three tools are named on the standard's own compatibility list as of 31 July 2026. Adoption was reported at more than 60,000 open-source projects as of the December 2025 donation announcement — a figure the project site has not revised since, so treat it as a floor rather than a current count.

The second mechanism is the file that only gets opened when it is needed, and this is the one that makes a large folder survivable. The convention is a folder containing a file called SKILL.md, published as an open standard at agentskills.io. Loading runs in three stages, spelled out in the spec: at startup the tool reads only the name and the one-line description, which is about a sentence or two's worth of text. If a task matches that description, it reads the whole file. Only then, and only if the instructions call for it, does it open anything in the folder's scripts/, references/ or assets/ subfolders.

Think of it as reading the spine of a binder before deciding whether to pull it off the shelf.

That three-stage rule is why a fifteen-file folder can work at all, and it tells you what your job files have to be good at — which is not what people expect. The description line matters more than the instructions. The instructions only get read if the description won the match. Brilliant steps behind a vague one-liner is a file that never opens.

Two limits are worth writing on the back of your hand. OpenAI's Codex stops adding project documents once they total 32 KiB by default — call it thirty thousand characters, or about twelve pages — and past that, content is dropped with no warning. And neither Claude nor ChatGPT guarantees that everything you uploaded to a project gets read on every turn — both fall back to fetching what looks relevant once there is enough material. Which means "it did not read my file" is usually not a bug. It is capacity, and the fix is structural.

The folder, laid out

Here is the whole thing. This is what the folder looks like once every piece has been added — the rules file, the job files, the checks, the boundaries, the written-down memory — plus the one thing this piece adds, which is the part that tells it what to open when.

my-work/
├── AGENTS.md                       read first, every single time
├── boundaries.md                   what never gets handed over
├── jobs/
│   ├── client-intake.md
│   ├── pre-delivery-check.md
│   └── month-end-close.md
├── checks/
│   ├── delivery-check.md
│   └── month-end-close.md
├── memory/
│   ├── decisions.md                things I settled once and don't re-argue
│   ├── recurring-issues.md         things that go wrong more than once
│   └── clients/                    one file per client, named after the matter
└── reference/
    ├── fee-language.md
    ├── standard-disclaimers.md
    └── forms/

Six things, and each one answers a different question about when.

Three things about this layout that are deliberate, and one thing people get wrong.

The folders are named after moments, not after roles. Not intake-assistant/ and reviewer/ and bookkeeper/, but when in your week you need them. This matters more than it sounds, and I will come back to it: naming folders after roles is the first step down the road of splitting the work, and once they are named that way, splitting starts to feel like the obvious next move even when it is not.

checks/ is separate from jobs/ on purpose. The steps for doing a thing and the test for whether the thing is done have different lifetimes — steps change when your process changes, checks change when something goes wrong. Keeping them apart means you can tighten one without disturbing the other, and it means a checklist can be run on work that came from somewhere else entirely, including work a human did.

memory/clients/ is a folder, not a file. One file per client or per matter, named after the thing, because you never want all of them in front of it at once and you very often want exactly one.

The thing people get wrong: they put everything in the top file. One enormous AGENTS.md with every job, every check and every template inside it. It feels safer — nothing can be missed if everything is always loaded — and it does the opposite. You hit Codex's 32 KiB ceiling and content vanishes silently. You push Claude or ChatGPT into fetching-what-seems-relevant mode, which is the behaviour you were trying to avoid. And you get the drift from the top of this piece, where fee language turns up in an answer about timelines, because it was in front of the thing the whole time and nothing told it not to reach for it.

The part that does the routing

This is the section that goes in AGENTS.md, and it is the actual deliverable of this piece. Copy it and change the rows.

## Where things are

Read this file every time. Read `boundaries.md` every time.
Everything else, open only when the trigger below matches.

| If I ask you to...            | Open                                          | Do not open              |
|-------------------------------|-----------------------------------------------|--------------------------|
| take on someone new           | `jobs/client-intake.md`                   | anything in `checks/`    |
| send something out            | `checks/delivery-check.md`                | `jobs/`                  |
| close out the month           | `jobs/month-end-close.md`, then               | `memory/clients/`        |
|                               | `checks/month-end-close.md`                     | unless I name someone    |
| look at a specific client     | `memory/clients/<the one I named>.md`         | any other client file    |
| something not on this list    | ask me which of these applies                 | —                        |

Rules for this table:
- If I name a file in my request, that file wins over this table.
- If two open files disagree, say so in one line before you continue.
  Do not pick silently.
- If nothing here matches, do not guess. Ask one question.

Four rows and three rules — the whole routing layer.

The reason this works is the reason the three-stage loading rule works: you are not making it smarter, you are narrowing what is in front of it. And the last rule is the one that fixes the drift — "do not pick silently" turns a wrong answer into a question, and a question you can answer in four seconds.

One job, wired end to end

A layout with nothing in it proves nothing. Here is one complete job file, with every step's input and output pinned down and the human step written in as a step.

I have used new-client intake for one reason: the public rules for it are unusually hard and specific, so you can check my work against something other than my opinion. American Bar Association guidance is explicit that you take the minimum information needed to run a conflict check first, and only then let the person tell you their story. Model Rule 1.18 Comment 4 limits the initial consultation "to only such information as reasonably appears necessary for that purpose," and the Kentucky Bar Association's conflict consultation form carries a warning notice at the top saying the same. The duty also attaches to people who consulted you and never signed, which is why the search has to hit three lists rather than one.

If you are not in law, read it anyway, then read the next section where I do the same exercise for a delivery check and a monthly close. The shape transfers; the content does not.

---
name: new-client-intake
description: Runs intake for a new enquiry. Conflict fields first, story second.
  Use when someone new contacts us and before any matter detail is discussed.
---

# New client intake

## Step 1 — Collect only the conflict fields

Input:  the enquiry, however it arrived (email, web form, note from a call)
Output: a block containing exactly these fields and nothing else —
        - full legal name of the person or entity
        - related parties
        - who is on the other side
        - the other side's lawyer, if named
        - which court, or which court it would be filed in
        - one line on what the dispute is about

Record nothing else they said. If the enquiry already contains matter detail,
do not summarise it and do not use it. Move it verbatim into
`intake/quarantine/<date>-<name>.md` and tell me you did.

## Step 2 — Run the three lists

Input:  the block from Step 1
Output: a table, one row per list —
        current clients | former clients | people who consulted us and did not sign
        each marked HIT / NO HIT / UNSURE, with the matching name quoted.

UNSURE counts as HIT. Do not resolve it yourself.

## Step 3 — STOP. I decide.  [human]

You hand me: the Step 2 table, plus the quarantine note if there is one.
I hand back exactly one word: PROCEED, DECLINE, or SCREEN.
Nothing in Step 4 runs until one of those three words comes back.
If I have not answered, wait. Do not draft ahead.

## Step 4 — Draft the outbound

Input:  my one word from Step 3
Output: one draft, saved to `outbox/`, filename reported back to me —
        PROCEED → engagement letter built from `reference/fee-language.md`,
                  with fee basis and scope left blank for me
        DECLINE → decline note, no reasons stated
        SCREEN  → written notice to the prospective person

Never send. Never fill in the fee basis. Never guess the scope.

Look at what that file is doing, because the shape is the transferable part.

Every step names its input and its output. Not "review the enquiry" — the input is the enquiry as it arrived, the output is six named fields and nothing else. This is where a document written for a person and one written for a machine part company. A person reads "collect the necessary information" and knows what it means from ten years of doing it. A machine reads it and invents a definition.

Step 1 says what not to keep. That quarantine line is doing real work. It separates something that helps you follow the ordering rule from something that quietly breaks it for you by summarising the case facts into your notes before the conflict check has run.

Step 2 turns an ambiguous result into a definite one. "UNSURE counts as HIT" is one clause, and it removes a whole category of judgement call from a place it does not belong.

Step 3 is a step. Numbered, with a stated input, a stated output, and an explicit instruction not to work ahead. A stop that lives in your head gets skipped the week you are busy. A stop written as step three of four has to be walked past on purpose.

Step 4 ends in a file, not in an outbox. "Never send" appears once, at the end. The whole job produces a draft and a filename.

Notice the block at the top too — the bit fenced off by three dashes, which the tools call frontmatter and which is just labelled facts about the file. Two fields, name and description, are the entire required set under the open specification at agentskills.io. Names are lower-case letters, numbers and hyphens, up to 64 characters, matching the folder name. Descriptions can run to 1,024 characters and should say both what it does and when to use it. The body has no format rules at all. Keep the file under about 500 lines and push detail into referenced files.

Write that description as if it is the only line of the file anyone will ever read, because on most turns it is.

What splitting the work actually costs

Now the part every ai workflow automation listicle skips, because it is not a feature anybody sells.

Suppose you take the job above and split it. One helper handles intake and conflicts, a second handles drafting. Cleaner, surely — each one has a smaller thing to know.

Here is the bill.

You explain the background twice. The second helper does not know what the first one saw. Anthropic's write-up is specific about what a delegated task has to contain before it will work at all: an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. Four things, per handoff, written by you — and not as a one-time setup cost. You pay it on the design of every handoff you ever build.

Decisions made on one side of a handoff get re-made on the other, differently. The sharpest version of this comes from Cognition, the company behind Devin, in a post titled Don't Build Multi-Agents. Ask for a Flappy Bird clone; split it into "build the background with pipes" and "build a bird you can move." One helper builds a background that looks like Super Mario Bros. The other builds a bird that does not move like the one in Flappy Bird. Now a third has to stitch two misunderstandings together. Their two principles: pass along the whole record of what happened, not selected messages from it, and remember that every action carries an unstated decision inside it. Their verdict on the split-it-up shape: "very fragile."

At your desk that looks like this. The intake helper decides — without saying so — that a company and its parent count as one party. The drafting helper assumes they are two. Neither decision was written down, and no disagreement was flagged, because neither one knew there was one.

The measured gains are often not there. A 2025 study led out of Berkeley, with authors including Dan Klein, Matei Zaharia, Joseph Gonzalez and Ion Stoica, collected more than 1,600 annotated recordings of real runs across seven of the multi-agent toolkits people actually use. The opening line of the abstract: "Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal." They catalogued fourteen distinct failure modes in three buckets — system design issues, misalignment between the helpers, and failures to verify that a task was actually finished. Two of those three buckets do not exist when there is only one helper.

And the token bill is roughly fifteen times a chat. About 4× for a single agent, about 15× for the split-up shape. On a fixed monthly plan you feel this as hitting limits sooner rather than as a line item, but you pay it either way.

What convinced me this is not a theoretical worry is a failure Anthropic reported on their own system: early versions were opening fifty helpers to answer a simple question. In a second example from the same post, one helper went off researching the 2021 automotive chip crisis while two others duplicated each other on 2025 supply chains — in their words, "without an effective division of labor." Best available models, best available prompts, full engineering resources, and the result was still three people doing two people's work and one of them doing the wrong decade.

The last cost is the quiet one: you now have more than one place to look when something goes wrong. With one helper and a bad answer, you read the files it had in front of it. With four, you first have to work out which one produced the bad part. Anthropic notes that in their setup the lead waits for each round of helpers to finish, so the whole thing can sit blocked while one of them is still searching.

The three conditions that justify a split

None of that means never split. It means the split has to earn its keep, and there is a short test.

Anthropic names the conditions where the arrangement actually pays: "valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools." And the ones where it does not: "some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit." A context window is simply how much text it can hold in front of it at one time; when your material is bigger than that, you have run out of room.

Rewritten for someone with a real trade and no engineering team:

Condition 1 — the parts genuinely run side by side. Not "there are several steps." Several steps in a row is one job. Side by side means: if you had two people, they could both start right now, neither waiting on the other, and neither needing to know what the other found. Twelve suppliers to chase for the same document is side by side. Intake then conflicts then engagement letter is not — it is a queue wearing a costume.

Condition 2 — it does not fit in one sitting. Two hundred pages of discovery. A year of statements. A tender pack with eleven annexes. When the material is bigger than one head can hold, splitting buys you real capacity, because each helper gets its own head. This is the condition most people think they meet and mostly do not. A folder with fifteen files in it is not too big. Fifteen files is small.

Condition 3 — your trade requires a genuinely independent second look. This one is not about capacity at all, and it is the one most often missed. Sometimes the rules of your work say the second pass must be done by someone who did not do the first — and in those cases the whole point is that the second party does not share the first party's reasoning. Under ISO 17100, a translation must be revised by a second person, comparing source and target line by line; as certification bodies state it, a translation cannot be self-revised. There is no "for long documents only," no premium tier where you get the second pair of eyes. It is a condition of the work.

If none of the three is true, do not split. Write better files instead. A single helper with a well-organised folder beats two helpers with a muddled one, and costs a fraction as much to run.

And if you are going to split, the smallest useful version is not two chat sessions. It is one helper with a job file whose Step 3 is a human — the file above. That already gives you what people are actually reaching for when they say "split it up," which is a checkpoint where fresh judgement enters, without the coordination bill.

Three trades, three calls

Same test, three different jobs, three different answers. This is the part I would read twice.

Taking on someone new — do not split

The intake job above. Every step feeds the next: the fields from Step 1 are what Step 2 searches, and the outcome of Step 2 is what Step 4 drafts from. A queue, not parallel work. It fits in one sitting easily. And no rule anywhere requires a second, independent party to do the conflict search.

Condition 1: no. Condition 2: no. Condition 3: no. Do not split.

Split it and you land squarely on Cognition's problem: the conflict helper forms a view of who the parties are, that view lives only inside its own reasoning, and the drafting helper forms a second view from the same raw enquiry. The stakes should end the argument. Under Model Rule 1.18, if a lawyer receives significantly harmful information from someone who never becomes a client, disqualification can be imputed to the whole firm — so adding a coordination seam to a job whose entire purpose is a clean ordering of information is exactly backwards. The ABA has also formally opined that using a non-lawyer for intake does not shift the responsibility, and that the confidentiality duty extends to AI tools. Splitting does not move liability; it only moves where the mistake happens.

Checking work before it goes out — split, and split for the right reason

Translation delivery is the clean case. ISO 17100's minimum production process runs translation, then the translator's own check, then revision by a different person comparing the two languages, then a final verification. The second person must have equal or higher qualification and relevant subject experience, and must not be the translator.

Condition 3, unambiguously. Note why: the value here is not throughput — nobody splits this to go faster. The value is that the second reader has not spent three hours convinced that a sentence means what they decided it means.

This has a direct implication for how you set it up, and it inverts everything else in this piece. Normally you want the second helper to know everything the first one knew. Here you deliberately do not. The reviewing pass should get the source, the target, and the checklist — and should not get the translator's notes about the tricky bits, because being told which bits are tricky is precisely what stops fresh eyes from being fresh.

The delivery-check pattern generalises past translation. A contractor's substantial-completion sequence has the same bones: under AIA A201-2017 § 9.8.2 the contractor prepares the list of items to be completed or corrected, and the architect then verifies and amends that list — a second party, deliberately, with authority to change the first party's list. And the European Commission's translation directorate writes the review obligation into the contract itself: its tender specifications state that thorough revision and review before delivery is a contractual obligation, and that failing to do it is a breach that can end the standing contract.

So: two files, and the check runs on the output, not on the reasoning.

Closing out the month — split partly, and know which part can never move

Bookkeeping is the interesting one, because the answer is neither yes nor no.

The pulling-together part — statements, the ledger, chasing what has not cleared — is repetitive, well defined, and could reasonably run alongside other things. The checking part is a different activity with a different failure mode. Splitting preparation from review is written into real policies: a university bank-reconciliation policy I read requires both a preparer and a reviewer, each signing and dating, with the controller approving after both have been through it.

But there is a step here that cannot be handed to anyone — not a second helper, not a bookkeeper, not staff. In North Carolina, Rule 1.15-3(i)(1) requires a lawyer to review bank statements and check images for every trust account every month, and the state bar's handbook says that requirement cannot be delegated. It explains why: the lawyer looks at the images so the lawyer might notice a cheque made out to an employee. California says the same thing differently — hiring a trained bookkeeper is allowed, and you remain personally responsible for the money. And under IRC § 6672, payroll tax withheld and not paid over attaches to a responsible person individually, can be assessed against several people at full amount each, and survives bankruptcy.

So the call is: split preparation from review if it helps, and put the non-delegable step in boundaries.md so it is visible every session rather than remembered every month. Making the undelegatable visible is the entire reason a boundaries file exists.

Your trade is not my trade

I am not a lawyer, a contractor, a translator or a bookkeeper. What I did was take the published rules for each of those jobs — bar association guidance, the substantial-completion documents, a translation standard, state trust-accounting rules — and write them out as job files with fixed inputs and outputs, then look at where the shape broke.

Here is where it broke, and it is the same crack in all three: the public documents are unanimous about the order of the steps and nearly silent about what a step produces. "Verify the conflict check is complete." Complete against what, in what form, handed to whom? Each of those documents assumes a reader who already knows, because each was written for one. Closing that gap is the whole job of a job file, and it is the part I am least qualified to close for your trade.

So: I ran this on real, published procedures from four trades, this is what came out, and this is where it stopped being obvious. If you do one of these jobs for a living, tell me which step I got wrong — and specifically, tell me the step where you would refuse to let anything but a human produce the output.

That is also the honest limit of everything above. The layout is general and the three-condition test is general. Which of your jobs is worth writing down first is not general at all, and it is the question that decides whether any of this is worth an afternoon. Every piece of general ai workflow automation advice, including this one, assumes you already know what your first job is. In most trades there is one obvious candidate — the thing you do every week, that has a right order, that you have already got wrong once. In some there are three, and picking the wrong one first is how people conclude the whole approach does not work for them.

Receipts

What this piece is built on, and what it is not.

Checked, with sources, on 31 July 2026:

• The 4× / 15× token figures, the fifty-helpers-for-a-simple-question failure and the duplicated-research example come from Anthropic's engineering post How we built our multi-agent research system, published 13 June 2025.
• The split-it-up failure argument and the Flappy Bird example come from Cognition's Don't Build Multi-Agents by Walden Yan, 12 June 2025.
• The 1,600+ recordings, seven toolkits and fourteen failure modes come from Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657, version 3, revised 26 October 2025. Note that version 1 called the first category "specification issues" and version 3 calls it "system design issues"; I have used the current wording. I have deliberately not quoted the percentage split between the three categories that circulates in secondary write-ups, because I could not confirm those figures against the current version of the paper.
• The two required fields, the character limits, the three-stage loading rule and the 500-line guidance come from the specification at agentskills.io, read on the date above. The home page listed 44 named products as reading the format; the site describes that as a partial list.
• The 23-tool compatibility list, the "just standard Markdown" FAQ answer, the 32 KiB Codex ceiling and the 60,000-project figure come from agents.md and OpenAI's Codex documentation. The 60,000 number has not been revised since the December 2025 announcement.
• The trade-specific rules are cited inline: ABA Model Rule 1.18 and Formal Opinions 506 and 512; AIA A201-2017 § 9.8.2; ISO 17100's four-step production process as stated by certification bodies (the standard itself is paid, and I have not read the original text); European Commission translation tender specifications; North Carolina Rule 1.15-3 and the state bar's trust account handbook; IRC § 6672.

Solutions I considered and ruled out, with the reason:

• One big file holding everything. Ruled out because Codex silently stops appending past 32 KiB by default, and because both major chat products fall back to fetching-what-seems-relevant once a project gets large. The failure is invisible, which makes it the worst kind.
• A separate routing file. Putting the "where things are" table in its own document rather than inside the top file. Ruled out for the obvious reason: it is one more file that has to be opened in order to know which files to open.
• Naming folders after roles. intake-assistant/, reviewer/, bookkeeper/. Ruled out because the naming pre-decides the architecture. Once the folders are named after people, adding a person feels like the natural next step.
• Letting the tool's own memory feature remember which file to open. Ruled out because that is the one part of the setup that does not come with you, which is the subject of the previous piece in this series.

Not tested, and I am not going to pretend otherwise:

• [NEEDS REAL RUN: the before-and-after — the same job run once with one helper and once split across two or more, with wall-clock time and actual cost for both. Requires picking one job, running it both ways at least three times each, and logging tokens or plan usage.]
• [NEEDS REAL RUN: the time I over-split — how many helpers, what the job was, and what specifically got slower or wrong. Requires deliberately building the over-split version and recording where it broke, rather than reasoning about where it would break.]
• [NEEDS REAL RUN: how many roles are actually in use here today, and what each one does. Requires an honest audit of the current setup rather than a description of the recommended one.]
• [NEEDS REAL RUN: a real non-coding AGENTS.md run end to end — the actual file, the actual session transcript, and the points where it opened the wrong thing despite the routing table.]
• [NEEDS REAL RUN: minutes-to-connect for the same folder on each of the three routes in the table below, measured with a stopwatch rather than estimated.]

I have also not tested whether the routing table measurably changes which file gets opened. It is a reasonable inference from how loading works, not a measurement, and it should be read that way.

If you're on Claude, ChatGPT, or something else

The folder is plain Markdown, which means the files themselves are the easy part. Connecting them is where the differences live.

✅ works out of the box · 🟡 works with a workaround · ❌ this one does not have it.

The ❌ row is the one worth sitting with, because it is the most honest thing on this page. The same job file, written once, has to be uploaded again to every surface where you want it, and changing it in one place does not change it anywhere else. No single company is to blame for this; it is the current state of the whole layer. The instruction file has a real standard behind it. The rest does not, yet.

Which is the argument for keeping the folder as the source of truth and treating every product as a place you copy it to. That way, when one of them changes its rules, you re-copy. You do not rebuild.

What to do this week

One job. Not the folder, not the layout — one job.

1. Pick the thing you do most often that has a right order to it. Not the hardest thing. The one you have already got wrong once.
2. Write it as four to six steps. For each step, write the input and the output on separate lines. If you cannot say what a step produces, the step is two steps.
3. Find the moment where you would want to look before anything else happens. Make it a numbered step. Write what it hands you and what you hand back, in those words.
4. Give it a name in lower case with hyphens and a one-line description saying what it does and when to use it. That line is the one that decides whether the file ever opens.
5. Put it in jobs/, add a row to the routing table in AGENTS.md, and use it for a week before you write the second one.

Do not add a second helper. Not yet. Run the three-condition test on the job you just wrote — side by side, bigger than one sitting, independent second look required — and if the answer is no three times, which for most jobs it will be, your next improvement is a better description line, not another seat at the table.

And when you do outgrow one helper, the thing you built still comes with you: it is a folder of text files, and the next piece in this series runs exactly this folder on three different products to see what survives the move.

Stay in the loop (no account signup)

This site does not ask you to create a product account. Free readers just leave an email—or follow where the build is posted.

No paywall on this article. No "sign up for access." If you only want one next step: use the email box at the bottom of the site, or follow on X if you prefer the timeline.

Going deeper

Both of these are written for people already working at the command line, and both cover the same split-or-don't question at a lower level:

• When to split agents, and the four mechanisms that hold a split together
• Setting up your first delegated helper, with a copy-paste config and the hidden costs

Questions people actually ask

Does AI workflow automation mean I have to buy an automation platform?
No. If you already pay for a chat assistant, you already have the engine. What is usually missing is not software but organisation: a folder of written instructions, one file per job, and a rule for which file gets opened when. Most of what the search results call ai workflow automation is a market for connecting apps to each other, which is a different problem from getting one assistant to follow your procedure correctly.

How many AI helpers should a one-person business run?
Start with one and keep it there until a specific job forces you off it. Anthropic's own data puts multi-agent setups at roughly fifteen times the tokens of a chat conversation, so the second seat has to earn that multiplier.

When is it right to split work across more than one helper?
Three conditions, any one of which is enough: the parts genuinely run side by side rather than in a queue; the material does not fit in one sitting; or your trade requires a genuinely independent second look, as translation revision does under ISO 17100. If none applies, better files will beat more helpers.

Why does adding a second helper sometimes make things slower?
Because you explain the background twice, and because implicit decisions made by the first get re-made differently by the second. Cognition documented this pattern in June 2025; a Berkeley-led study of more than 1,600 recorded runs across seven toolkits found gains on common benchmarks are often minimal, and catalogued fourteen distinct ways these setups fail.

What goes in the top file versus a job file?
The top file holds what is true every time you sit down: who you are, how your trade talks, what never gets handed over, and the index that says which other file to open when. A job file holds the steps for one job and is opened only when that job comes up.

How long should each file be?
Short enough to be read in full. The open specification recommends keeping a job file under about 500 lines and pushing detail into referenced files. On the command-line side, OpenAI's Codex stops appending project documents past a default of 32 KiB, so an oversized file can be cut off without any warning.

Will my folder still work if I switch providers?
The files are plain Markdown and come with you. What does not come with you is anything the provider stored on its own side — and even inside one provider, Anthropic's documentation states that custom skills do not sync across surfaces and have to be uploaded separately to each.

Where do I put the step where I have to sign off?
Into the job file, as its own numbered step, with what the helper hands you, what you hand back, and an explicit instruction that nothing downstream runs until you answer. A stop that is not written as a step is a stop that gets skipped.

My trade has a step that legally cannot be delegated. Where does that go?
In boundaries.md, which is read every session. Trust-account rules in some US states require the lawyer personally to review check images monthly and say the requirement cannot be delegated; translations for US immigration filings need a human certification of competence. Those belong in the always-read file, not buried in a job file that only opens sometimes.

Can I just tell it my process in the chat each time instead?
You can, and it works until the week you are busy and shorten it. The whole point of writing it down is that the tired version of you gets the same procedure as the careful version.

— hh, AI Workflow Pro