DRYAS

Free · open source

Dryas Workflow Framework

A target operating model for AI software delivery. It sets down who decides, who builds, what each agent may touch, what is remembered, when to pay for a stronger model, and what must be true before work merges. It runs on its own core, on Claude Code, Codex and OpenCode. The method is the asset; the tools are replaceable.

Try itRead it on GitHub

01 · The problem

The problem it solves.

  1. Building before deciding: the agent codes from a one-line prompt and builds the wrong thing well.
  2. Agents that wander: a form fix also "tidies" three other modules, and parallel agents overwrite each other.
  3. A big model for everything: every call goes to the most expensive model, or all go to the cheapest and fail.
  4. "Done" that is not done: the agent says the tests pass, and they were never run.
  5. Silent autonomy: it installs, deletes and pushes on its own.
  6. Amnesia: each session relearns what failed last week.

Dryas is not autonomous. You approve the design, and you have the final say on anything that goes live.

02 · Asked vs enforced

Asked for, or enforced.

Your agent today compared with Dryas
AreaYour agent todayWith Dryas
DesignStarts coding from a one-line prompt.Nothing is built until you approve the design.
Scope“Tidies” three modules on the way past.Each task names its files. Edits outside them are denied.1
ProofSays the tests pass.Reports what it ran. Three reviewers (spec, quality, over-engineering) and a verify step gate the merge.
CostRuns on whatever model is the default.Cheapest first. It climbs a tier only after a failure, and logs why.
GatesInstalls, deletes and pushes on its own.A judge screens risky commands. Installs, deletes, pushes, overwrites and settings changes always need you.

1 The lock covers file edits. While a task is active, a shell command that writes files asks you first and is logged.

task 2 · Scope: src/auth/**
Edit src/billing/invoice.ts
scope lock: src/billing/invoice.ts is outside the scope of active task(s) 2
Edit src/auth/rate-limit.ts ✓
The agent wasn't asked to stay in scope. It couldn't leave.

03 · The loop

One loop. Two human gates.

The loopBrainstorm, Plan, Judge, Build, Escalate, Review, Ship, then back to Brainstorm. A person approves at Brainstorm and at Ship. A failed task climbs a tier and returns to Build.climb a tier, retryBrainstormyou approvePlanJudgeBuildEscalateReviewShipyou ship
  1. Brainstorm. You and the orchestrator settle the design. Nothing is built until you approve it.
  2. Plan. The design is split into small tasks, each with its files and a done check.
  3. Judge. A judge answers narrow questions: is this risky, which tier fits.
  4. Build. Each task is built test-first, in its own copy of the project.
  5. Escalate. A task that fails climbs one tier, with the reason logged.
  6. Review. Three reviewers and a verify step gate the merge.
  7. Ship. You decide what ships. The outcome is remembered.

A one-file fix may skip Plan, Judge and Build. It never skips Review.

04 · The ladder

Spend more only when cheaper failed.

The escalation ladderA task starts on the fast tier and climbs to standard, strong and frontier only after failing; it stops at the first success. After the frontier tier, a person takes over. Every climb is logged with a reason.fastfailed → climb, loggedstandardfailed → climb, loggedstrongfailed → climb, loggedfrontierfailed → climb, loggeda personpassed → stop, no climb
  1. Start on fast. Tasks start here.
  2. Then standard. Takes the task when fast failed, once the cause is looked for.
  3. Then strong. Takes it when standard failed, once the cause is looked for.
  4. Then frontier. Used only if strong failed too.
  5. Then a person. Takes over with every report, if frontier failed.
  • Tasks start on the cheapest tier, never the top one. ESC-1
  • Before each climb, the cause of the failure is looked for. ESC-4
  • Every climb is logged with its reason. ESC-5
  • After the frontier tier, a person takes over. ESC-6

05 · Own core

Runs on its own core.

No API key. No Node. No network needed to judge.

Judge
A deterministic local judge answers narrow questions: is this step risky, which tier fits. Measured on a public labelled corpus and gated in CI. A remote judge model is an optional upgrade.
Memory
What was tried, what worked, what failed. Read before planning, written after each task.
Process
Eight skills: brainstorm, plan, test-first, debug, verify, request review, receive review, worktree.
The hook chain, in a fixed orderscope lockgatememoryobserver
  1. scope lock
  2. gate
  3. memory
  4. observer
One chain: scope lock, then gate, then memory, then observer. The order is a file, tested like code.

06 · We ship with it

We ship with it.

Dryas Studio delivers every client project with it.

For your project: you approve the design before anything is built. Nothing merges until it's tested and reviewed. A person signs off on anything that goes live.

Start a projectSee SidecraftFlowObserve live demo

07 · Five layers

Also an operating model.

Formally, the Dryas Workflow Framework: five layers, a set of roles, metrics with healthy ranges, maturity levels, and a draft specification any harness can implement.

  1. MemoryWhat was tried, what worked, what failed.
  2. GovernanceWho decides, and what each AI may touch.
  3. ExecutionSmall tasks, kept apart, built test-first.
  4. EscalationA stronger model only when a cheaper one failed.
  5. ReviewNothing merges unverified. A person ships.

08 · Who decides

Who decides.

Orchestrator
The lead AI. Brainstorms with you, plans, hands out tasks and pulls the results together. It decides when the judge is unsure.
Judge
Answers narrow yes, no or pick-one questions. It never writes code or plans (GOV-6).
Builders
Each takes one task on the fast tier, works test-first inside its own files, and reports back in a fixed format (EXE-7).
Stronger tiers
Standard, then strong, take a task a cheaper tier could not finish, after the cause of the failure is looked for.
Frontier tier
The most capable model. It runs only if the strong tier fails too.
A person
Approves the design, approves installs, deletes and settings changes, and decides what goes live (WF-2, GOV-4, GOV-5).

Every decision an AI cannot make has a named human owner.

09 · Calibrated

Calibrated, not guessed.

The loop logs its own numbers. A weekly tune reads them and proposes changes. A person applies them.

  • < 500 msjudge latency
  • 5–25%judge override rate
  • 0–1scope-lock denials per task
  • < 20%strong-tier escalation rate
  • 0frontier use without a strong-tier failure
  • ≤ 2review rounds per branch

Healthy ranges. A metric out of range is a prompt to look, not an automatic change.

10 · Maturity

Adopt it a level at a time.

  1. L0Ad hoc

    Turn on An AI assistant, no loop.

    Move up when Starting point.

  2. L1Gated

    Turn on Design first, review before merge, only people push.

    Move up when Every merge had an approved design and a review; at most two review rounds.

  3. L2Scoped

    Turn on Plan files, worktrees and the scope lock.

    Move up when At most one scope-lock denial per task.

  4. L3Laddered

    Turn on Cheap builders and the escalation ladder, every climb logged.

    Move up when Strong-tier climbs under 20%, no frontier use without a strong-tier failure.

  5. L4Target

    Turn on The judge, memory and a weekly tune.

    Move up when Stay here.