RampStack

Context

RampStack is an open-source, MIT-licensed AI agent-orchestration framework, and I am its Creator & Maintainer. Roughly roughly 1,000^{Source note 4} people use the open-source tooling weekly.

It exists because coding agents got good enough to be worth using and stayed unreliable enough to be dangerous. The interesting problem stopped being whether an agent can write the code and became whether you can tell when it has written the wrong code. That is a release engineering problem, not a prompting problem, and it is the problem this framework is pointed at.

Owned

Creator and sole maintainer. I write the specifications, dispatch the work to agents, review every output, and hold merge authority. There is no team to delegate the review to, which is the constraint the whole design answers.

Architecture

Four layers, each of which exists to make the layer above it checkable.

Skills. 103 Claude Skills^{Source note 1} in an open-source library, with 425+ reference files^{Source note 2} across 16 categories^{Source note 3}. A skill is a written procedure an agent loads when the task matches, which is how a practice becomes portable instead of living in one person's context window.

Engines. Three Claude-based engines, where Krine decides, Tholo builds, and Basano proves, with Lanthe as Basano's citation-measurement instrument. Separating deciding from building from proving matters for the same reason it matters in a team: the agent that wrote the thing is the worst possible judge of whether it works.

Orchestration. 30+ codified patterns^{Source note 5} coordinating simultaneous agents across public and private repositories, plus 35+ MCP integration patterns^{Source note 6}, including Google Search Console and Umami analytics servers I built so a pipeline can read its own metrics and plan against them.

Governance. Manifest-driven release governance in GitHub Actions: drift checks across artifacts, byte-identical fence tests, and brand-leak lint, all running before a release can go out.

The loop is the part I would defend hardest. An agent drafts against a written brief, the work lands as a held pull request, verification runs independently of the agent that produced the work, and a human merges or nothing merges. Human-only merge authority is not ceremony. It is the single place where an automated pipeline can be stopped by someone who understands what the change was supposed to do, and removing it converts every downstream check into a formality.

That loop has caught instrument-invalidating defects before they shipped, which is the class of failure that matters most here: a broken measurement instrument does not announce itself, it just quietly reports numbers that are wrong.

Decisions

• Verification independent of the agent that did the work. An agent asked to check its own output will find it satisfactory. The check has to come from somewhere else or it is not a check.
• Human-only merge authority. Slower on purpose. It is the stop that the incident evidence says has to exist.
• A written specification before dispatch. The failure mode of agent work is a plausible answer to the wrong question, and a specification is what makes that visible on review.
• Measurement instruments over dashboards. Wilson confidence intervals and write-once baselines because a number that can be revised after the fact is not evidence.
• Skills as files, not prompts. A procedure in a repository can be diffed, reviewed, and versioned. A procedure in a prompt cannot.

Outcome

The release process has run 5 green, 4 correct stops^{Source note 8}. The stops are the number I would point at first: a governance system that has never stopped anything has not been tested, and four correct stops mean the gates fire on real conditions rather than sitting decorative.

10 of 15 agent-drafted^{Source note 7} of the open-source workflows were drafted by agents and held to the same quality bar, with provenance recorded for each.

On the measurement side, an AI-search event registry of 26 primary-sourced events^{Source note 10}, with a tiered attribution ladder and schema validation in CI, and a first-party SERP volatility instrument built on a 1,000-keyword frozen cohort^{Source note 11} with displacement scoring weighted toward the positions that matter.

The CI/CD verification specification came out of an 11 incidents^{Source note 9} evidence base of real production incidents, which is why it prioritises post-deploy live verification and a crawler-vantage noindex tripwire rather than the checks that are easiest to automate.

CodeBlu is a demonstration product built with the framework, and it is the evidence that the tooling reaches past websites into software.

How I write code

Spec to code, with agents. I write the specification, dispatch the work, then read, review, and debug what comes back. I own the integration and the quality gates.

Reviewing an agent's output is not an overhead on the work. It is the work, and it requires being able to read the code well enough to find the defect that the tests did not. The three engines and the dispatch loop exist because I needed that review to be repeatable rather than heroic.

Revision

I would have built the release governance before the skills library rather than after. The skills came first because they were useful immediately, and the governance came after the first release that should have been stopped and was not. That order cost me the incident that taught me the lesson, and the evidence base is smaller than it would have been if I had instrumented earlier.