Provider-independent guardrails and workflows that build your software, run your research, and write your content.
It lives in your repo as plain commands and notes, not inside any one company's product. Switch tools, switch models, switch vendors: the same loop keeps running. Nobody can flip a switch and take it away.
Runs the same in Claude Code · Codex · OpenCode · and more.
↻ then back to the top, for the next piece of work
Together they are the rhythm: think first, build carefully, prove it, remember it.
It writes a short plan and stops before touching a single file. The plan is the agreement, so nothing gets built that you did not approve.
Decisions and lessons live in your repo. Close everything, come back next week, and the next session opens already knowing where you left off.
Before anything is marked finished, it checks the work against the real code and tests. Anything that can only be proven on the live site is blocked from being ticked off until it has been checked there — that one is enforced by the tool, not just asked for.
A clear label at every step, so you always know whether it is planning, building, or checking the work.
Five questions, one pass, and the plan, the task list, and the checks are written for you.
Point it at a large codebase and three focused readers map it at once, then hand you one short summary to work from.
Each piece of work runs through the same six steps. You always know whether it is thinking, building, or checking that the live site really works.
Keep a short list of what is next. New ideas get parked on the list, not jammed into today's work.
It writes a short plan and stops. You read it, you approve it, then the work starts. The plan is the spec.
It does the work one task at a time, and ticks each one off as it goes. Nothing moves on until the piece in front of it is done.
It checks the work against the plan and tells you, with proof, what passed and what did not. No taking its own word for it.
It runs the checks again, publishes, watches the live site for a minute, and writes down what shipped. One command puts it back if something is wrong.
When something breaks, it works out why, writes it down, and adds a new check so the same gap cannot open twice.
The loop stays the same everywhere: one careful step at a time. On Claude Code you can opt into a faster gear for the slow, repetitive parts — many short-lived helper agents working at once instead of walking a list one by one. It never turns on by itself, and it never changes the result — only the speed.
A second, skeptical agent tries to knock down each "pass," so a test that was quietly weakened to go green gets caught instead of trusted.
On a large existing project, several readers sweep it in parallel and hand back one short brief — faster than reading it end to end.
Every parallel step reads, checks, and reports. None of them writes a line. A parallel build existed briefly and was removed — it sped up the typing, and the slow part of this loop is you reading the plan.
A workflow can spin up many agents at once (up to 16 working together, 1000 over a run) — real token cost — so it only ever starts when you say so.
Why it stays optional: workflows are a Claude Code feature only. On Codex, OpenCode, or a pasted chat there's no workflow runtime, so the loop quietly falls back to the normal one-at-a-time path. It can only ever be a speed-up — never something the loop depends on.
Anthropic's core pitch for building with these models is simple: give the model a loop, tools, and a way to verify — then manage its context. The loop is a hand-authored, human-gated version of that loop. The workflow fan-out is a newer runtime primitive for one slice of it: orchestrating sub-steps deterministically. They are not rivals — one is the frame, the other is a power tool inside it.
The outer loop is the slow, deliberate part — plan before code, prove before shipped, remember across sessions, and refuse to skip a step. It runs the same everywhere, one thing at a time, with you at the gate. This is the part that keeps the work honest.
Inside a single step — checking a list, smoke-testing a deploy, surveying a big repo — many short-lived agents do the work at once, then report back. It never decides what to do or changes the order; it only makes one already-approved, parallelizable step finish faster.
Same principle both times: deterministic control around model calls, and verification by keeping the agent that does the work separate from the agent that judges it — once at the scale of the whole project, once at the scale of a single step. The loop is the conscience; orchestration is the muscle.
Strip it back and it is a work loop with four parts: a plan you approve before work starts, a checklist of what "done" means, a step that demands proof for each item, and a memory that carries between sessions. None of that is about code. It fits any work where "looks finished" and "actually done" are dangerously different things.
Each row becomes "every claim has a real source." The proof step is fact-checking, and it will not accept a claim backed by a misquoted or made-up source. Going live means opening the real source and confirming it says what you claim.
Your checklist is the brief: covers these points, this tone, both languages at parity, a real call to action. "Go live" means published, links work, the page renders. Memory holds your voice and style so the next piece starts aligned.
The strongest fit. Every requirement is a row with evidence attached, and the decision log is an audit trail. A draft your team approved is not the same as filed with the regulator: the same rule in a different costume.
Course material, where rows are learning objectives. Proposals and grants, where every requirement is answered and "go live" is submitted before the deadline. Data reports, where no finding lands without the number behind it. Team runbooks that improve themselves after each miss.
It earns its keep when "done" is something you can write down and proof actually matters. For open exploration with no quality bar, the plan and checklist are overhead you can skip.
A way of working with no gaps. Every meaningful moment leaves a written trace: the decisions, the timing, the context. You can always see what happened, and always pick up exactly where you left off.
When a real decision gets made, it is written down with the options that were weighed and why this one won. Months later you see not just what was chosen, but why.
Close the laptop mid-task, come back next week, and the work resumes already knowing what you were doing, what is next, and what was blocking you.
Each step leaves a written, timestamped trace. Look back and see exactly what happened, in order, with no reconstructing it from memory.
When a piece of work finishes, a short record is saved of what got built, what was checked, and where it landed. The busiest part of the loop is no longer invisible.
Before you step away, a tidy, fixed-shape summary is kept: current task, what is next, what is blocking. The next session reads it instantly.
The things it commits to, and the ones it deliberately said no to.
Most AI agent frameworks aim at the wrong problem. The models can already write the code. What is missing is anything that holds one accountable between sessions — and that turns out to be a files-in-your-repo problem, not an infrastructure one.
The inspiration comes from our earlier build — the world's first brand strategy harness, ai.brandguide.me. Built between August 2025 and March 2026 to reach full capacity, with many new things still coming. Try it free and see how it guides you when building a new brand.
Inside Claude Code, Codex, OpenCode, or another environment. No accounts, no infrastructure, nothing new to learn.
/plugin marketplace add bencium/bencium-marketplace
/plugin install bencium-loop@bencium-marketplace
Restart your tool, then run /bencium-init in any folder. New project or existing one, both work.
The same commands fall back to plain numbered questions in claude.ai, Cursor, and other tools.