Deep-Solve / AI Operating Model

Loop Engineering: What It Is, and Your Plan to Use It

You are 70% there already. The work is not inventing loops. It is wiring three missing pieces onto what you already run, on one workflow first.

Prepared for Anthony June 14, 2026 Sources: 8 primary (read in full)

TL;DR

A loop is one machine: a maker agent does work, a separate checker grades it, the checker's notes become the maker's next instruction, state lives in a file, and a hard stop ends it. That is the whole thing.
The loop is commodity (a dozen public guides, and Claude Code already ships /loop and /goal). Your real moat is your proprietary data (ticket + decision history) and your verifiers (the checks that decide "good enough"). Build those, not a fancy loop.
I am pushing back on "apply loops to everything." That is the most expensive beginner mistake. Loops only pay off when work repeats, can be objectively verified, and is bounded. Looping everything burns tokens and ships work you can't keep up with reading.
Build one loop first: Pam. Repeating, checkable, already 70% built, keeps the human approval gate. Jarvis-as-clone is the reward you unlock later, with checkpoints, not full autonomy.
Then package it as a guided "loop-starter" skill for the team, after Pam proves the template. I need 5 decisions from you (bottom of page) to start.

1. What loop engineering actually is

The clean mental model, from the people who named it:

Skill	Your role
Prompt engineering	You drive the car. Type a prompt, read the result, type the next one. Every step needs you.
Context engineering	You load the GPS with the right route (the right info for the next step).
Loop engineering	You set the destination and the car drives itself. You design the system once. The system runs the prompts.

Boris Cherny (head of Claude Code) said it plainly on June 2: "I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude. My job is to write loops." Peter Steinberger (OpenClaw) echoed it; Addy Osmani (Google) named it "loop engineering." That is the entire origin story.

The anatomy of one loop

Part	What it does
Trigger	Starts the loop: a schedule, a PR, a CI failure, or you typing `/loop`.
Maker	The agent that produces the work.
Checker	A separate agent that grades the maker's output. Its findings become the maker's next instruction. This is the single most important part.
State file	A markdown file (or board) on disk that holds what's done and what's open. The model forgets between runs; the file is its memory.
Stop condition	A hard exit set before the run: max iterations, a budget ceiling, or an objective rule like "all tests pass and lint is clean."

Your understanding from Slack was correct. The one step most people miss is that the verifier has to be a separate checker. A model grading its own work justifies what it already did instead of catching where it failed. That is the difference between a loop that improves and a loop that just agrees with itself on repeat.

2. Where I push back on you

You said you want to apply loops to everything. I'd push back on that hard, because every source agrees it is the costly beginner trap.

Don't loop everything A loop only pays off when ALL of these are true: the work repeats (weekly or more), there is an objective way to verify "good," you can absorb the token cost of retries, and the agent can run and test its own output. Miss one and the loop costs more than it returns. (Uber capped Claude spend at $1,500/person/month after teams burned a year's budget in four months with no stop conditions.)

Your real moat is not the loop The loop mechanism is already a commodity. The two things only you have are your proprietary data (Pam's ticket history, your decision history in the second brain) and your verifiers (the checks that decide "good enough"). Chase better data and better checkers, not a fancier loop. This is the single most important strategic point on this page.

You are 70% there Loops persist intent in anchor files: a vision/goals file, an operating-rules file, the per-run instruction, and a growing library of tested skills. You already have all of these. Your Pam playbooks, your learned-rules file (cst-learned.md), your skills folder, your second brain, your crons. You are not starting from zero. The job is wiring, not inventing.

3. Your two questions, answered directly

Q: Is observability the same as my scheduling tab? Should I copy Datadog onto it?

Partly, and not yet. Your scheduling tab is a status view (what is scheduled). Observability in the loop sense is a trace view: for every run, what did it do, did it pass or fail, and why. Datadog shows you what an agent did and almost nothing about how to fix it. The 2026 frontier is one step past that: the harness repairs itself. A failing trace gets diagnosed, the fix is verified against the exact input that failed, and that failure is locked as a regression test so it cannot recur.

The move Don't rebuild Datadog on the scheduling tab. You already have the seed: your cron-health dashboard (the daily dead-man's-switch, the Google Sheet, the Slack alerts). That is observability for your automations. Extend that to log per-loop traces (run, outcome, error, fix), rather than bolting monitoring onto the scheduling tab. Build the self-repair step only after one loop is live and actually drifting.

Q: Does the loop self-teach? Can I point it at Pam to train her on history + new data so she replies at my quality and gets better? And eventually Jarvis as my clone?

Yes, that is exactly the right use case, and you already half-built it. The pattern is called "evolve context": the agent improves by reflecting on past runs, distilling what worked into reusable skills on disk, and updating its own prompts from failure analysis. Pam's nightly backtest already does a version of this: she answers historical tickets, gets compared to the real human answer, and the teachable patterns get distilled into her playbooks. That IS a self-learning loop.

The Jarvis caveat that matters Jarvis as your "clone" is the highest-leverage target and the worst place to start. He is an ambient, high-judgment agent that touches irreversible actions (messages to real people). His verifier is subjective ("did he decide like Anthony?"), so a second agent checking him is just "a second optimist" with no ground truth. Both Anthropic's own engineering team and Lance Martin are explicit: ambient agents like this need the most human checkpoints, not the fewest. Grow Jarvis's judgment over time by feeding decision history and gating the risky moves. Never hand him full autonomy.

4. The plan, broken into micro-objectives

Seven steps, sequenced so each one earns the next. Status reflects where we are today.

MO-1Decide now

Pick the first loop

One workflow, not all. Decision gate. My pick is Pam (see section 5). Needs your sign-off.

MO-2Next

Audit Pam's existing loop against the checklist

Verify three things structurally: is the checker truly separate from the maker (not self-grading), is there a hard stop + budget, is the learned state on disk clean. Confirm all four prerequisites (repeats / verifiable / budget / self-testing) hold. Output: a gap list.

MO-3Next

Wire the missing pieces onto Pam

Close the gaps from MO-2: a separate checker agent, a hard stop + token budget ceiling, clean disk-state. Keep the existing human approval gate (proposals → dashboard → you approve). Nothing customer-facing goes fully unattended yet.

MO-4Then

Add observability + a self-repair step

Fold per-loop traces (run, outcome, error) into the cron-health dashboard. Add a weekly check for "harness drift" (the loop quietly breaking as models/tools change). This answers your observability question.

MO-5Then

Supervised dry-run, then release

Watch it run for 2 to 3 ticks against real data before letting it sleep. Verify outputs against source. Only then let it run unattended within its gate.

MO-6After Pam proves it

Templatize into a team "loop-starter" skill

Package the proven pattern into a guided skill, shipped through your existing eg-skills pipeline. Teammates run it, it interviews them about a recurring task, scaffolds their maker/checker/stop/state, and dry-runs it. Battle-tested template, not theory.

MO-7Ongoing

Write the pattern down once, canonically

One reference file for "how we build a loop here," so every future loop (and every teammate) starts from the same spine instead of re-deriving it. One canonical source, no drift.

5. Recommendation: build the Pam loop first

The decision: which single workflow becomes your first real loop?

Pam (CST bot)My pick

Why it wins: repeating daily, has a semi-objective verifier (the real human answer + policy + CSAT), and it is already ~70% built (playbooks, distill cron, approval gate). Lowest risk, highest payoff, fastest to prove. It is also the only candidate whose output is checkable enough to run safely.

Jarvis (your clone / assistant)Not first

Highest ceiling, but ambient, high-judgment, and touches irreversible actions. Its verifier is subjective, so the checker has no ground truth, and its mistakes are sent messages you can't unsend. This is the agent that needs the most checkpoints. It is the reward you unlock after Pam, with gates, not the place to start.

Observability / scheduling tabNot first

Valuable, but it is the monitoring layer for loops you haven't hardened yet. Premature. It becomes MO-4, after Pam is live.

The reasoning in one line Loop safety is governed by how cheaply you can verify the output. Pam's output is checkable against a known-right answer. Jarvis's "good decision" is not. So Pam first, Jarvis later with checkpoints. Your own Jarvis independently reached the same call in Slack, which is a good cross-check.

6. Pros and cons of going down this road

Pros

Removes you as the bottleneck on repeating work. Few tokens in, a lot of output back.
Compounds: every loop run sharpens the playbook, so it gets cheaper and better over time.
You build on infrastructure you already own. Days, not months.
The team skill turns your one win into everyone's leverage.
Quality goes up, not just speed: a separate checker catches misses a human reviewer skims past.

Cons / risks

Comprehension debt: the loop ships faster than you read. Green checks mean it passed the test, not that you understand what shipped.
Token surprises if budgets/stops aren't set first.
Security: an unattended loop is an attack surface. A 2026 audit found 520 agent skills leaking credentials. Scope tokens, isolate runs.
Self-grading drift if the checker isn't genuinely separate.
Over-application: looping subjective work where "done" is judgment, not a measurable rule.

7. What you don't know that you'll wish you did

The lessons an expert would hand you on day one.

The loop is commodity; your data and checkers are the moat. Don't gold-plate the machine. Spend your effort on better training data and sharper verifiers.
The maker must never grade itself. The model that wrote the work is too nice to its own homework. A separate checker is non-negotiable. This one rule separates loops that improve from loops that spin.
Set the stop condition before you run, never during. "Fix only the majors, one final pass, stop after two loops" plus an objective exit ("tests pass, lint clean").
State on disk, not in context. The model forgets everything between runs. A markdown file or board is the spine that lets a loop resume after days.
Green does not mean understood. The loop merges faster than anyone reads. Comprehension debt is the silent killer. You still have to read what it ships. Stay the engineer, not just the person who presses go.
The lower the verification bar, the safer the loop. Loop boring, easily-checked work first (a stale version string, a missing test). Loop judgment work only as far as the checker can confirm it.
Token budgets are a hard ceiling, not a suggestion. Set an iteration cap and a dollar/token budget per loop, or you get a billing surprise orders of magnitude over plan.
The harness itself drifts. Even a good loop breaks over weeks as models and tools change. You need observability traces plus a self-repair step, or it silently rots while every check still shows green.
Ambient, high-autonomy agents need MORE gates, not fewer. Autonomy and human checkpoints scale together. The more a loop can do unattended, the more carefully you gate its irreversible moves.
Skills compound, prompts don't. Turn recurring work into named skills the loop reuses. Re-deriving the same logic every tick just burns tokens.
Always dry-run 2 to 3 ticks watching it, before you let it sleep. Never go straight to unattended on anything that matters.

8. The team-shareable loop skill

You asked for a prompt or skill teammates can give to their Claude, where it learns from it and customizes to their own work. That is real, and the right shape is a guided skill, not a static prompt (a prompt can't interview them or scaffold files).

"loop-starter" skill, concept A teammate runs /loop-starter. It (1) interviews them about a task they do repeatedly, (2) checks it against the four prerequisites and tells them honestly if it's a bad loop candidate, (3) identifies their maker, checker, stop condition, and state file, (4) scaffolds the anchor files and the loop command, and (5) runs a supervised dry-run before going live. Because it reads their actual work and second brain, it customizes to them automatically. Ships through your existing eg-skills install-once + daily-auto-pull pipeline, so edits propagate to everyone without reinstalling.

Timing: build this at MO-6, after Pam proves the pattern. Shipping an untested loop template to the whole company is the same over-application mistake at team scale. Prove it once, then template it.

9. What I need from you to start

Answer by number (just reply in chat, e.g. "1 Pam, 2 keep gate, 3 $400..."). Each has my recommendation so you can also just say "yes to all."

1. First loop target? Pam, Jarvis, or a different workflow you have in mind.

My rec: Pam. Lowest risk, highest payoff, already 70% built.

2. Autonomy level for the first loop? Keep the current human-approval gate (you approve before anything customer-facing), or go fully unattended within budget caps.

My rec: keep the gate. It already exists and it's the right call for customer-facing answers.

3. Token / dollar budget ceiling per loop run (and per month)? I need a real number to set the hard stop. This is the guardrail against a billing surprise.

My rec: start conservative, name a monthly number you'd be calm seeing spent unattended.

4. Observability home? Extend the existing cron-health dashboard to log loop traces, or build a new observability view on the Work Hub scheduling tab.

My rec: extend cron-health. Don't build new; you already have the seed.

5. Team skill timing? Build the loop-starter skill now in parallel, or wait until Pam proves the template (about 1 to 2 weeks).

My rec: wait. Ship a proven template, not a theoretical one.

Bonus. Your candidate list: which of your workflows do you personally think repeat often enough AND are objectively checkable enough to be future loops? You know your work better than I do. I'll rank them.