What is a Nimbus Loop
A Nimbus Loop is a standing order on a workstream — trigger, compiled recipe, and run page — that produces outputs or signed actions and notifies the team without a chat ritual.
A standing order for enterprise AI is a job that already exists before anyone starts a run: a trigger admits work, a compiled recipe executes, and a run record shows outputs and skips. Nobody re-describes the job in a chat thread to make Monday happen.
McKinsey’s State of AI shows organisations using models widely while leaving recurring work in chat and memory. Adoption without redesign means the same exception list is still a ritual: someone remembers the filters, someone else remembers the sheet, and audit asks a person rather than opening a record.
Disambiguate before you build or buy:
- Eval loop — a sensor that grades a run. Did the executed write match the signed payload? See eval loops for enterprise agent harnesses.
- Standing-order loop — this page. A job that admits a run when a trigger fires.
- Agentic workflow — an interactive path that still reasons when the route is not fully known. See what is an agentic workflow.
Loop engineering is the discipline behind the recipe: compile the known path, detect change, record skips. A standing-order loop is how that discipline shows up as an object operators can own — on a workstream, with connectors, a roster, and a finish line.
What a standing-order loop is
Four parts, always visible:
1. Trigger. What starts a run. A schedule (every Monday 06:00), a file landing in a folder, a threshold crossed, or a deliberate manual start from a form. See six things that start a loop.
2. Compiled recipe. The fixed sequence for this job on this workstream: which connectors to read, which rules to apply, what to produce, whom to notify. Not a system prompt. Not “use your judgement.” The same recipe every time until you version it.
3. Run page. One URL per execution. Inputs observed, steps taken, outputs attached, skips listed with reasons, actions proposed or completed. This is what audit walks — not a transcript of vibes.
4. Team notified. The roster on the workstream gets the outcome. Success, partial success with skips, or hard stop. Collaborative AI means the right people see the same run page, not a forwarded screenshot.
A standing-order loop is not an agent you chat with. On the normal path it does not invoke a model. See a loop is not an agent. When the path is unknown, the loop escalates — to a person on the roster, or optionally to an agentic workflow you have explicitly attached for that exception class.
LangChain defines Agent = Model + Harness. A standing order is intentionally not that object on the happy path. It is closer to a scheduled pipeline with operator UX: a form to configure, a run page to inspect, a roster to notify.
Compare loop vs workflow vs agent: workflow is the abstract sequence; a standing-order loop is the deployed sequence on a named job with connectors and roster; an agent is the reasoning actor for unknown branches.
Words you’ll hear
- Standing order. The job waits. It does not need to be re-briefed.
- Trigger. Schedule, arrival, threshold, or manual start. Deduplicate so unchanged inputs do not page finance.
- Recipe version. The compiled steps as of this run. If only a prompt versions, you do not have a recipe.
- Skip. Recorded halt. Missing file, ambiguous row, stale schema.
- Output. Artefact on the run page. Read-only connectors suffice.
- Action. Write to a live system. Requires write-back governance.
- Roster roles. Owner, signer, subscriber, exception worker — not “whoever is online.”
- Quiet success. Ran, nothing to write, record still exists. Month-end with zero exceptions is success, not a missing email.
If a vendor cannot show these nouns as objects — not as slides — you are looking at a copilot with a cron job.
Outputs vs actions
Outputs are artefacts: CSV, table, PDF draft, exception list, email body for review. They land on the run page and in notifications. Read-only connectors suffice.
Actions are writes to live systems: CRM stage change, ticket update, approved journal. They follow the same rules as any other write — quoted payload, named signer, write-back governance. A loop does not silently become a write tool because the schedule fired.
Good defaults:
- Month one: outputs only. Prove the recipe matches manual work.
- Month two: one action class with a named signer and a stored rejection test.
- Never: bulk writes before anyone has rejected a payload on this workstream.
Harness engineering covers sensors around model steps. Standing-order loops inherit platform gates for actions without turning the whole job into an agent harness. Loop engineering vs harness engineering is the split.
Anthropic’s guidance on building effective agents advises simple pipelines where a fixed sequence will do. Outputs-first is that advice in operations clothing: prove the list before you post the journal.
Wizard, not chat ritual
Operators configure a standing order from a form: name the job, pick the trigger, attach sources, define outputs, choose who gets notified. Starting a run is an explicit start or waiting for the schedule — not typing “please do the usual” into Slack.
Why this matters:
- Chat rituals depend on memory. The usual drifts. New hires cannot start the job.
- Forms compile intent. Fields become recipe parameters. Parameters version.
- Audit needs objects. A standing order with version 4 is evidence. A thread is not.
McKinsey’s State of AI reports broad use and narrow redesign. Replacing a chat ritual with a form on a scoped workstream is redesign you can measure: time to first output, skip rate, diff versus manual baseline.
Discovery still happens in conversation. The first time you figure out the filters, chat is fine. The tenth time, chat is a tax. Compile after the second successful manual run, not after the twentieth apology.
Where a standing-order loop lives
On a workstream — the shared workspace for one outcome: brief, connectors, people, budget, finish line. See what is an AI workstream.
The loop inherits:
- Least-privilege connectors scoped to this job
- Roster who may view, sign, or receive skips
- Budget if a later step adds a model for exceptions
- Wiki sections the recipe may load as feed-forward context
Standing orders stack on the same workstream. “Weekly exceptions” and “month-end accrual list” can coexist with separate triggers and recipes. They share connectors and governance without sharing a Slack channel.
Four pillars of an enterprise AI platform — workstream, governance, graph, teams — describe the platform a loop plugs into. The loop is not a fourth pillar; it is how unattended work runs inside the workstream.
Thoughtworks on the enterprise AI operating system stresses organisational ownership. A standing order without an owner on the workstream is automation theatre: the recipe will rot, skip rates will climb, and people will return to the thread they trust.
Why you should care
Reliability. The job runs when the trigger fires, even if the usual operator is on leave.
Evidence. Auditors and partners open the run page. NIST AI RMF Measure functions assume you can observe what ran. Skips are observations, not embarrassments.
Cost. No tokens on the happy path. Stanford HAI’s AI Index tracks rising capability and cost. Compiled loops avoid paying for reinterpretation every Monday.
Safety. Unknown paths escalate. A standing order that guesses is an unharnessed agent wearing a schedule.
Regulatory fit. ISO/IEC 42001 wants named actors and operational controls. A loop on a roster satisfies the instinct better than a shared login. GDPR purpose limitation maps to workstream scope. The EU AI Act documentation expectations map to run pages and versioned recipes.
It affects you if the same artefact is due every week, if two people already follow a checklist, and if last quarter’s audit asked “what ran on the 12th” and the answer was a search through chat.
A worked example: month-end accrual list
Finance runs the same accrual exception pass every close: read ERP open items, read the controller’s mapping tab, flag mismatches, send the controller a list — no posting.
Configure once.
- Workstream: “Month-end accrual exceptions — Entity UK”
- Trigger: manual start during the close window, plus optional schedule on close day 3
- Recipe: read ERP (read-only), read mapping sheet, apply rules from wiki section “UK accrual mapping v3”
- Output: exception table on the run page, plus notification to the controller roster role
- Skips: missing mapping row → queue to FP&A; ERP timeout → hard stop with reason
Each close (unattended).
- Controller starts the run or the schedule fires
- Run page shows 142 rows scanned, 7 exceptions, 2 skips (ambiguous business unit on rows 88 and 91)
- Controller works skips in collaborative AI on the same workstream — not in a side message
- No model on the happy path; no journal posts without a signed action later
If row 88 needs judgement beyond rules, assign to a human. Optionally attach an agentic workflow for that queue only after the compiled path proves stable. Agents should be disposable; the standing order remains.
Sarbanes-Oxley does not mention loops. It asks whether an independent person can reconstruct how a number became the number. A run page with inputs, rules version, and skips is reconstruction-friendly.
Walk a second close. Recipe version is still v3. The mapping tab gained a new entity code. The loop skips those rows instead of inventing a mapping. FP&A updates the wiki, the owner versions the recipe to v4, and close day 3 runs clean. That update is loop engineering — not a prompt tweak in a private workspace.
Standing orders vs things you already have
Cron plus script. Fine for engineers. Standing orders add roster, notifications, skip UX, and workstream scope for operators who will never open a repository.
RPA. Screen replay breaks when the interface changes. See loop vs RPA. Prefer API reads and explicit skips.
Personal automation wiring. Good for individual productivity. Weak on named signers, skip queues, and audit export for regulated teams.
Agent in a channel. Re-describes the job every time. See a loop is not an agent. Cost and drift scale with repetition.
Eval harness only. Grades agent runs. Does not replace a standing order that starts them. See eval loops for enterprise agent harnesses.
Shared spreadsheet plus calendar invite. Common, and honest. It is also how the invite survives and the rules do not. Compile the rules; keep the calendar as a trigger if you must.
Human roles on the loop
- Owner. Maintains recipe and wiki references. Reviews skip trends monthly.
- Signer. Approves action classes. Same as governance as a multiplayer primitive.
- Subscriber. Gets notified. May not sign.
- Exception worker. Works the skip queue. May use human-in-the-loop for judgement calls.
Multiplayer AI is several people in the room at once. A standing order is several people aligned on the same run page asynchronously — often more realistic for finance and operations.
Research on hybrid human–AI teams (Yang et al., Nature Human Behaviour, 2022) shows clear role separation improves outcomes. Loops encode machine steps versus human steps explicitly. If everyone is “a user,” you have not assigned override.
What goes wrong
Scheduled prompt. “Run this chat task every hour.” That is a scheduled agent call. No compiled recipe version. No skip semantics. No diff against last week’s baseline.
Silent defaults. Missing values filled, categories invented, emails sent without a skip. Overnight work that “helped” is how wrong rows become official.
Outputs and actions collapsed. The schedule posts because posting was easier to demo than a table. Prove the artefact first.
Ownerless workstream. Connectors exist; nobody reviews skips. The recipe ages in place.
Eval as the loop. A grading harness without a standing order still starts from Slack. See eval loops for enterprise agent harnesses.
God workspace. One workspace for every job destroys purpose limitation. Scope the workstream to the finish line. GDPR cares about purpose; so should you.
Exception class as hidden agent. “If skip, ask the model” injected into the compiled path without a harness. Attach an agentic workflow explicitly, or keep the human queue.
Failure looks like a forwarded screenshot and a disagreement about which filters ran. Success looks like a run page two people can open without asking who started it.
How to start this quarter
One standing order. One workstream. Outputs only for four weeks.
- Pick a job with a written checklist already used by two people.
- Open a workstream with read-only connectors and the real roster. See what is an AI workstream.
- Configure the standing order from a form: trigger, sources, output format, notify list.
- Run twice manually alongside the legacy process. Diff outputs.
- Add skip rules for every difference that required a side message last month.
- Enable the schedule only after skip rate is stable.
- Evaluate with how to evaluate loop engineering before adding actions.
How to evaluate collaborative AI applies when the loop’s output becomes a shared artefact people sign — forecast pack, pipeline commit, accrual list.
If step 4 fails, you have not compiled the path yet. Write the steps again. Do not add a model to paper over a fuzzy recipe.
How this shows up in Nimbus
Nimbus names this object a Loop. A Loop is a standing order on a workstream: trigger, compiled recipe, run page, roster notified. Operators configure it from a wizard — not by re-briefing a chat thread — and each execution is inspectable.
The Loop inherits that workstream’s connectors, wiki context, budget, and write-back gates. Model steps are not implied. If you later attach an agentic workflow to an exception class, harness engineering applies to that branch only.
See what is loop engineering, six things that start a loop, and a loop is not an agent. Product surfaces: workstreams and governance.
Related reading
- What is loop engineering
- Six things that start a loop
- Loop vs workflow vs agent
- What is harness engineering
- What is write-back governance
Sources
Standing orders, not chat
Is a Nimbus Loop the same as an eval loop?
No. An eval loop grades a run after it happens — tests, schemas, read-backs, signer checks. A standing-order loop is the job that admits the run when a trigger fires and then executes a compiled recipe. You need the sensor when you write to a live system or when a model step must be independently verified. You need the standing order when the same job should exist before anyone types. Refuse to treat a passing score as proof that Monday's job started, or a schedule as proof that the output was correct. See eval loops for enterprise agent harnesses.
Do I start a Nimbus Loop from chat?
No. You start from a form with known fields — schedule, sources, outputs, roster — on a workstream. Chat is the right surface for novel work; a standing order is for work you have already compiled. If the only way to start the job is to re-describe it in natural language, you do not have a loop yet. Use chat to discover the path once. Then write the path as steps, attach a trigger, and stop asking the model to remember. Refuse a product that treats an open thread as the compiler for recurring operations.
Can a Nimbus Loop write to live systems?
It can, when the recipe includes an action class and a named signer on the workstream. The default posture is outputs first: a table, a list, a draft that humans can diff against last month. Writes follow the same governance as any other proposed change — quoted payload, named identity, fail-closed if nobody signed. Use actions only after the compiled path matches the manual baseline. Refuse bulk writes in week one, and refuse a schedule that becomes a write tool merely because the clock fired. See what is write-back governance.
What happens when the path is unknown?
The standing order skips with a reason and notifies the roster. A person decides next — or, later, an explicit agentic workflow on that exception class only. Guessing is how operational debt compounds overnight: ambiguous input, silent default, wrong row updated, inbox quiet until finance opens the file. Use skips as first-class outcomes, not embarrassments. Review skip rates on a cadence; a rising count means the recipe or the world changed. Refuse silent best-effort fills inside the compiled path. See a loop is not an agent.
See what governed AI looks like on your stack.
Connect your tools, run a workstream, and keep every decision on your ledger. Start on Free.