A brief beats a flowchart
Briefs describe the outcome; builders demand every branch before the work exists. Where each one wins, and why Delagents starts from the brief.
4 August 2026 · 4 min read · Delagents
There are two ways to tell a machine what you want done. You can draw the flowchart: this trigger, this condition, this branch, this action. Or you can write the brief: here is the outcome, here are the constraints, here is where to stop and ask me. Delagents is built on the second, and this essay is about what that costs and what it buys.
What a flowchart asks of you
An automation builder asks you to enumerate the cases before the work exists. Every path the job can take has to be drawn as a branch, and every branch has to end in an action you specified. This is the right shape for work that is the same every time: a form submission becomes a row, a new customer gets a welcome sequence, an invoice over a threshold gets flagged.
The cost is that the builder can only handle the cases you thought of. The case you did not think of either fails loudly, halting the run and paging someone, or fails quietly, taking the nearest branch and doing something plausible and wrong. Neither is a defect in the tools. Zapier, Make, n8n and Relay.app are good at what they are for, and Relay.app in particular treats a human step as a first-class node, which is closer to our view than most. The limitation is in the model of the work: a diagram has to be complete before it runs.
What a brief asks of you
A brief describes the outcome and the boundaries and leaves the route to the agent. It reads like the message you would send a capable new colleague on their first morning.
Research twenty-five companies matching this profile, rank them, and draft a two-line intro for each. Prefer primary sources. Skip anyone on the do-not-contact list. Ask me before anything is sent. Budget: forty credits.
Nothing in that brief is a branch. It names what good looks like, what to avoid, and where a person must be involved. The agent plans the steps, and the plan is visible on the Progress timeline as it runs. The cases nobody drew are absorbed by the checkpoints: when the agent reaches something the brief did not anticipate, it stops and asks, and the question arrives in the Inbox as an approval card with the exact action and the cost.
Where each one wins
| Flowchart | Brief | |
|---|---|---|
| Volume | Thousands of runs a day | Dozens a week |
| Nature of the work | Deterministic: same input, same output | Judgment: tone, priority, relevance |
| Setup | Hours drawing and testing branches | Minutes writing, then a reviewed first run |
| Unmapped case | Halts, or takes the wrong branch | Stops at a checkpoint and asks |
| Cost | Fixed per run | Estimated before, capped during, itemized after |
| Record | Run history | Step log, payloads and every sign-off |
We want to be plain about the left column. If you have a form that must create a row every single time, draw it. The builders keep deterministic, high-volume work, and they should. Delagents takes the judgment-heavy, medium-volume work that nobody could diagram: the morning support queue where the tone matters, the recruiting screen against a rubric, the month of receipts where a new vendor needs a human eye.
What a good brief contains
A brief is short, but it is not vague. The ones that run well have six parts, and the composer asks for each.
- The outcome: what should exist when the work is done, and in what format.
- The inputs: the sources to use, the ones to avoid, and any attachments.
- The constraints: tone, do-not-contact lists, thresholds, house rules.
- The checkpoints: where the agent must stop and ask, beyond the floor that always applies.
- The due date, so the agent can plan the run and you can plan your review.
- The budget cap, so the bill is known before the first step.
The brief and the checkpoint are one design
A brief without checkpoints is a wish. Checkpoints are what make it safe to leave the route open: the agent may choose the path, but it cannot take a step with a real consequence without a person seeing it first. That division of labor is the point. The person spends their attention on outcomes and decisions; the agent spends its steps on the route.
The same division shows up when the work comes back. Reviewing a deliverable and asking for changes reopens the run with your note attached, so the second attempt starts from what you said rather than from zero. In a flowchart, the equivalent is editing the diagram.
Using both
None of this means the flowchart goes away. A builder is a good way to start a delegation: an event happens in a system you already automate, and the last node hands a brief to Delagents. Flowchart outside, brief inside, sign-off before anything leaves. We plan actions for the builders for exactly this reason, and we would rather be the step in your diagram that handles judgment than pretend the rest of your diagram should not exist.
Write the brief you would write for a person. Say where to stop. Let the agent plan the rest, and read the card when it asks.
