Loops

Loops mean two different things in OpenEng, and it helps to keep them apart:

Each iteration of a global loop is an ordinary turn, so it runs on an iteration strategy like any message you type. The first half of this page covers strategies; Global loops covers the second kind.

Iteration strategies

A loop strategy is the iteration strategy the engine runs a turn with: how it observes, acts, reviews, plans, and retries. You almost never pick one by hand: the engine scores every request and chooses the right loop for you. Strategies are configured per config (the config builder's Settings step, under Loop posture), so you can constrain or tune which strategies a config may use.

How the engine decides (no modes)

There is no user-facing "chat / coding / goal" mode anymore. For every message you send, the engine does two things, internally:

1. Score the complexity. The engine scores the request from 0 to 1 (with an embedded model or a heuristic router) from your message and the previous turn for context. At or above the threshold (0.65 by default) the turn is planned; below it runs direct. In the web app you'll see this under the chat box as planned mode or non-planned mode with the score.
2. Pick the loop + the models. A direct turn runs the single agent loop (react); a planned turn runs the planner pipeline (plan-execute-replan), and each step is classified again to pick its role model from the config's role models (the agent, a sub-agent, a researcher, and so on).

So "goal mode" is just what a complex request looks like — you never select it. The threshold is operator-tunable (see Configuring loops below).

The strategy catalog

Loops apply at every altitude — the top-level turn, a delegator, and a leaf worker each run a loop. A planned turn's per-node executors run their own react loop on their role's model; a delegator runs orchestrator-worker.

These five are the complete set a config can use. loops.openeng.app also publishes a longer reference of the internal iteration techniques behind them, at loops.openeng.app/reference; those are documentation, not strategies you can select or loops you can run.

Configuring loops

In the Console, open your config and go to its Settings step; the Loop posture section holds the config's strategy settings. A config carries three:

• Loop strategies (the allowed set) — the strategies this config may use. All five are allowed by default; at least one must stay allowed. Restrict it (for example, allow only react + reflection) to keep a config simple and predictable. Allowing orchestrator-worker asks you to acknowledge it first: it fans out to sub-agents, which costs more and adds failure surface.
• Per-category defaults — the strategy each category starts on: Chat, Coding, Goal runs and Research. The shipped defaults are chat → react, coding → react, and goal runs (the high-complexity, agentic lane) → plan-execute-replan; a category left on (built-in baseline) uses the engine's own default. Only an allowed strategy can be a default, and removing a strategy from the allowed set clears any default that used it. Device Use isn't listed: it runs its own dedicated screenshot-and-act loop.
• Policy tuning — bounds on a run: max iterations (28 by default), max sub-agent iterations (12), concurrency cap (10), the reviewer's revise cap (2), a token ceiling (0 means none), the compaction trigger (the share of the context window at which the conversation is compacted, 0.82 by default), and switches for stuck detection (on by default), speculative workers (on) and durable checkpoints (off). Per-iteration validation is shown locked on: the reviewer checks every iteration, and no config can turn that off.

These ride the published config artifact, so the engine resolves them the same way it resolves your models and agents — publish the config and they're live.

The durable wrapper

durable is special: it doesn't replace a base strategy, it wraps one. Every step is checkpointed, so a crashed or stopped run resumes from the last good step instead of restarting, and a human-in-the-loop approval can suspend and later resume the run. Use it for long, expensive, or approval-gated work.

Worked example

You ask: "Build a small FastAPI app with a SQLite store and a health route, then write tests."

1. The scorer rates it high (multi-step build) → planned.
2. The engine runs plan-execute-replan: it plans a DAG (scaffold → db layer → routes → tests), executes each node, and replans a node that fails its build-verification.
3. Each node is classified — the code nodes run on your agent model, a research node (if any) on your research models (the document and code researchers) — and writes real files through the worker layer, asking your permission before it touches anything outside the workspace.

A follow-up — "how do I run it?" — scores low → direct (react): a single quick answer, no planning ceremony.

Global loops

A global loop is a loop you define and start: "iterate all my Jira tickets until every one is done." It's a request, a source of iterations, and a stopping rule. The engine runs it one iteration at a time, and every iteration starts fresh from complexity analysis: each one is a full turn that independently takes the direct or the planned path, exactly like a message you type.

Anatomy of a loop

The stopping condition is one of:

• allItemsDone — keep listing the work items until the list comes back empty, so items that appear or reopen during the run are worked too. It needs a workItems source.
• conditionMet with a text — after each iteration, the config's reviewer model judges the result against the text and ends the loop when it's satisfied. With no reviewer model bound, the loop runs until maxIterations.
• unbounded — no natural end; the loop runs to its maxIterations or token bound.

Whatever the condition, maxIterations always applies, so a confused loop can't spin forever.

The loop catalog

As of September 25, 2026, loops.openeng.app publishes six loops:

The two repeat loops, Backlog burn-down and Failing-tests until green, run as published.

A work-items loop lists its items by calling the connector, cell or MCP server it names (its target id), so that source has to be available in the config it runs on. Its args (such as the Jira project in the ticket sweep's query) are part of the loop as published. As of September 25, 2026, none of the four work-items loops has a source that works as published:

• Inbox-to-done names a Gmail connector (connector_def_gmail) that no catalog offers yet.
• Alert triage watch expects an MCP server with the id mcp_pagerduty, but MCP servers you add in the Console get ids of the form mcp_usr_….
• Nightly PR review sweep and Ticket sweep use the GitHub and Jira integrations, whose endpoints return a web page instead of JSON, so their calls fail (Integrations).

Adopt, select, publish

1. Open Loops in the Console (Building blocks → Loops) and switch to Catalog. Adopt makes your own copy of a loop (id loop_usr_…) that carries the loop's definition and remembers its catalog id; loops you've already adopted show an Adopted badge. Mine lists your adopted loops.
2. Open the config and pick the loops in its Loops step. The step lists only loops you've adopted.
3. Publish. The published config carries the full definition of every selected loop, and the engine stores them under ~/.openeng/loops/ when it starts (definitions in defs/, run records in runs/; OPENENG_LOOPS_DIR moves the folder).

The Loops page is adopt-only: there's no New loop button, because the Console can't author a loop from scratch yet.

Run a loop

In the Web Console at app.openeng.app, a message that starts with /loop controls global loops instead of starting a chat turn:

A run keeps going in the background while you do other things. If the engine restarts, runs that were still going resume from their records: a work-items loop skips the items it already finished, and a repeat loop continues after its last iteration.

When a config selects loops, the engine offers only those: /loop start refuses any other loop id.

Plan & tier notes

Adopting loops, setting a config's loop posture and publishing are open on every plan. Running loops needs the openeng engine, which starts only on an active Pro plan (Plans & billing).

Troubleshooting

"loop '…' is not selected by the served configuration". The config the engine serves selects loops, and this one isn't among them. Add it to the config's Loops step and republish.

/loop list says no loops are defined. Nothing published has reached this engine yet. Adopt a loop, select it in the config, publish, and restart the engine so it loads the new version.

Publishing fails with loop_def_missing. The adopted loop has no definition, which happens when its catalog entry couldn't be validated at adoption. Adopt it again from the catalog.

A conditionMet loop runs to its maximum. The reviewer never judged the condition satisfied, or the config has no reviewer model bound. Bind one in the config's Models step, or make the condition text more concrete.