From internal tool to public starter kit: our agent harness on GitHub

In an earlier post in this category we shared, in general terms, how we were applying to this very site the same content architecture and editorial workflow principles we propose to our clients. Since then we took it a step further: the set of AI agents that coordinates that work — what we internally call "the harness" — now also exists as a public starter kit, published on GitHub as agent-harness-drupal, with everything specific to this project (client name, domain, tracking board, memory entries) stripped out or reduced to empty templates to fill in.

What exactly is it? A multi-agent architecture for Claude Code: an orchestrator that talks to the person and decides what to do, a planner that turns a goal into tasks, a documenter that records what worked and what didn't in a short- and long-term memory, twelve specialized execution agents (content, style, SEO, Drupal development, frontend, testing, pull request review, among others), two flows that chain them in the right order — one for content, one for development and testing — and reusable Drupal domain skills. We labeled it "alpha" on purpose: the mechanism is battle-tested on one real use case, this very site (trilingual ES/EN/PT, on Drupal 11, with a full editorial workflow), but not yet on a second, different project.

In practice, two rules hold the whole system together and aren't negotiable. No agent publishes content directly: any draft stays in a review state until a person approves it explicitly. And no agent merges code into the main branch: the development flow always ends with a branch with verified tests, a pull request opened and reviewed, and the final merge in human hands. These are the same two gates we were already applying on this site before we even thought about publishing the harness as something reusable.

The fact that the mechanism is "battle-tested" doesn't mean it went right the first time. Two real examples, no gloss. During a session focused on delegating more work to another AI tool (Kimi Code CLI) to save our own context, we realized we'd been writing out, by hand, in every request, operational rules — the right branch, running linters before delivering — that already existed preloaded in each agent's configuration. The problem wasn't that the delegated tool worked badly; it was that we weren't using what we'd already built. Fixing that was the highest-impact change of the whole session, and we recorded a baseline with real numbers (how many invocations, how much friction) so we can compare properly next time, instead of assuming it improved.

The second example is different: trying to publish a text change across the site's three languages, one language's draft would silently get lost every time we saved another language that had its own pending draft. We reproduced it twice, with two different methods, before we even suspected it wasn't our own mistake. It turned out to be an active, unresolved bug in Drupal 11 itself, with other reports describing the same pattern. There was a faster shortcut available — forcing it with a script touching the database directly — but that was exactly the kind of intervention that had already cost us an incident before, so we left it documented and pending a decision instead of forcing it.

What can you do with the starter kit today? Use it as a starting point for another Drupal project with similar needs — editorial workflow, multiple languages, a small team that needs to move fast without losing quality control — and adapt the parts the repo marks as examples from the original project (the nested-Paragraphs content model, the Twig templates, certain theme conventions) to each site's real structure. It's still an alpha: thoroughly tested on one case, not yet on several. If someone tries it on their own project, that's real information we'd like to know about.