{"slug": "orchflows-build-self-improving-loops-in-one-sentence", "title": "Orchflows: Build self-improving loops in one sentence", "summary": "Orchflows launched a self-improving agent loop that lets users build workflows in one sentence, autorouting requests to the smallest subagent-driven workflow. The open-source tool offers 37 composable skills, domain-blind workflows, and self-improvement capabilities via `orch-self-improve` and `orch-evolve`. It supports Claude Code and Codex on Windows and POSIX systems.", "body_md": "Build a self-improving agent loop in one sentence:\n\n```\nBuild me a workflow that loops over each project in my GitHub and\nsaves a summary of its open issues. After the loop is done, the\nworkflow runs self-improve on itself.\n```\n\nOr don't do that — just ask Claude or Codex for any one-off task of any size, like you normally would. Every request autoroutes to the smallest subagent-driven workflow that can prove it's done: a one-line answer stays a one-line answer; a product-sized build gets a frozen spec, tickets, parallel subagents, and a verification gate. 37 composable skills. Claude Code and Codex, Windows and POSIX. By default the planner/reviewer subagent is Fable 5 on high effort on Claude Code and GPT-5.6 Sol on ultra on Codex; workers are Sonnet 5 on xhigh and GPT-5.6 Sol on high. Think of it as an upgraded, cross-harness Dynamic Workflows.\n\nSkill libraries break the same four ways:\n\n**Overly specific, handcrafted prompts.** As models get smarter, overprescription degrades output quality.**Manual chaining by the user.** First run`/brainstorm`\n\n, then run`/to-prd`\n\n, then run... blah blah blah.**Domain-specific.** The workflow for writing a blog is basically the workflow for shipping a feature: outline the goal, build each section in parallel, review the output for cohesion and consistency. You don't need a`/write-blog`\n\nskill and a`/build-feature`\n\nskill.**Static.** Run 100 hits the same snags as run 1.\n\norchflows answers each in structure:\n\n**Tiny, composable skills.** Every word of every skill has to fight for its life. Heavily avoids context rot.**Workflows, not prompts.** Every request autoroutes to the smallest workflow. No more memorizing skill names or chains.**Domain-blind.** Smart model outlines the task → cheaper parallel subagents deliver → smart model reviews. The same shape works for blogs, code, or research.**Self-improving.**`orch-self-improve`\n\ncan run at any time to mine the logs for friction points in agent behavior and reasoning, and improve the workflows over time.`orch-evolve`\n\nis its sibling: a tournament-style improvement loop over any artifact, runnable or static.\n\n**One brick, one job.**`orch-deliver`\n\nships,`orch-critique`\n\nattacks,`orch-judge`\n\nscores blind,`orch-loop`\n\niterates,`orch-fix`\n\nproves the cause before repairing it.**One stud pattern.** Six frozen contracts — spec, work-item, delegation, verdict, worklog, pack-signature — are the only interfaces. Anything that emits one plugs into anything that takes one.**Swappable baseplates.** Workflows are domain-blind; a pack (code | content | research | design) is pure data that retargets the whole tower. The pipeline that ships a feature also ships a research report — swap one pack, change zero control flow.\n\nYou snap bricks by naming them; the agent snaps them by routing. Same bricks either way.\n\n```\ngit clone https://github.com/DanMcInerney/orchflows\ncd orchflows\n./install.sh          # install.cmd on Windows\n```\n\nThe wrapper resolves an interpreter (uv → python3 → python; any\nPython 3 works) and\nauto-detects your harnesses — Claude Code (`~/.claude`\n\n), Codex\n(`~/.codex`\n\n) — configuring whichever exists. Update: `git pull`\n\n,\nrerun. Committable per-project routing block: `python install.py --project PATH`\n\n. Uninstall: `python install.py --user --uninstall`\n\nremoves only what it generated; `--dry-run`\n\npreviews either.\n\nJust talk. Routing reads the request and picks the smallest shape:\n\n```\n> fix the flaky login test\n# orch-fix: reproduce it, prove the cause, guard the repair\n\n> why did memory double last release?\n# orch-investigate: one read-only lane, answer cited from primary evidence\n\n> ship dark mode\n# orch-spec → orch-deliver: frozen spec, tickets, parallel subagents\n# on a rolling frontier, one review gate, final verification\n\n> build me a custom workflow that reads all the documentation, then\n  researches similar projects, then builds a spec doc to copy their\n  best features and implements them\n# orch-build: the chain is admitted as a project-local skill,\n# callable by name from then on\n```\n\nOr name the bricks yourself:\n\n```\n> orch-loop orch-deliver until `pytest -q` exits 0\n> orch-panel these three cache designs — blind judges, pick one\n> orch-critique src/auth under the security lens\n```\n\nOr build your own custom workflow:\n\n```\n> build me a workflow that does spec > deliver, then always updates\n  the documentation afterwards (favoring edits and deletions over\n  additions), and automatically PRs and merges it\n```\n\nCustom workflows are project-local. In the example above, if you were\nworking in `my-personal-site/`\n\nyou'd get a workflow named something\nlike `/site-work-and-merge`\n\n, callable only when you're working in\n`my-personal-site/`\n\n.\n\nRouting too eager? `orch-off`\n\nstands it down for the session. The\nrouting law is `rules/topology.md`\n\n§2, installed as\n`~/.orchflows/host-block.md`\n\n.\n\nChain any bricks and put `orch-self-improve`\n\nlast:\n\n```\n> my release workflow: orch-investigate what merged since the last\n  tag → orch-deliver the release notes under the content pack →\n  orch-self-improve\n```\n\nEvery run auto-logs its friction — retries, missing inputs,\nworkarounds — under an always-on law, and `trace.py`\n\nlogs every\nsession's agent reasoning and secret-redacted tool calls.\n`orch-self-improve`\n\nmines the logs into single-owner proposals you\naccept or reject. Proposals I've seen in my own usage:\n\n- Offload a repeated piece of agent reasoning to a deterministic script\n- A tiny AGENTS.md addition telling agents to use the packaged Python\ninterpreter instead of whatever\n`python`\n\nis on`$PATH`\n\n- Remove overlapping\n`orch-verify`\n\nsteps from a workflow to speed it up - Add a documentation-update step to a workflow because the user kept asking for it manually\n\nThe coolest part of `orch-self-improve`\n\nis that you can run it on\nitself. I run `orch-self-improve`\n\nacross all sessions in a project,\nthen point a second `orch-self-improve`\n\nrun at the first one.\n\n`orch-visualize`\n\nrenders anything you hand it as a verified Mermaid\ndiagram — a workflow, your session trace, a codebase, a website, a\nprocess from a doc. Every diagram is syntax-verified against a real\nMermaid renderer before it comes back, and on request it emits a\nself-contained HTML page. This is its drawing of the delivery pipeline\nthat ships every orchflows run:\n\n``` php\nflowchart TD\n    spec[\"orch-spec — freeze exactly what should be made\"] --> pack{\"pack: code | content | research | design\"}\n    pack --> ws[\"orch-workspace — clean, isolated working area\"]\n    ws --> dec[\"orch-decompose — cut the spec into ordered tickets\"]\n    dec --> frontier[\"orch-frontier — dispatch every ready ticket\"]\n    frontier --> task[\"orch-task\"]\n    task --> del[\"orch-delegate — hand the ticket to the right agent\"]\n    del --> exec[\"executor: orch-tdd | orch-draft / orch-edit | orch-investigate / orch-synthesize | orch-render\"]\n    exec -.-> chk[\"orch-check — fresh agent double-checks (when needed)\"]\n    exec --> integ[\"orch-integrate — accept or reject the returned work\"]\n    chk --> integ\n    integ -.->|rejected| frontier\n    integ --> ver1[\"orch-verify — run any remaining checks\"]\n    ver1 --> frontier\n    frontier --> gate[\"orch-review-fix — critique, repair confirmed defects, re-verify\"]\n    gate --> final[\"orch-verify — final result matches the original request\"]\norchflows\n│\n├── Layer 0 · contracts/ — Shared forms that keep every part of the system speaking the same language\n│   ├── delegation     — Says what another agent should do, use, avoid, and return\n│   ├── pack-signature — Lists what every project-type setup must provide\n│   ├── spec           — Records exactly what the user wants made\n│   ├── verdict        — Records whether a check passed and what proves it\n│   ├── work-item      — Describes and tracks one piece of work\n│   └── worklog        — Records the progress and current state of a larger job\n│\n├── Layer 1 · skills/ — Things the agents know how to do\n│   │\n│   ├── kernel/ — Basic building blocks used by the rest of the system\n│   │   ├── orch-check          — Has a fresh agent double-check the work and correct problems\n│   │   ├── orch-critique       — Reviews something and lists the most important problems\n│   │   ├── orch-decompose      — Breaks a large job into smaller pieces in the right order\n│   │   ├── orch-delegate       — Hands one clearly defined task to another agent\n│   │   ├── orch-elicit         — Asks the user when a decision cannot safely be made for them\n│   │   ├── orch-integrate      — Decides whether returned work is acceptable and can be used\n│   │   ├── orch-investigate    — Researches one focused question using reliable evidence\n│   │   ├── orch-judge          — Rates one option using standards agreed on beforehand\n│   │   ├── orch-mechanize      — Turns a repeatedly performed step into a reusable script\n│   │   ├── orch-synthesize     — Combines findings from several sources into one answer\n│   │   ├── orch-verify         — Runs the agreed checks to see whether the work passes\n│   │   ├── orch-worklog        — Updates the job's progress record\n│   │   └── orch-workspace      — Prepares a clean and safe place in which to work\n│   │\n│   ├── engines/ — Reusable ways of organizing work\n│   │   ├── orch-task      — Takes one ready piece of work from start to acceptance\n│   │   ├── orch-frontier  — Starts each piece of work as soon as the work it needs is finished\n│   │   ├── orch-loop      — Repeats work until an agreed check says it is done\n│   │   └── orch-panel     — Uses several independent reviewers to compare choices fairly\n│   │\n│   ├── workflows/ — Complete processes made from the smaller building blocks\n│   │   ├── orch-spec          — Turns a request into a clear, agreed plan\n│   │   ├── orch-deliver       — Runs a project from the agreed plan to a checked final result\n│   │   ├── orch-goal          — Runs the delivery process again to improve the result further\n│   │   ├── orch-bench         — Sets the rules and tests before different options are compared\n│   │   ├── orch-evolve        — Creates and compares improved versions over several rounds\n│   │   ├── orch-diagnose      — Reproduces a problem and finds what is actually causing it\n│   │   ├── orch-fix           — Finds the cause of a problem, repairs it, and proves it stays fixed\n│   │   ├── orch-repair        — Applies the smallest change that fixes a known problem\n│   │   ├── orch-review-fix    — Reviews the result once, fixes valid problems, and checks it again\n│   │   ├── orch-build         — Creates or changes a reusable part of the orchflows library\n│   │   ├── orch-fixture       — Saves a finished task as an example that can be run again later\n│   │   ├── orch-self-improve  — Studies past difficulties and proposes improvements to the system\n│   │   └── orch-triage        — Sorts a list of work into what is ready, blocked, or needs a person\n│   │\n│   ├── instances/ — Skills that perform a particular kind of hands-on work\n│   │   ├── orch-tdd               — Writes software in small steps and checks each step with tests\n│   │   ├── orch-resolve-conflicts — Decides how to combine two sets of changes that clash\n│   │   ├── orch-draft             — Writes one section using only the supplied information\n│   │   ├── orch-edit              — Combines separate sections into one consistent document\n│   │   └── orch-render            — Builds a screen and checks how it actually looks and behaves\n│   │\n│   └── utilities/ — Small optional helpers\n│       ├── orch-visualize — Turns supplied information into a diagram\n│       └── orch-off       — Stops orchflows from automatically choosing skills\n│\n├── Layer 2 · packs/ — Setups for different kinds of projects\n│   ├── orch-code-pack     — Tells the system how to organize, save, and check software work\n│   ├── orch-content-pack  — Tells the system how to organize and review written documents\n│   ├── orch-research-pack — Tells the system how to answer questions using trustworthy sources\n│   └── orch-design-pack   — Tells the system how to build and visually check interfaces\n│\n└── Layer 3 · compositions/ — Example playbooks showing how the parts can be combined\n    ├── delivery-loop        — Repeats delivery until a chosen measurement says to stop\n    ├── drift-canary         — Reruns known examples to detect changes in agent behavior\n    ├── evidence-to-document — Researches a subject first, then turns the findings into a document\n    ├── evolve               — Produces several versions and selects the strongest one\n    ├── feature-plus-docs    — Builds a software feature and then documents what was built\n    ├── improvement-delivery — Turns an approved process improvement into a tested change\n    ├── renovate             — Reviews an existing project and completes selected improvements\n    └── skill-tournament     — Tests competing versions of a skill to see which works best\n```\n\nFour layers, dependencies pointing one way. `contracts/`\n\nis the narrow\nwaist: six hash-pinned data shapes that are the only interfaces between\nskills. `skills/`\n\nis everything callable — kernel primitives that call\nno other skill, engines that add control flow, workflows assembled from\nboth, instances that do the domain's hands-on work, and a couple of\nutilities. `packs/`\n\nis per-domain data, never control flow.\n`compositions/`\n\nis non-normative worked examples, free to churn.\n\n```\nUNITS OF WORK — the orchflows ladder\n│\n├── (floor) Tested script\n│     no model, no ticket — a unit of certainty, not of work\n│     orch-mechanize keeps pushing repetition down here\n│\n├── U0 — Direct answer\n│     question answered from context already in hand\n│     no deliverable change → no record, no ticket\n│\n├── U1 — Verified ad-hoc ticket\n│     one ticket + one execution + one external verdict\n│     U1×N: a small ticket graph with edges, run on the frontier\n│\n├── U2 — The run (spec → delivery)\n│     a frozen spec governs a ticket graph → rolling frontier →\n│     one review gate → final verification\n│\n└── U3 — Composition\n      control flow OVER units: chained runs, goal loops\n```\n\nEvery request lands on the cheapest rung that can still prove it's done. A question you can answer from context costs nothing; a small fix gets one ticket and one external verdict; only work that genuinely needs a frozen spec pays for one; and repetition keeps getting pushed below the floor into tested scripts that need no model at all.\n\n```\npacks/\n├── orch-code-pack     — delivers code        · deterministic oracles · executor orch-tdd\n│                        workspace: git, one worktree per work item\n├── orch-content-pack  — delivers documents   · judged oracles        · executor orch-draft, assembly orch-edit\n│                        workspace: document tree with outline slots\n├── orch-design-pack   — delivers rendered UI · capture oracles       · executor orch-render\n│                        workspace: git plus render (view × breakpoint × state)\n└── orch-research-pack — delivers answers     · evidence oracles      · executor orch-investigate, assembly orch-synthesize\n                         workspace: evidence store of lane packets\n```\n\nA pack is pure data — no control flow. It supplies the domain's vocabulary, oracle classes, executors, workspace rules, and design principles, all satisfying one frozen pack-signature, so everything the library builds inside a domain stays cohesive. Stamp a different pack on the spec and the identical pipeline ships code, documents, research, or UI.\n\n**Cross-harness.** One library drives both Claude Code and Codex, on Windows and POSIX.**Workflows persist.** A custom workflow is admitted as a project-local skill — versioned, callable by name, improvable — not regenerated from scratch each session.**Verification is structural.** Named oracles, fresh-context checkers, and one review gate stand between an executor's claim and \"done\" — the agent never grades its own homework.**Self-improving.** Friction and full session traces are always logged;`orch-self-improve`\n\nmines them into concrete fixes to the workflows themselves — including to itself.**Survives session death.** Specs, tickets, and worklogs are files in`.orch/`\n\n, so any fresh context can resume a run mid-flight.**Smallest-first routing.** One intake for everything: a one-line question never pays workflow ceremony, and a launch never gets typo-fix rigor.", "url": "https://wpnews.pro/news/orchflows-build-self-improving-loops-in-one-sentence", "canonical_source": "https://github.com/DanMcInerney/orchflows", "published_at": "2026-07-18 17:49:59+00:00", "updated_at": "2026-07-18 18:21:29.397571+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "artificial-intelligence"], "entities": ["Orchflows", "Claude Code", "Codex", "Fable 5", "GPT-5.6 Sol", "Sonnet 5", "DanMcInerney"], "alternates": {"html": "https://wpnews.pro/news/orchflows-build-self-improving-loops-in-one-sentence", "markdown": "https://wpnews.pro/news/orchflows-build-self-improving-loops-in-one-sentence.md", "text": "https://wpnews.pro/news/orchflows-build-self-improving-loops-in-one-sentence.txt", "jsonld": "https://wpnews.pro/news/orchflows-build-self-improving-loops-in-one-sentence.jsonld"}}