agentic examples

177 runnable examples of plan-and-execute Ruby

Every example runs offline, checks itself, and exits honestly - built across twenty rounds of persona-driven development on agentic. Each page shows a real captured run. Point your agent here to add one.

allTesting & Verification · 41Data & Pipelines · 26Scheduling & Concurrency · 24Observability & Ops · 23Reliability & Recovery · 20Developer Experience · 18Plans & Graphs · 15Patterns · 5Live LLM · 3Fun & Strange · 2

177 shown

The Adaptive Throttle

The Adaptive Throttle: nobody TELLS you an upstream's capacity - you discover it. An AIMD controller (TCP's algorithm) probes upward one lane at a time and halves on congestion, converging on the capacity the provider …

Data & PipelinesSamuel Williams

The Allocation Audit

The Allocation Audit: every object is a promissory note the GC collects on later. This audit counts exactly what each framework operation allocates (GC.stat's total_allocated_objects is an exact counter, not a sample) …

Observability & OpsKoichi Sasada (ko1)

The Always-On Profiler

The Always-On Profiler: the mini-profiler heresy is that profiling belongs in PRODUCTION, on EVERY request, visible to the people who wrote the slow code - not in a lab you visit twice a year. Every plan gets a badge …

Observability & OpsSam Saffron

The API Reference Generator

The API Reference Generator: walk the registry, emit reference docs for every capability - types, enums, bounds, policies - straight from the contracts that VALIDATE the calls. Documentation that enforces itself cannot …

Data & PipelinesPiotr Solnica

API Riffs

API Riffs: before an API ships, sketch it three ways and READ the call sites out loud - the design work happens in the comparing, not the committing. Subject: the journal's group-commit knob (which shipped this round as …

Observability & OpsKasper Timm Hansen

The API Surface Census

The API Surface Census: your public API is not what you documented - it's every public method a user CAN call, because that's what semver binds you to. This census counts the whole surface, then cross-references 100 …

Data & PipelinesYehuda Katz (wycats)

The ASCII Darkroom

The ASCII Darkroom: a photo pipeline where the photos are made of characters and the chemistry is arithmetic. One NEGATIVE comes in; the enlarger develops it into a print; then three derivative baths run in PARALLEL off …

Data & PipelinesJanko Marohnić

The Assembly Doctor

The Assembly Doctor: syntax_suggest for plans. When a 12-step plan won't assemble, "KeyError: task not found" is technically true the way "syntax error, unexpected end" is technically true - it names the symptom and …

Developer ExperienceRichard Schneeman

The Attachment Pipeline

The Attachment Pipeline: Shrine's central lesson is that file uploads are a TWO-PHASE commit wearing a file input - phase one (cache) must be instant and disposable, phase two (promote + derivatives) is slow, …

Data & PipelinesJanko Marohnić

The Auto-Screencast

The Auto-Screencast: a plan that records its own tutorial. Every step carries narration and code; as the plan executes, it emits a markdown episode - prose, code fence, actual output - and then the strange part: the …

Testing & VerificationChris Oliver

Backoff Conformance

Backoff Conformance: every strategy x jitter combination, a thousand draws each through an injected seeded RNG, checked against the documented bounds. Retry timing is a contract like any other - and now that rng: is …

Testing & VerificationJeremy Evans

The Bakery Rush

The Bakery Rush: two ovens, thirteen orders, one queue - and the morning is decided before the first tray goes in, by ENQUEUE ORDER. A bakery is a queue wearing an apron: the plan is the queue, the concurrency limit is …

Testing & VerificationRosa Gutiérrez

The Batch Import

The Batch Import: 500 rows of the kind of data people actually upload - typos, header drift, impossible combinations - run through one contract. Good rows proceed; bad rows land in a REJECT FILE with the field, the …

Data & PipelinesAndrew Kane

The Behavior Spec

The Behavior Spec: ruby/spec exists because "MRI does X" is not a specification - it's an implementation detail wearing one. When TruffleRuby and JRuby needed to know what Ruby MEANS, the answer had to be executable, …

Testing & VerificationBenoit Daloze

The Borrow Checker

The Borrow Checker: I brought Rust's ownership model to a language that never asked for it, and I regret nothing. Task outputs get ownership semantics: a value can be MOVED to exactly one consumer (who may then mutate …

Testing & VerificationSteve Klabnik

Bulk Import

Bulk Import: the job every team writes badly once - load N thousand rows into the database without melting it, and survive the crash that WILL happen at row 2,743. Three disciplines, all boring, all load-bearing: BATCH …

Data & PipelinesJean Boussier

The Burst Absorber

The Burst Absorber: three waves of requests slam a credential with a ceiling of 3 (Agentic::RateLimit - this round's release). The ceiling holds, the queue absorbs, and the per-request wait times show exactly what …

Scheduling & ConcurrencySamuel Williams

The Cancel Drill

The Cancel Drill: structured concurrency's core promise is that cancellation is PROMPT - stop means stop, not "finish everything and then agree you'd stopped". Three drills measure what each cancel path actually …

Testing & VerificationSamuel Williams

The Capability Autoloader

The Capability Autoloader: Zeitwerk's contract, ported. Drop a file at packs/text/summarize.rb defining Text::Summarize, and the capability "text.summarize" exists - no registration ceremony, no init file that lists …

Testing & VerificationXavier Noria

Capability Evals

Capability Evals: golden test cases run against registered capabilities, scored, and gated. When you swap a lambda for an LLM (or one model for another), the eval suite is what tells you whether quality moved - …

Testing & VerificationAndrew Kane

The Capability Resolver

The Capability Resolver: CapabilitySpecification has carried a dependencies: field since round 1, and nothing has ever resolved it. Resolution is a SEARCH problem (pick versions so every constraint holds, backtrack when …

Developer ExperienceAndré Arko

The Capacity Planner

The Capacity Planner: "how many workers do we need?" is not a feeling, it's Little's Law - L = lambda x W. The journal already holds W (task durations, as percentiles across runs); give the planner your target arrival …

Scheduling & ConcurrencyNate Berkopec

Carrier Quotes

Carrier Quotes: the most common integration problem in commerce - ask three shipping carriers for rates, and cope with the fact that on any given afternoon one is slow, one is down, and one has quietly changed its …

Reliability & RecoveryAvdi Grimm

The Changelog Scout

The Changelog Scout: reads real git history, classifies every commit through a contract-checked capability, and drafts the release notes - features first, fixes second, docs summarized in one line.

Developer ExperienceAndrew Kane

The Circuit Breaker

The Circuit Breaker: when an upstream is down, the cheapest request is the one you don't send. The breaker trips after 3 consecutive retryable failures (or ONE non-retryable - no auth error deserves a second strike), …

Reliability & RecoveryMike Perham

The CLI Contract

The CLI Contract: a command-line tool is an API whose clients are shell scripts, cron, CI, and a tired human at 2am - and each of those clients reads a different channel. Data goes to stdout, diagnostics to stderr, the …

Data & PipelinesDavid Bryant Copeland

The Collaboration Tracer

The Collaboration Tracer: lifecycle hooks record every message the orchestrator sends and every reply that comes back, then the run is drawn as a sequence diagram. Object-oriented programs are conversations; this makes …

Observability & OpsSandi Metz

The Command Bus

The Command Bus: every command is a composed capability with its OWN declared contract (new in this round - compositions used to be contract-less). The bus is just the registry: dispatching a command validates it at the …

Data & PipelinesPiotr Solnica

Composed Limits

Composed Limits: a real provider enforces BOTH a billed quota and a connection ceiling. quota.and(pool) - new this round - holds the two laws in one limiter, and the run proves each law bound the traffic in its own …

Reliability & RecoverySamuel Williams

The Concurrency Key

The Concurrency Key: "at most one sync per TENANT, any number of tenants at once" is the concurrency control every multi-tenant job system eventually needs - global limits are too blunt (one tenant's backlog throttles …

Scheduling & ConcurrencyRosa Gutiérrez

The Confident Pipeline

The Confident Pipeline: timid code checks nil at every step because it trusts nothing, including itself. Confident code validates once, at the barricade, and then speaks in declarative sentences. Same pipeline, written …

Data & PipelinesAvdi Grimm

Configurable Cops

Configurable Cops: a style guide nobody can configure is a style FIGHT on a delay timer. RuboCop's deepest lesson isn't any single cop - it's the .yml: enable/disable per cop, parameters instead of hardcoded taste, and …

Observability & OpsBozhidar Batsov

Connection Pool Care

Connection Pool Care: the production incident with the most misleading symptoms - the database is fine, the app is fine, and nothing works, because the connection pool drained one leaked checkout at a time. The leak is …

Reliability & RecoveryJeremy Evans

The Contract Cop

The Contract Cop: RuboCop for capability specs. Contracts are the most-read documents in this framework - six tools consume them - so they deserve a style guide with teeth: named cops, an offense report, and …

Data & PipelinesBozhidar Batsov

Contract Fixtures

Contract Fixtures: example payloads in docs rot the day the contract changes. So don't write them - DERIVE them. This generator reads a capability's declarations and produces a minimal fixture (required keys only) and a …

Developer ExperiencePiotr Solnica

The Contract Fuzzer

The Contract Fuzzer: for every registered capability, generate inputs that SHOULD pass its declared contract and mutations that SHOULD fail it, then check the validator agrees. A contract that accepts garbage or rejects …

Testing & VerificationJeremy Evans

The Contract Overhead Bench

The Contract Overhead Bench: "should we validate every call?" is a performance question, so answer it with a measurement instead of a vibe. Benchmarks the validator across contract sizes and rule counts, then prices it …

Observability & OpsAaron Patterson

The Contract Semver Advisor

The Contract Semver Advisor: two versions of a capability's contract, every change classified as breaking or compatible - FROM THE CALLER'S and THE CONSUMER'S seats, which disagree about what "breaking" means. The …

Developer ExperiencePiotr Solnica

The Cost Estimator

The Cost Estimator: price the plan BEFORE running it - per-task token estimates times a pricing table - gate on budget, then reconcile estimate against actuals afterward. LLM plans spend real money; nobody should learn …

Observability & OpsAndrew Kane

The Coupling Cartographer

The Coupling Cartographer: which files lean on which? Every file is surveyed for the constants it DEFINES and the constants it REFERENCES; a fan-in task joins the two into a dependency graph and reports the load-bearing …

Data & PipelinesXavier Noria

The Critical Path

The Critical Path: after a run, combine the graph topology with measured durations to find the chain of tasks that determined the wall clock. Optimizing anything OFF that path is charity work - and this proves it by …

Plans & GraphsAaron Patterson

The Dead Letter Office

The Dead Letter Office: three days of journaled runs, every failure collected and triaged by what the errors said about themselves - retryable failures go on the requeue manifest, non-retryable ones get parked with a …

Reliability & RecoveryMike Perham

The Deploy Train

The Deploy Train: lint -> test -> build -> canary -> ship, where a red gate stops the train and everything behind it reports CANCELED, not skipped-and-shrugged. Run it twice: healthy train, then a canary failure. The …

Testing & VerificationDHH

The Deprecation Shepherd

The Deprecation Shepherd: removing an API is easy; removing it WITHOUT breaking anyone is a data problem wearing an etiquette costume. The failure mode is universal - a warning gets printed for two years, nobody reads …

Observability & OpsRafael França

Discovery Testing

Discovery Testing: most people use test doubles to ISOLATE code that already exists. The better trick is using them to DISCOVER code that doesn't: start at the top with fakes for collaborators you haven't designed yet, …

Testing & VerificationJustin Searls

The Documentation Surveyor

The Documentation Surveyor: measures YARD comment coverage for every public method in a lib/ tree. One survey task per file fans out; a single report task fans all the surveys in through the dependency pipe and renders …

Data & PipelinesXavier Noria

The Document Refinery

The Document Refinery: an HTML-to-digest pipeline where every stage assumes the input is hostile until proven boring - because it is. Real-world markup arrives with script injections, event handlers, javascript: hrefs, …

Reliability & RecoveryMike Dalessio

The Drip Campaign

The Drip Campaign: every product ships one - welcome on day 0, tips on day 3, the gentle upsell on day 7 - and every team ships the same three bugs with it: the DOUBLE SEND (cron fired twice; your users got two welcomes …

Scheduling & ConcurrencyKasper Timm Hansen

Duck Agents

Duck Agents: the agent: seam asks one question - "can you be called with a task?" - and five differently-shaped objects all answer yes: a lambda, an instance, a Method, a curried proc, and a decorator wrapping any of …

Plans & GraphsSandi Metz

The Dungeon Crawl

The Dungeon Crawl: a quest is a plan, rooms are tasks, and doors are dependencies. The map is drawn from the orchestrator's own graph BEFORE the run - then the party delves, and the treasure fans in.

Plans & GraphsMatz

The Durable Batch

The Durable Batch: six billable "LLM calls" run under an ExecutionJournal. Mid-batch, the process dies for real - exit!, no cleanup, the honest kill -9. Then a second process replays the journal and finishes the batch …

Scheduling & ConcurrencyMike Perham

The Error Taxonomy Drill

The Error Taxonomy Drill: three tasks fail three different ways - a rate limit (retryable, says the error itself), an auth failure (not retryable, says the error itself), and a mystery error (no opinion, so the policy's …

Testing & VerificationMike Perham

The Etude Machine

The Etude Machine: deliberate practice for plan-builders. An etude is a small broken plan, a hint, and a hidden test - you fix the plan until the test passes, exactly like an exercism exercise. But the machine holds …

Testing & VerificationKatrina Owen

Eval Scorers

Eval Scorers: the same eval set scored four ways - exact match, keyword containment, numeric tolerance, and a judge rubric. Exact scoring drowns one real failure in wording noise; the right scorer per field reports …

Testing & VerificationAndrew Kane

EventProf for Plans

EventProf for Plans: TestProf taught test suites to answer "where does the time GO?" by group, not by file. Same question for plans: tag every task by its kind (llm:, db:, render:), collect durations from the lifecycle …

Testing & VerificationVladimir Dementyev

The Executable Runbook

The Executable Runbook: every ops wiki has a page titled "If the queue gets stuck" with eleven steps, three of which are stale, one of which is dangerous, and none of which have been run since the person who wrote them …

Testing & VerificationDavid Bryant Copeland

The Exquisite Corpse

The Exquisite Corpse: three artists each draw one part of a creature without seeing the others' work; the assembler receives all three parts BY NAME and stacks them. The surrealists played this on folded paper; we play …

Plans & GraphsMatz

The Failure Weather Report

The Failure Weather Report: a journal of three days, read as a forecast. Retryable failures are WEATHER - showers that pass on their own or with an umbrella. Non-retryable failures are CLIMATE - no amount of waiting …

Reliability & RecoveryMatz

Fair Share

Fair Share: two tenants, one upstream. The global ceiling is fair to REQUESTS - first come, first served - but tenant A brings 6 workers and tenant B brings 2, so "fair to requests" quietly means "A gets triple". …

Scheduling & ConcurrencySamuel Williams

Feature Flags for Plans

Feature Flags for Plans: shipping a new pipeline step shouldn't be a deploy decision - it should be a FLAG decision. A tiny Flipper- shaped adapter (boolean, actor, percentage gates) decides per run whether the …

Data & PipelinesJohn Nunemaker

The Fireworks Show

The Fireworks Show: choreography IS concurrency. A show is three staggered volleys and then a finale - five shells that must burst TOGETHER, which is only physically possible if someone can light five fuses at once. We …

Scheduling & ConcurrencySamuel Williams

The Flaky API Drill

The Flaky API Drill: a task that times out twice before succeeding, run under a retry policy with exponential backoff and a journal. The timeline shows every attempt, every backoff gap, and the journal proves the whole …

Testing & VerificationMike Perham

The 422 Generator

The 422 Generator: turn a ValidationError into the API error document your frontend actually wants - message, allowed values, bounds - using ONLY what the exception carries (new this round: #expectations). The renderer …

Data & PipelinesPiotr Solnica

The Freight Desk

The Freight Desk: a quoting capability whose tariff book is written as cross-field contract rules (new this round). Per-key checks catch nonsense; rules: catch the LEGAL-LOOKING orders that violate policy - and every …

Developer ExperienceJeremy Evans

The Frozen Mandala

The Frozen Mandala: generative art with a purity contract. Eight painter tasks each paint one sector of a mandala IN PARALLEL from the same frozen inputs - a seed, a palette, a rule. Purity buys two properties you can …

Developer ExperienceMarc-André Lafortune

Gem Scout

Gem Scout: describe what you need, get a ranked shortlist of gems. Search and scoring are separate capabilities; the search backend is the pluggable seam - offline it's a bundled index, online swap in the real WebSearch …

Developer ExperienceAndrew Kane

The Gentle Deadline

The Gentle Deadline: most deadline code is violent - a timeout fires, everything dies, the user gets an error page at 30.0 seconds that could have been a good-enough answer at 29. This plan knows which of its tasks are …

Reliability & RecoveryYukihiro Matsumoto

Gentle Deprecations

Gentle Deprecations: the hard part of maintaining a framework isn't adding the better name - it's the two years of not breaking anyone who used the old one. This shims a renamed contract field through three release …

Scheduling & ConcurrencyRafael França

The Graph Critic

The Graph Critic: reviews a plan's dependency structure BEFORE it runs, the way you'd review a class diagram. God tasks, deep chains, and orphans are design smells in a graph exactly as they are in objects - and they're …

Plans & GraphsSandi Metz

The Graph Invariants Prover

The Graph Invariants Prover: the reflection API makes promises - order respects edges, roots have no dependencies, depth is the longest path, leaves feed nothing. Documentation asserts these; this referee PROVES them, …

Testing & VerificationXavier Noria

The Graph Style Guide

The Graph Style Guide: RuboCop for plans. Cops with thresholds run against any orchestrator's graph - depth, fan-in, orphans, and the style rule I care most about: fan-ins of two or more should NAME their dependencies, …

Developer ExperienceSandi Metz

Graph to Specs

Graph to Specs: the plan's structure dictates its test plan - roots need fixture cases, joins need one case per missing tributary, leaves need output assertions. This generates the RSpec skeleton from the graph, so …

Testing & VerificationSandi Metz

The three-line agent

The three-line agent. Run me with no API key at all:

Developer Experience

The Helpful 404

The Helpful 404: every system has three doors where users arrive with a typo - the URL, the config file, and the CLI - and at all three the system is holding the complete list of correct answers at the exact moment it …

Observability & OpsYuki Nishijima

The Hill Chart

The Hill Chart: Basecamp's answer to "how's it going?" - work climbs the hill while it's still uncertain (queued, waiting on dependencies) and rolls down once it's just execution. Three live snapshots of a running plan, …

Scheduling & ConcurrencyDHH

Honest Doubles

Honest Doubles: every fake LLM in every agent test suite is lying a little - the question is whether anyone checks. The discipline: (1) don't mock what you don't own - wrap the vendor in an adapter whose interface YOU …

Testing & VerificationJustin Searls

Hostile Inputs

Hostile Inputs: a parser's real spec is what it does with input nobody intended. The journal's replay parses a file that - by the journal's own reason for existing - may end mid-write. In round 12 this probe caught the …

Testing & VerificationMike Dalessio

Hot Config Reload

Hot Config Reload: change the server's configuration without dropping a request - a problem every long-running process has, and one with two classic wounds. Wound one: TORN READS. Update the live config hash field by …

Scheduling & ConcurrencyEvan Phoenix

The Implementation Shootout

The Implementation Shootout: two candidates for the same capability, one eval set, and a verdict computed instead of vibed. v1 is a fast regex; v2 is a slower keyword-weight model. The scoreboard reports quality AND …

Testing & VerificationAndrew Kane

The Incident Report

The Incident Report: a nightly batch dies at 3am. The on-call's first three questions - what ran? what broke? what do I resume? - answered from the journal replay, formatted for the incident channel. Nobody greps logs …

Observability & OpsMike Perham

The Invariant Sentinel

The Invariant Sentinel: domain invariants checked after EVERY task, from a lifecycle hook. When a task leaves the world in an illegal state, the sentinel names the task, names the broken law, and stops the plan before …

Plans & GraphsJeremy Evans

The Jitter Shootout

The Jitter Shootout: none vs equal (+/-25%, the default) vs full (uniform over [0, delay], new this round) - same forty workers, same synchronized failure, three retry-arrival histograms. Pick your herd size with your …

Reliability & RecoveryMike Perham

The Job Adapter

The Job Adapter: your Rails app already has a vocabulary for background work - perform_later, retry_on, discard_on - and the fastest way to adopt a new tool is to let it speak that vocabulary. This wraps a plan in an …

Testing & VerificationChris Oliver

The Journal Audit

The Journal Audit: seven tools now trust the journal, so the journal itself gets audited - well-formed lines, monotonic timestamps, no success without a start, no double-success, plan_completed present. A corrupted …

Observability & OpsJeremy Evans

The Journal Cinema

The Journal Cinema: an execution journal is a film negative. The run happened once, in real time, unwatched - then the negative sits in a JSONL can holding everything: who started, who failed, who came back, to the …

Observability & OpsRyan Tomayko

The Journal Tail Pager

The Journal Tail Pager: production journals grow like production tables, and the question asked of both is always the same one - "what happened RECENTLY?" Answering it by replaying the whole file is SELECT * wearing a …

Observability & OpsAkira Matsuda

The Schema Export

The Schema Export: a capability contract emitted as draft-07 JSON Schema (new this round), then PROVEN faithful - the same payloads are judged by Agentic's validator and by an independent interpreter reading only the …

Data & PipelinesPiotr Solnica

The Kanban Board

The Kanban Board: a plan rendered as the three columns everyone actually understands - To Do, Doing, Done - reprinted at every state change while the plan runs. No standup, no sync meeting, no PM tool subscription: the …

Scheduling & ConcurrencyDHH

The Kill Switch

The Kill Switch: feature flags answer "who should get this?"; kill switches answer a grimmer question - "how fast can a human make this STOP?" Every capability that talks to money, email, or an external API needs a big …

Reliability & RecoveryJohn Nunemaker

The Knee Finder

The Knee Finder: runs the same plan at increasing concurrency limits, measures wall time and total queue-wait via the task_slot_acquired hook, and recommends the limit where adding lanes stops paying. Guessing …

Scheduling & ConcurrencyAaron Patterson

The Lightning Talks

The Lightning Talks: five speakers, five minutes each, one GONG. The lightning talk is conference culture's greatest API: a hard timeout with applause. Speakers are tasks on a single-track stage (concurrency 1 - there …

Testing & VerificationAkira Matsuda

The Live Dashboard

The Live Dashboard: lifecycle hooks publish events onto an Async::Queue; a consumer task IN THE SAME REACTOR renders the plan's state as it changes. This is the "streaming observability" the architecture documents …

Live LLMSamuel Williams

Live Goal Planner

Live Goal Planner: the step every offline example skips, run for real. You hand agentic a GOAL in plain language; TaskPlanner asks an LLM to break it into tasks - each with an agent spec (name, purpose, instructions) - …

Live LLM

Live Import Mapper

Live Import Mapper: bulk_import's sibling with the stub removed. The mechanical 80% of an import (batch, upsert, journal) never needed a mind - but the semantic 20% does: marketing's CSV says "E-Mail Addr" and "Tier", …

Live LLM

The Markov Bard

The Markov Bard: the smallest language model that can still embarrass you. Order-2 Markov chain, trained on a corpus of commit messages, generating new ones - and the point isn't the generator (40 lines, no …

Testing & VerificationAndrew Kane

The Mirror Plan

The Mirror Plan: every task ships its own inverse, so every plan has a REFLECTION - same graph with the arrows flipped, undo agents in place of do agents - and running plan-then-mirror returns the world to its exact …

Reliability & RecoveryLuca Guidi

Money Discipline

Money Discipline: every money bug in production is the same three bugs - floats for currency, arithmetic before validation, and rounding decided at the last minute by whoever's line of code got there first. This runs an …

Observability & OpsNoel Rappin

The Namespace Cartographer

The Namespace Cartographer: maps a gem's constant tree and audits every file against the constant Zeitwerk expects it to define. One orchestrator task per file; Prism reads the actual definitions.

Plans & GraphsXavier Noria

The Observer Effect

The Observer Effect: profilers are not free, and the strangest number in performance work is the one almost nobody measures - the cost of measuring. This example instruments a workload with 0, 1, 2, and 3 layers of …

Scheduling & ConcurrencySam Saffron

The Omakase Scaffold

The Omakase Scaffold: `rails new` for plans. You bring six lines of intent - a name and some steps. The generator brings the menu: journaling on, retries configured, concurrency chosen, a runnable file with your name on …

Scheduling & ConcurrencyDHH

The Onboarding Trail

The Onboarding Trail: a codebase is a place people live, and new teammates don't need a map of every pipe - they need a TOUR: which room to enter first, and why each room makes sense given the ones you've seen. This …

Developer ExperienceSarah Mei

The One-File API

The One-File API: an endpoint is a contract wearing HTTP. Declare the capability once and the rest is derived - the 422s (with relation rules explained), the 201, and the machine-readable schema your client generator …

Data & PipelinesDHH

The Perf Diff

The Perf Diff: run the plan before and after a change, diff per-task durations, and flag regressions - with the one qualifier that decides whether anyone should care: is the regressed task ON the critical path? Off-path …

Observability & OpsAaron Patterson

Perf History

Perf History: last release's run left a journal; this release's run is compared against it. No synthetic baseline, no same-process rerun - the baseline is what production actually did, keyed by task description, …

Scheduling & ConcurrencyAaron Patterson

The Performance Detective

The Performance Detective: one task per Ruby file in lib/, fanned out through the orchestrator, each dissecting a file for long methods. The victim is this very gem. The report names names.

Observability & OpsAaron Patterson

The Pinball Queue

The Pinball Queue: a job queue explained on a pinball table, because every retry policy I have ever shipped is already in the machine. Balls are jobs. Flippers are workers (two; the table is the concurrency limit). A …

Reliability & RecoveryMike Perham

The Plan Diagrammer

The Plan Diagrammer: any orchestrator's graph, emitted as Mermaid - paste it into a README, GitHub renders it, and the diagram can never drift from the plan because it is generated FROM the plan.

Developer ExperienceXavier Noria

The Plan DSL

The Plan DSL: Sinatra's whole argument was that an API is a user interface, and a user interface should read like what it means. The orchestrator's API is honest but administrative - ids, task objects, add_task …

Developer ExperienceKonstantin Haase

Plan Flog

Plan Flog: flog gives every Ruby method a pain score; this gives every plan one. Fan-in hurts (joins hide coupling), depth hurts (chains hide latency), unlabeled edges hurt (anonymous data flow), and orphans hurt (dead …

Testing & VerificationRyan Davis (zenspider)

The Plan Forest

The Plan Forest: your graph drawn as a forest - roots at the soil, leaves in the canopy, every task planted at its depth. stats[:roots] and stats[:leaves] (new this round) do the gardening.

Plans & GraphsMatz

The Plan Fortune Teller

The Plan Fortune Teller: reads your graph's palm - depth, fan-in, roots, breadth - and tells its fortune. Every fortune is a real structural fact wearing a mystic's robe; the entertainment is a delivery mechanism for …

Plans & GraphsMatz

The Plan Gantt

The Plan Gantt: lifecycle hooks timestamp every task, then the run is rendered as an ASCII timeline - where your wall clock actually went. A diamond dependency graph with a tight concurrency limit makes the scheduler's …

Scheduling & ConcurrencyAaron Patterson

The Plan Heckler

The Plan Heckler: mutation testing for workflows. Your plan has tests. Cute. Do the tests actually FAIL when the plan is wrong, or are they decoration? The heckler finds out the honest way: it breaks the plan on purpose …

Testing & VerificationRyan Davis

The Plan Kata

The Plan Kata: red, green, refactor - for a plan. The "tests" are assertions about the graph (one root, one leaf, labeled joins, nothing too deep), written BEFORE any tasks exist. Each step adds the smallest thing that …

Testing & VerificationKatrina Owen

The Plan Lockfile

The Plan Lockfile: Gemfile.lock for workflows. A plan that says "give me text.summarize ~> 1.0" is a WISH; production runs need a FACT. `lock` resolves constraints once and writes plan.lock - exact versions plus a …

Developer ExperienceAndré Arko

The Plan Merge

The Plan Merge: base, ours, theirs - a three-way merge of plan wire formats. Independent changes combine; the same edge rewired two different ways is a CONFLICT, reported in topology vocabulary, not JSON-line …

Plans & GraphsXavier Noria

The Round Trip

The Round Trip: serialize a plan's graph to JSON, rebuild a fresh orchestrator from the JSON, and prove the rebuilt topology is isomorphic to the original - same shape, same labels, new ids. A projection you can't …

Data & PipelinesXavier Noria

PlanScript

PlanScript: a DSL where BAREWORDS build the graph. Inside the block, `fetch` isn't a variable or a method you defined - it's method_missing, catching the name and declaring a step; `rank after: fetch` catches two. …

Data & PipelinesYehuda Katz

The Plan Server

The Plan Server: a server is three disciplines wearing one process - accept concurrently, share resources safely, and above all SHUT DOWN WELL. This serves plan executions over a real socket with a thread pool, a shared …

Reliability & RecoveryEvan Phoenix

The Structural Diff

The Structural Diff: two versions of a plan's wire format, diffed as TOPOLOGY - tasks added and removed, edges rewired, labels renamed. A line diff of plan JSON tells you bytes changed; this tells you what changed about …

Plans & GraphsXavier Noria

The Plan Tour

The Plan Tour: hand any orchestrator to the guide and it narrates the plan as prose - first this, then that, meanwhile the other - read straight from graph[:order] and graph[:edges]. If the prose sounds wrong, your plan …

Plans & GraphsMatz

Plans as Automata

Plans as Automata: strip away the agents and the LLMs and a plan is a transition system - states are sets of completed tasks, and each step completes one task whose dependencies are satisfied. Which means questions …

Testing & VerificationTom Stuart

The Polite Form

The Polite Form: a contract usually speaks AFTER you fail - a 422, a stack of violations. This assistant makes it speak FIRST, turning every declaration into a question: required keys become requests, bounds become …

Developer ExperienceMatz

Ports and Adapters

Ports and Adapters: the domain is the part of your app that would survive a framework migration - IF you kept it clean. Here the use-case (quote a shipment) is pure Ruby speaking only to PORTS; the adapters live at the …

PatternsLuca Guidi

The Process Drill

The Process Drill: threads share a Mutex; PROCESSES share nothing but the file. The journal claims flock+fsync, which is a promise about processes - so this drill forks real ones, points them all at one journal, and …

Testing & Verification

Programming with Nothing

Programming with Nothing: FizzBuzz built from lambdas and nothing else - no Integer, no Boolean, no if, no % - just Church encodings, assembled layer by layer like civilization: numerals first, then arithmetic, then …

Testing & VerificationTom Stuart

The Progress Channel

The Progress Channel: broadcasting plan progress to N subscribers is easy until one subscriber is slow - then your "real-time" layer quietly becomes a memory leak or a brake on the plan itself. AnyCable years distilled …

Testing & VerificationVladimir Dementyev

The Projection Agreement Prover

The Projection Agreement Prover: relation rules now render twice - the validator enforces them in Ruby, and to_json_schema projects them into draft-07 keywords (dependencies, not-required). Two renderings of one law can …

Testing & VerificationXavier Noria

The Queue-Time Autoscaler

The Queue-Time Autoscaler: the Speedshop rule, closed-loop. Most autoscalers trigger on utilization, which is a lie with a dashboard - a healthy busy server and a drowning one can post the same number. The metric with a …

Reliability & RecoveryNate Berkopec

The Quota Keeper

The Quota Keeper: the same 20 requests through two different laws. A concurrency ceiling ("3 in flight") models connection limits; a windowed quota ("5 per 200ms") models what providers actually bill. They are different …

Scheduling & ConcurrencySamuel Williams

The Ractor Shareability Audit

The Ractor Shareability Audit: `freeze` is a promise about one object; Ractor.shareable? is a promise about everything it can reach. The graph API says "frozen snapshot" - this audit asks the stricter question: which …

Scheduling & ConcurrencyMarc-André Lafortune

The Railway Plan

The Railway Plan: dry-monads taught Ruby that failure handling is COMPOSITION, not rescue blocks - a pipeline of steps where success rides the happy track and the first failure switches every later step onto the bypass, …

Data & PipelinesPiotr Solnica

The RBS Export

The RBS Export: a capability contract already knows its types - it validates them at runtime on every call. RBS is the same knowledge written down for tools that read instead of run: steep, IDEs, docs. This generates …

Data & PipelinesSoutaro Matsumoto

The README Verifier

The README Verifier: every ruby code fence in the README is a promise. This extracts them all, syntax-checks each with Prism, and verifies that every Agentic constant a snippet mentions actually exists in the loaded …

PatternsAndrew Kane

Refactor Receipts

Refactor Receipts: the god-join plan from the graph critic, improved in two small steps - with a receipt after each one. Every step shows the smells found, the structure numbers, and the measured wall time, because "I …

Testing & VerificationSandi Metz

The Refactoring Dojo

The Refactoring Dojo: a student submits a method, three critic agents review it from three distinct perspectives, and the sensei prescribes the ONE smallest next step. Today's student: this gem itself, submitting its …

Testing & VerificationSandi Metz

The Relation Diff

The Relation Diff: round 8's semver advisor classified declaration changes but had to shrug at rules - lambdas can't be compared. Now relations are data, so the RULES diff too: a tightened limit is breaking, a loosened …

Developer ExperiencePiotr Solnica

The Relation Prober

The Relation Prober: relation-typed rules are new, and new predicates deserve hostility. Each relation is probed with edge inputs - zeros, negatives, floats, missing keys, nils - and every verdict is checked against an …

Testing & VerificationJeremy Evans

A renga circle

A renga circle: three poet agents compose a linked-verse poem, each verse responding to the one before it. The dependency graph IS the poem's form - verse 2 cannot begin until verse 1 exists, and the orchestrator pipes …

Plans & GraphsMatz

The Require Cost Report

The Require Cost Report: `require` is a purchase - memory, objects, and boot time, paid again by every process you fork and every worker you scale. This measures what the gem and each major dependency cost AT REQUIRE …

Scheduling & ConcurrencyRichard Schneeman

The Resize Torture Test

The Resize Torture Test: a feature that changes a limiter's ceiling while fibers are waiting on it had better say exactly what it guarantees - and then survive an attempt to break the guarantee. Three assaults: …

Testing & VerificationJeremy Evans

The Retry Budget

The Retry Budget: a retry storm is a self-inflicted DDoS - every job politely retrying 3x turns one outage into four. Retries are a SHARED resource, so give the fleet one wallet: transient failures spend from it, …

Reliability & RecoveryMike Perham

The Rule Prober

The Rule Prober: structured rules declare which fields they read - so now that claim can be AUDITED. For each rule, perturb fields it does NOT declare; if the verdict flips, the rule is reading fields off the books. One …

PatternsJeremy Evans

Rule Shapes

Rule Shapes: the same policy - "express shipments need a customs code" - written three ways: a lambda, a structured check, and a relation. Then four consumers try to use each shape: the validator, the message deriver, …

Data & PipelinesSandi Metz

Schedule Equivalence

Schedule Equivalence: a plan's declared meaning is its dependency graph - which implies a PROMISE nobody usually tests: outputs must not depend on the schedule. Run the same plan at concurrency 1, 2, and 8; if the …

Testing & VerificationBenoit Daloze

The Schema Advisor

The Schema Advisor: give it a schema and a query log, get back the advisories a careful DBA would write - each rule its own capability, each table analyzed as its own task.

PatternsJeremy Evans

Self-Correcting Output

Self-Correcting Output: the pattern that makes LLM components shippable. The model's output is validated against the capability's contract; violations don't raise to the user - they become the CORRECTION PROMPT for a …

Reliability & RecoveryObie Fernandez

The Setup Doctor

The Setup Doctor: every onboarding wiki page is a bug. This runs the checks a README asks a new hire to do by hand - gem loads, bundle health, git state, catalog presence - in parallel, then one diagnosis task reads …

Developer ExperienceDHH

Shadow Traffic

Shadow Traffic: the safest way to replace a component at scale is to never let the replacement answer. The OLD implementation serves every request; the NEW one runs beside it in the shadow - same inputs, measured and …

Scheduling & ConcurrencyEileen Uchitelle

Shameless Green

Shameless Green: the 99 Bottles discipline applied to a plan. Step zero is one god task that does everything - and it's GREEN, and we are not ashamed, because green output pinned as a golden master is what buys every …

Testing & VerificationSandi Metz

The Shared Rate Limit

The Shared Rate Limit: two plans run concurrently in one reactor, but the API key they share allows only 3 requests in flight. A single Async::Semaphore, passed to both, enforces the provider's ceiling across plan …

Scheduling & ConcurrencySamuel Williams

The Spend Ledger

The Spend Ledger: LLM plans spend real money, and money has rules older than software - integer cents (floats round YOUR money, never theirs), a ledger where every entry has a description, and a budget that stops the …

Observability & OpsNoel Rappin

The Stack VM Plan

The Stack VM Plan: I have spent twenty years compiling Ruby onto other people's virtual machines, so for the strange round I built the inverse: a virtual machine made OUT OF the framework. An arithmetic expression …

Scheduling & ConcurrencyCharles Nutter

The Stampede Simulator

The Stampede Simulator: twenty workers hit a hiccuping upstream, all fail at once, all retry. With jitter OFF they come back as a single synchronized herd - the second outage. With jitter ON (the default, as of this …

Reliability & RecoveryMike Perham

The Standup Digest

The Standup Digest: three collectors gather from the repo in parallel - recent commits, TODO debt, test suite shape - and a writer task fans their outputs in through the dependency pipe and publishes the digest nobody …

Testing & VerificationDHH

The Contract State Machine

The Contract State Machine: each transition is a capability whose guard is not an if-statement but an enum predicate on its declared contract (new this round). An illegal transition doesn't fail - it never types-checks …

Developer ExperiencePiotr Solnica

Status Board

Status Board: output is not always text. The wallboard your team glances at is a FILE - an SVG chart, a CSV you can pivot, a JSON summary a dashboard ingests - and a plan is the right machine to produce one: collect …

Data & Pipelines

The Stdlib Census

The Stdlib Census: "it's in the standard library" is a statement with a shelf life. Default gems become bundled gems on a published schedule, and every `require` your gem makes is either covered by ruby itself, covered …

Data & PipelinesHiroshi Shibata

The Supervision Tree

The Supervision Tree: "let it crash" for plans. The agents in this file contain NO rescue clauses - error handling is not the worker's job. Recovery is a POLICY, and policies live one level up, in a supervisor that …

Reliability & RecoveryJosé Valim

The Escalation Ladder

The Escalation Ladder: the pattern under every AI product that survives contact with customers. The machine does the whole job it can PROVE it can do, and hands the rest up a ladder - tier 0 auto-resolves from …

Scheduling & ConcurrencyObie Fernandez

The Survey Scrubber

The Survey Scrubber: you asked ten humans "what's blocking your team?" and they answered like humans - with names, emails, phone numbers, and @handles embedded in the grievances. Every downstream system that touches …

Data & PipelinesSarah Mei

The Telemetry Bus

The Telemetry Bus: lifecycle hooks are callbacks - one producer, one consumer, coupled at configuration time. A telemetry bus inverts that: the orchestrator emits NAMED EVENTS into a bus, and any number of handlers …

Observability & OpsJosé Valim

The telephone game

The telephone game: a rumor passes through five villagers, each of whom hears the previous version through the orchestrator's dependency pipe and repeats it... imperfectly. No shared state, no scroll passed around - the …

Observability & OpsMatz

Tenant Shards

Tenant Shards: at scale, "the plan" becomes "the plan, per shard" - same pipeline, isolated blast radius. Each shard gets its own journal (its own recovery story) and its own rate limit (its own noisy neighbor …

Reliability & RecoveryEileen Uchitelle

The Terminal Band

The Terminal Band: a one-computer band where every instrument is a task. Four players compose their parts IN PARALLEL (they've played together for years; the chord chart is the only coordination), a mixer task fans them …

Fun & StrangeAaron Patterson

The Terminal Demoscene

The Terminal Demoscene: a 64-column demo intro - parallax starfield, plasma, and a wrapping scroller - rendered by a plan that is, structurally, a render farm: every frame's three effects compute in PARALLEL as tasks, a …

Plans & GraphsPiotr Murach

The Threads Drill

The Threads Drill: fibers are polite; threads are not. Everything in this gem that claims to be shared-safe gets hammered by real Ruby threads - the kind that run truly parallel on JRuby, where there is no GVL to be …

Testing & VerificationCharles Nutter (headius)

Three Shapes

Three Shapes: the same six units of work arranged three ways - a chain, a star, and staged joins - then measured and critiqued. Design is choosing a shape ON PURPOSE, and purpose needs numbers.

Plans & GraphsSandi Metz

The Throughput Knee

The Throughput Knee: sweep one limiter's ceiling from 1 to 8 against an upstream that quietly serializes above 4, and measure TWO clocks - service time (inside the upstream) and total time (including the wait for a …

Scheduling & ConcurrencyAaron Patterson

The TTY Status Board

The TTY Status Board: terminal output is a UI, and UIs are built from COMPONENTS - a tree for structure, gauges for progress, badges for state - not from puts sprinkled where the mood struck. This renders a plan's live …

PatternsPiotr Murach

The Type Séance

The Type Séance: this plan has no type annotations, but it HAD a run - and a run is a set of observations, and observations formalized are types. The séance sits with the departed execution, records the shape of every …

Observability & OpsSoutaro Matsumoto

A typed ETL pipeline

A typed ETL pipeline: extract -> transform -> load, each stage a capability with a declared contract, composed into one capability via the registry. Bad data doesn't flow downstream - it's stopped at the boundary that …

Data & PipelinesPiotr Solnica

Unix Workers

Unix Workers: I like Unix because the operating system already solved process supervision and nobody told the frameworks. A master preforks N plan workers, work arrives on a pipe, SIGTERM means "finish what you hold, …

Reliability & RecoveryRyan Tomayko

The Variance Detective

The Variance Detective: ten journaled runs of the same plan, then a hunt for the task whose p90/p50 ratio betrays it. Averages hide flakiness; percentile spreads name it. Uses duration_percentile (new this round) over …

Observability & OpsAaron Patterson

The VM Eye

The VM Eye: your plan, as the virtual machine saw it. Above the waterline there are tasks and dependencies; below it there are method calls, block invocations, and allocated objects, and the VM counts ALL of them …

Observability & OpsKoichi Sasada

The Wat Museum

The Wat Museum: seven exhibits of genuine Ruby strangeness, each one a task that PROVES its own placard before you're allowed to gasp at it. Museums of programming wat usually run on hearsay - screenshots of someone …

Fun & StrangeKonstantin Haase

The Write Path Profile

The Write Path Profile: everyone's first instinct about a slow journal is "switch JSON libraries". Before holding that opinion, weigh each layer of the write separately - serialize, write, flush, fsync - because …

Observability & OpsJean Boussier (byroot)