Recursive Goals: How to Turn a Business Workflow into a Loop That Runs Itself
Every discipline has its unit of work. Prompt engineering has the instruction. Agent design has the job description. Loop engineering's unit is stranger and more powerful: the recursive goal, [Osmani's] 'Clickable Text'
"purpose you define once, that the AI iterates until the work is actually complete."
Recursive is the load-bearing word. A normal goal is consumed by achievement: "chase this invoice" ends when the invoice is chased. A recursive goal regenerates: "keep our receivables healthy" is never finished, only satisfied for now; tomorrow it produces new work from the same definition, informed by everything already done. It is the difference between an errand and a responsibility, and writing responsibilities that a machine can hold is the genuinely new skill in all of loop engineering.
This article is the practical craft: how to recognise which of your workflows are loop-shaped, the five-part template for writing a recursive goal that actually works, three full translations from ordinary business processes, and the goal-writing mistakes that quietly doom loops before their first run.
What Makes a Goal Recursive?
A recursive goal has three properties an ordinary task lacks:
It regenerates. The goal's own definition produces fresh work each cycle: new overdue invoices exist every morning, new emails arrive, new documents land. Nothing about completing today exhausts the purpose.
It feeds on its own history. Each cycle begins from the [state the last one wrote]: chased invoices are not re-chased, answered emails not re-answered, the follow-up scheduled Tuesday fires Thursday. The loop's memory is what makes iteration progress rather than repetition.
Its satisfaction is checkable. "For now, done" has a verifiable meaning: queue empty, every item in a known state, budgets intact ([the stopping conditions] discipline, embedded in the goal itself).
The analogy that carries the article: the standing responsibility versus the errand. "Post this letter" is an errand: one instruction, one completion. "Own the post" is a responsibility: it regenerates daily, remembers what went out, knows what awaiting-reply means, and escalates the letter from the solicitor. Businesses are built from responsibilities, yet almost all automation history has been errand-automation: fixed steps, fired once per trigger. The recursive goal is the first tool shaped like the responsibility itself, which is why loop engineering feels like a bigger deal than another automation feature: it automates at the altitude where jobs are actually defined.
Which Workflows Are Loop-Shaped? The Four Marks
Not everything should become a loop. The candidates carry four marks:
1. A natural cadence. The work regenerates on a rhythm: daily (inboxes, payments), weekly (reporting, follow-ups), continuous (intake queues). One-off projects are not loops; they are projects.
2. Judgment per item, pattern across items. Each case needs reading (which tone, which category, which exception), but the cases rhyme: exactly the [rules-plus-judgment texture] that separates agent work from Zapier work, one level up.
3. Checkable completion per item. You can say what done means for one unit in a verifiable sentence. If done is a feeling, the workflow is not loop-ready (and often not delegation-ready to humans either, which is the tell).
4. Nameable exceptions. The cases that must reach a person can be described in advance: amounts, senders, sentiments, shapes. "I know it when I see it" exceptions mean the [boundary design] has homework left.
Run your [repetitive-hours audit] through these marks and a shortlist falls out; in most SMBs it is the same five suspects: receivables, inbox triage, document intake, CRM hygiene and reporting, exactly the loops the [pillar] sketches.
Writing the Goal: The Five-Part Template
A working recursive goal fits on one page, in five labelled parts. This template is the deliverable of the whole article:
1. The standing purpose (one sentence). "Each weekday morning, ensure every overdue invoice has an appropriate, policy-compliant next action taken or scheduled." Note the shape: a state to maintain, not a task to do. If your sentence starts with a verb like "send" or "write," you have an errand; start again with "ensure," "keep" or "maintain."
2. The discovery rule. How the loop finds its work each cycle, with sanity bounds: "all invoices >14 days overdue, excluding disputed and payment-plan accounts; if today's set exceeds 3x trailing average, halt and alert." Discovery is where [the sorcerer's-apprentice failure] lives, so the bound is part of the goal, not an optional extra.
3. The per-item standard. What correct handling means for one unit, pointing at your codified knowledge: "chase tone per customer-history tier (see collections skill); amounts re-verified at draft time; one clear action per message." This is the part [the checker] will verify against, so write it as decidable criteria, not vibes.
4. The boundaries and escalations. What never gets handled autonomously: ">£2,000 queues for approval; any legal-adjacent language routes to finance manager; two failed checks equals human queue." Your [gate map], embedded.
5. The satisfaction condition and budgets. What "done for now" verifiably means, plus the [stop-sheet numbers]: "queue empty or 8:30, whichever first; every item's state written; ≤£5 model spend; ≤40 sends."
One page. If it will not fit, the goal is too broad: split it (the receivables loop and the disputes loop are different responsibilities, as any finance manager would tell you about the human versions).
Three Translations, Worked
The inbox-triage loop. Purpose: "Ensure every inbound customer email has a correct next state within one hour of arrival, working hours." Discovery: unprocessed inbox items, hourly heartbeat. Per-item standard: classify (order query / support / complaint / sales / other), resolve what the [grounded assistant] can with citations, draft-for-approval what it nearly can, route the rest with a one-paragraph brief. Boundaries: complaints and legal-adjacent always route; no send without checker pass. Satisfaction: no item unclassified >1 hour; escalation queue briefed. The responsibility this replaces: the office manager's "keeping on top of the inbox," which was never really about typing.
The CRM-hygiene loop. Purpose: "Keep customer records current with reality as evidenced by mail and calendar." Discovery: yesterday's communications, nightly. Per-item standard: extract contacts, commitments and stage-changes; update records with provenance notes; never delete, only append and flag. Boundaries: mergers of suspected duplicates queue for approval; anything ambiguous becomes a flag, not a guess. Satisfaction: all of yesterday's items processed, changes logged. The [oldest lie in sales] retired on a schedule.
The weekly-reporting loop. Purpose: "Ensure Monday 8am's operations report reflects last week accurately, with anomalies flagged." Discovery: the week's transactions, tickets and jobs, Sunday night. Per-item standard: figures mechanically verified against sources ([never self-reported](the LLM article's rule about numbers)); narrative drafted from the verified figures; every anomaly flagged with the evidence attached. Boundaries: the report ships to the owner as a draft, always: this loop's output is briefing, not action. Satisfaction: report delivered, every figure traceable. Notice a loop can be modest: no sends, no writes, pure [analyst-role] on a heartbeat, and it is many businesses' safest first loop for exactly that reason.
The Goal-Writing Mistakes That Doom Loops
The verb trap. Goals written as errands ("send chasing emails daily") make the loop optimise sending rather than the receivable's health: it will chase brilliantly and never notice the customer who paid. State-maintenance phrasing ("ensure every overdue invoice has an appropriate next action") keeps judgment pointed at the responsibility.
The unbounded noun. "Handle customer communications" is a department, not a goal. The [fuzzy-scope failure pattern] applies with a heartbeat attached: split until each goal has one discovery rule and one per-item standard.
Satisfaction by adjective. "Professionally," "appropriately," "promptly" are checker-proof words. Every adjective in a goal should either point at codified criteria ("per the collections skill, tier table 2") or be replaced by a number.
The missing regeneration test. Before building anything, ask: what does this goal produce on a morning when nothing new happened? The right answer is "verifies the queue is empty, checks scheduled follow-ups, writes state, stops within budget." If the honest answer is "it would find something to do anyway," you have written an over-eager goal, and [the budgets] will be earning their keep from day one.
Skipping the human draft. The strongest goal-writing trick is unfashionable: write the responsibility as if briefing a competent temp for a month's cover. The gaps that description exposes (unwritten tiers, unstated exceptions, folklore thresholds) are exactly what the loop needs codified, and the temp-brief IS the first draft of the five parts. Businesses that can brief humans well can write recursive goals; businesses that cannot have found their [readiness] gap.
From Page to Heartbeat: What Happens After the Goal Is Written
The five-part page is the design; here is the bridge to a running loop, compressed, because the [pillar] and its siblings carry the detail.
The page gets audited against reality (week one). The people who currently hold the responsibility read the draft and mark everything that does not match practice: the unlisted exception, the tier that exists only in Deb's head, the "we stopped doing that in March." Every correction is cheap now and expensive later; this read-through is the single highest-value hour in the whole build.
The parts map to the six blocks (weeks two to four). The discovery rule becomes the [heartbeat and its bounds]; the per-item standard becomes the [checker's checklist] and the knowledge files; the boundaries become the [gate map]; the satisfaction condition and budgets become the [stop-sheet]; and a state store is stood up as the memory. Nothing on the page fails to land somewhere in the architecture, which is the sign the page was written properly.
The loop runs caged, against the page (weeks four to eight). Everything gated, humans approving all of it, and every disagreement between the loop's behaviour and the page resolved in one of two ways: the loop is corrected, or the page is, with the responsibility-holders deciding which. The page is the constitution; the shadow period is its first court.
The page stays the living centre. Post-launch, every threshold change, checklist edit and boundary adjustment amends the page first, then the config: one document, version-controlled, that always answers "what is this loop supposed to be doing?" Loops whose truth lives in scattered configs drift; loops with a constitution can be audited, handed over and trusted. It is, not coincidentally, the [documentation clause] this site puts in every hiring checklist, applied to a worker who happens to be a system.
Frequently Asked Questions
What is a recursive goal in AI? A purpose defined once that regenerates work each cycle, feeds on its own recorded history, and has verifiable "done for now" conditions: "keep receivables healthy" rather than "chase this invoice." It is loop engineering's unit of work: the AI iterates against the standing goal until each cycle's satisfaction condition is met.
How do I know if a workflow can become a loop? Four marks: it regenerates on a natural cadence, needs judgment per item but rhymes across items, has checkable per-item completion, and has nameable exceptions. Receivables, inbox triage, document intake, CRM hygiene and reporting carry all four in most businesses; one-off projects and pure-judgment work do not.
What should a recursive goal document contain? Five parts on one page: the standing purpose (a state to maintain, not a verb), the discovery rule with sanity bounds, the per-item standard pointing at codified criteria, the boundaries and escalations, and the satisfaction condition with budgets. If it exceeds a page, split the responsibility.
Why do loop goals fail? Predictably: errand-verbs that optimise activity over outcomes, unbounded scopes that describe departments, adjectives no checker can verify, no answer for the quiet morning (over-eager loops), and skipping the brief-a-temp draft that exposes the unwritten rules. All five are visible on the page before a penny is spent, which is the point of writing the page.
What is the safest first loop for a small business? The reporting loop: analyst-role only, no sends or writes, output shipped as a draft to a human, figures mechanically verified. It exercises every loop discipline (heartbeat, discovery, verification, state, budgets) with a blast radius of zero, and its Monday-morning output makes the case for the next loop by itself.
How does a recursive goal relate to stopping conditions? The satisfaction condition and budgets ARE the goal's stopping conditions per cycle, and the discovery bounds are its protection against runaway mornings: the [stop-sheet] and the goal document are two views of one design. A recursive goal without verifiable stops is not a goal; it is a wish with a heartbeat.
Can a recursive goal change over time? It should, deliberately: thresholds move as trust accumulates, standards sharpen as the catch log teaches, discovery widens as adjacent work proves loop-shaped. The discipline is that changes amend the one-page document first (version-controlled, owner-approved) and the configuration second, so the constitution and the machine never drift apart. A goal that has not been amended in a year is either perfect or unread, and the second is far more common.
The Takeaway
The recursive goal is the responsibility, written so a machine can hold it: a state to maintain, a way to find each day's work, a standard per item, lines that summon humans, and a checkable "done for now." One page, five parts, and the discipline of writing it, like briefing the world's most literal temp, exposes every unwritten rule your business has been running on folklore.
Find the workflows with the four marks, draft the temp brief, pass it through the template, and the loop is mostly designed before any technology appears. Which is the quiet secret of this whole cluster: loop engineering is 80% the craft of saying what you actually want, verifiably. The machines just made that craft finally, fully worth it.
Bots and Brand Works turns workflows into one-page recursive goals as the first step of every loop engagement, and half the value lands before any build: the unwritten rules, written. Send us one responsibility you would love to never think about on a Tuesday, and we will draft its five parts, free.
Need Help Implementing AI?
Read our FAQ section to learn more.
Resources and Further Reading
- Loop Engineering: The Complete Business Guide
- Related: [Stopping Conditions]
- Related: [The 90-Day AI Adoption Roadmap]
- Related: Loop Engineering vs Prompt Engineering vs Context Engineering: The Three Levels of Working With AI -
- Foundations: [Recursive goal template pairs with the AI Readiness Checklist · Verification Inside Loops]