Skip to content
Agentmart
Submit a tool

loop-orchestration

Reference loop-orchestration example; a local loop host chains governed runx turns through receipts, budgets, context, and stop policy.

Skill by ZachDreamZ

IndexedMIT
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/zachdreamz-loop-orchestration

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Reference loop-orchestration example; a local loop host chains governed runx turns through receipts, budgets, context, and stop policy.

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found
Runs as
Node.js package

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/loop-orchestration

What's inside

Skill name
loop-orchestration
Description
Reference loop-orchestration example; a local loop host chains governed runx turns through receipts, budgets, context, and stop policy.
License
MIT
Instructions
82 lines in SKILL.md · view on GitHub

Before installing

  • Ships executable scripts

Files (6)

  • SKILL.md
  • X.yaml
  • SKILL.md · context/loop-operator/
  • loop-host.mjs · loop/
  • turn.mjs · loop/
  • run.sh

SKILL.md (first lines)

# Loop Orchestration

This example shows the runx pattern for long-running agent work:

1. An outer loop host decides whether work should continue.
2. Each iteration submits one normal governed runx turn.
3. Each turn seals a receipt before the loop can advance.
4. The next turn consumes only explicit inputs, projection state, and receipt
   summaries.

Nothing in this example adds a loop engine to `runx-core`. The loop host is just
an application script. In production it could be a hosted service, Temporal
workflow, LangGraph app, n8n workflow, or another orchestrator.

## Run It

```sh
sh examples/loop-orchestration/run.sh
```

The script runs three demonstrations:

- **success:** two governed turns complete a tiny build-review loop;
- **refusal:** a requested tool is outside the loop policy, so the loop stops
  before another turn is submitted;
- **context gate:** an agent-task turn pauses with digest-bound skill context
  and explicit `allowed_tools`, showing what a host or managed provider would
  receive without requiring a model key.

The output prints each run id, receipt id, decision, and next-turn reason.

## Check The Harness

For the repeatable inline harness, use a fresh receipt store and the demo
signing identity. A clean store avoids mixing receipts signed by different local
test issuers.

```sh
tmpdir="$(mktemp -d)"
RUNX_RECEIPT_SIGN_KID=runx-demo-key \
RUNX_RECEIPT_SIGN_ED25519_SEED_BASE64=QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI= \
RUNX_RECEIPT_SIGN_ISSUER_TYPE=hosted \
"${RUNX_BIN:-crates/target/debug/runx}" harness examples/loop-orchestration \
  --receipt-dir "$tmpdir" \
  --json
```

## What This Proves

The important boundary is not the Node script. It is the contract:

- A **loop** owns scheduling, durable loop state, projection, and stop policy.
- A **turn** is one runx skill/graph run with explicit authority and one sealed
  receipt.
- A **handoff** is an artifact/result the loop host can inspect; it is not
  hidden prompt continuation.
- A **projection** is derived from receipts and admitted signals, not from
  ambient memory.

## Security Rules

- The loop has a max-turn budget.
- The turn runner receives only declared inputs.
- Tool choices are checked against loop policy before another turn is allowed.
- Context skills are advisory, digest-bound, and untrusted.
- A pause or refusal is a healthy result; the loop does not keep prompting until
  it gets the answer it wants.

## Adapting The Example

Replace `loop/loop-host.mjs` with your real orchestrator and keep the same
shape:

```text
load projection -> submit runx turn -> read receipt/result -> check stop policy
```

Do not move product-specific scheduling or state into the kernel. If a loop
needs to wake up later, persist the loop state in the host and submit another
runx turn when policy allows.

From ZachDreamZ/runx, MIT.

More from ZachDreamZ/runx

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
Jun 13, 2026 (4 months ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
Website
runx.ai
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from ZachDreamZ

Cite this page

loop-orchestration skill. Agent Mart. https://agentmart.dev/skills/zachdreamz-loop-orchestration (last updated 2026-10-24)