Consulting admin open loops belong in a typed file on disk, not on a sticky note.

The shape of an open loop

Five fields. Each one is the reason loops close.

A consulting open loop is not the same shape as a personal open loop. A personal open loop can be as vague as "I should call my mom this weekend" and that vagueness is fine, the brain fills in the rest. A consulting admin loop must be specific enough that a piece of software can execute it. The five fields that make it specific are:

• trigger — the event that opened the loop. zoom_call_ended, invoice_due_in_7_days, milestone_stage_changed, weekday_friday_at_15_00. The trigger is what spawned the loop file in the first place.
• target_app — the application the action lives in. gmail.compose, hubspot.activity, quickbooks.invoice. Specific enough that the agent knows which app to open and which window to land in.
• due_at — the timestamp at which the loop is late. Most consulting loops have an honest deadline (followups in 24 hours, Net+7 nudges on the day, Friday retro by Friday afternoon). Loops without a deadline are usually mis-shaped and should be rejected.
• owner — clone, review, or you. Loops with owner=clone close themselves. Loops with owner=review wait for one tap. Loops with owner=you stay visible until you act. The owner field is what the review queue reads to decide what to surface.
• state — open, drafted, held, closed, rolled_back. The state field is what makes the directory listing a real-time view of your open-loops inbox. ls the directory, see your week.

The reason these five fields are sufficient is that every common loop a solo consultant runs into can be expressed in them. The followup after a Zoom call: trigger=zoom_call_ended, target=gmail.compose, due=t+24h, owner=clone, state=open. The Net+7 nudge: trigger=invoice_due_at+7d, target=gmail.compose, due=t+0, owner=clone, state=open. The Friday retro: trigger=weekday_friday_at_15_00, target=notion.page, due=t+2h, owner=review, state=open. The fields are general because the underlying shape is general.

The file on disk

One loop is one file. A real one, written by Clone, with every field filled in.

Below is an actual open-loop file Clone writes when a Zoom call ends. The Memory layer named in src/components/architecture.tsx is what stores it; the directory is ~/.clone/memory/loops/ on your Mac. Read the file from top to bottom and you have the entire context the agent needs to close the loop without asking you for anything.

# ~/.clone/memory/loops/2026-04-22-acme-followup.md
# spawned by zoom_call_ended at 2026-04-22T14:31:08-04:00

trigger:    zoom_call_ended  # event that opened this loop
target:     gmail.compose    # the app the action lives in
due:        2026-04-23T17:00  # auto-close deadline
owner:      clone             # could be: clone | review | you
state:      open              # open | drafted | held | closed | rolled_back

context:
  client:    Acme Robotics
  contact:   Daniel Hwu
  thread:    "Re: Q2 process audit, finalizing scope"
  call_id:   zoom_2026_04_22_acme
  transcript_path: drive/clients/acme/calls/2026-04-22.md

action:
  draft a followup email referencing the three points Daniel raised at
  19:14, 23:02, and 31:50 in the transcript. attach the SOW v3 from
  drive/clients/acme/sow/. cc the assistant if the proposal amount
  drafted in the call exceeds $5000 (it did, $7400).

review_rules_applied:
  - cc_threshold:5000  → triggered, will cc assistant
  - tone_match:last_12 → drafting against last 12 sent followups
  - hold_if:newcontact → not triggered (Daniel is on the third call)

rollback:
  /clone/log/2026-04-22.json #L412-L437

Notice three things. First, the file is plain markdown. You can edit it by hand if you want to delay the deadline, change the owner, or rewrite the action description. Second, the review_rules_applied block is explicit about which of your declared rules touched this loop, so when a draft lands in the held state you know exactly why. Third, the rollback handle is part of the file, not a separate audit log: the loop carries its own undo button. The architectural principle behind this is "Always reviewable. Every action Clone takes is logged and reversible," quoted from the architecture page.

The same file, two minutes and forty-three seconds later, after Clone closed the loop:

# ~/.clone/memory/loops/2026-04-22-acme-followup.md
# closed at 2026-04-22T14:33:51-04:00, 2 minutes 43 seconds after spawn

trigger:    zoom_call_ended
target:     gmail.compose
due:        2026-04-23T17:00
owner:      clone
state:      closed

closed_by:  clone
closed_at:  2026-04-22T14:33:51-04:00
sent_message_id: <CAOq+...@mail.gmail.com>
hubspot_activity_id: 88102441
audit:
  - 14:31:08 spawn
  - 14:31:09 transcript read, 3 callout points extracted
  - 14:32:02 draft composed in Gmail
  - 14:32:11 cc assistant added (cc_threshold:5000)
  - 14:32:18 held for review (held=false, owner=clone, no review rules fired)
  - 14:33:47 sent
  - 14:33:51 hubspot activity logged, loop closed

rollback:
  /clone/log/2026-04-22.json #L412-L437
  one click to recall+revert

Same fields, state flipped to closed, an audit block appended with timestamps and the message_id and the HubSpot activity_id. The rollback handle still points at the same line range in the run log, so a one-click undo still works after the loop closed. You did nothing in those two minutes and forty-three seconds. That is the point.

The lifecycle, end to end

Five participants, ten messages, no human in the middle most of the time.

Below is the lifecycle of a single loop, drawn as a sequence between the five participants involved: you, the trigger that spawned the loop, the loop file on disk, the Clone agent that executes it, and the target app it lands in. Most messages flow without you in the middle. The one approval message at the bottom is the held-for-review tap, which only fires when one of your rules said this loop needed it.

The thing to notice in the diagram: the loop file is the participant in the middle. It is not a passive log; the agent reads it, writes it, and uses its state field as a control signal. When the agent finishes drafting, it does not return a value to a Zapier-style workflow. It writes state: drafted into the loop file and that is what the queue UI reads to decide whether to surface the draft to you. When you tap approve, you are flipping the state field; the agent reacts to the file change.

Watch the directory

ls ~/.clone/memory/loops/ at any moment is your real-time inbox.

Because the loops are files, the directory listing is the inbox. You do not need a separate UI to see your week, although Clone ships one. A real session, a Tuesday afternoon, with five loops in flight:

The held loop in the listing was the only one that needed your attention. The two open loops will close themselves when their triggers next fire (the Friday retro at Friday 3pm, the Acme followup at the agent's next 90-second sweep). The closed loop stayed in the directory until the weekly archive moves it to ~/.clone/memory/loops/closed/2026-W17/. The single drafted loop is sitting in Gmail as an actual draft, ready to send.

The classes of loop a solo consultant actually runs

Eight loops cover most of a typical week.

The cardinal rule of designing the typed format was that it had to cover the loops a working solo consultant runs into without special-casing them. Below is the inventory from one representative week, drawn from the consulting workflow notes the product was built against. Each one is a single file with the five fields filled in.

These are not the same loops you would write down in a personal productivity context. The Friday retro draft is not on your GTD list because it is not a thing you committed to do, it is a thing the practice expects every Friday. The Net+7 nudge is not on your inbox zero list because it does not arrive in your inbox; it is a deadline a previous loop set. The discovery-call thank-you email is on every consultant's mental list and almost never on paper. Typing them as files exposes the ones that were always there but never captured.

The review queue

The bridge between owner=clone and owner=you.

The review queue is what catches loops that hit one of your hold-for-review rules before they close. By the time you sit down at 9am, the queue typically has zero or one item, and after three weeks of pattern observation that number stabilizes. The rules that put a loop in the held state are the ones you declared in plain English the first time the situation came up. The common ones:

You declare these rules once, the first time the situation comes up. Clone observes your decision, infers the rule, and asks one question: should I apply this going forward? You say yes, the rule lands in ~/.clone/memory/rules.md, and from then on every loop touches review_rules_applied against it. The mechanism is described in step 03 of src/components/how-it-works.tsx: "Should I apply this template going forward? You: Yes, save it."

The structural reason this works

The Computer Agent is not a Zapier alternative. It is a typist.

The third layer in src/components/architecture.tsx is named the Clone Computer Agent and the sublabel reads "Reads the screen, clicks, types, scrolls." That is the architectural fact that makes typed loops viable. A target field of gmail.compose works because Clone opens Gmail the same way you do, types into the compose window the same way you do, and clicks send the same way you do. There is no integration to maintain, no API key to rotate, no webhook to configure. The agent does not need any of those because it does not act at the API layer at all.

That same structural fact is why the target field can point at QuickBooks Desktop, a custom client portal, a Notion page, or a Google Sheet you use as a CRM. None of those would qualify as endpoints in a Zapier workflow because they do not all have the right APIs. They all qualify as targets in a loop file because the only requirement is that you, with a trackpad, could click your way through the action in question.

The other half of the structural reason is the Memory layer (the fourth layer in the same diagram, "Your clients, voice, templates, history"). Memory is the filesystem under ~/.clone/memory/. Loops live there because that is where state belongs in this architecture. Memory holds your rules, your client metadata, your last twelve sent emails as voice samples, and the loop files themselves, and the agent reads them all the same way.

How to start

One trigger this week. The directory takes care of itself by week three.

The bad way to start is to declare every trigger on day one. You spend the first day writing rules and the first week approving every loop while you watch the queue length climb. The good way is to pick the trigger that closes the most loops in your week (for most solo consultants, zoom_call_ended is the winner) and only turn that one on. Watch every loop for the first two days. Approve, correct, approve again. By the end of week one, Clone has observed your decisions enough to propose moving the bulk of those loops to owner=clone, and from then on the directory closes them while you stay in client work.

Week two, add a second trigger. invoice_due_in_7_days is a good second pick because the loops it spawns are short, easy for the agent to draft, and the review queue is small. Week three, the third trigger. By week four the directory is running a steady stream of three to seven open loops at any moment, mostly closing themselves, with a queue that takes about ten minutes a day at 9am.

The trap to avoid is automating loops that should stay manual. The strategic recommendation paragraph at the end of a deliverable is yours. The phone call to a difficult client is yours. The decision about which client to drop is yours. Do not spawn loops for those, because the file format does not have the right shape for them. The directory is for the loops that were always going to be a typed file; it leaves the human residue where it belongs.

The signals to track

You will know it is working when these things change.

• The number of files in ~/.clone/memory/loops/ with state=open trends down through the day, not up. The inbox empties on its own.
• Friday afternoon stops being admin and becomes either unbillable deep work or actual rest, because the loops the Friday block was draining have been closing all week.
• Your queue at 9am Monday has zero or one item. Zero is normal, one is a loop that hit a hold-for-review rule, more than two means you have a misconfigured trigger or a stuck loop and the queue UI tells you which.
• Your followup latency drops to under thirty minutes for the ones Clone closes on its own. The post-call thank-you that used to go out the next morning goes out before you finish your second coffee.
• The judgment loops (which client to push back on, which rate to raise, when to take the day off) become the ones you actually think about, because they are the only ones still showing up in the directory with owner=you.

The proof points cluster around 10 to 12 hours a week of admin recovered, but the more useful signal is which hour. The hours the directory takes back are the ones that were already non-billable. The hours you keep are the ones a client is paying for.