Work · Capstone · Reusable Multi-Agent Systems

I build the agent teams behind this work, and the loop that improves them

Agent teams governed by a single rubric, bounded loops with hard fact-check gates, and a meta-optimizer architected to resist reward hacking. One skeleton, pointed at six marketing functions.

1 skeletonsix marketing functions
8 personas · 1 rubricsingle source for every score
9 · 1 · 0ADOPT · REVISE · REJECT, one real run
The pattern

One pattern, six marketing functions

Agent team + loop + rubric + a human on the gate, pointed at one marketing function until it runs itself.

The US site build used it as a build pipeline. The CMS rebuild was filled by this content team. The reporting model is folding its Layer 4 onto this engine. The same skeleton runs Google Ads ops, SDR outreach, and marketing email.

This page is the machinery; the work it produced is credited on those project pages.

Where the pattern came from

I am rebuilding a team I used to run

At PingPong the website was a human operation. Webflow, and around it a product marketing manager, a product manager, a content manager, a designer and a content writer, all working the same page. Then the review: the marketing team ran several sprints where every person reviewed at least their own page, wrote up their feedback, and we discussed what to implement before anything changed. It was systematic and it worked. It was also slow, and it consumed most of a team.

At ThinkingAI I own website operations, inbound campaigns and the tech stack at the same time, so that shape was never going to fit. What I did instead was take the collaboration apart: every seat in that old room became an agent with its own context, its own skills, and its own to-do list, and the sprint review became a review loop. The systems below are that decomposition, and a new page now comes out of it in a few hours.

The agent roster is a copy of a real org chart: product marketing, writer, designer, UI/UX, assembly, reviewers, plus a loop that improves them
Same seats, different substratePingPong team → ThinkingAI agent teamthe decomposition
Product marketingagent · capability knowledge base
Content writeragent · brand voice + writing skills
Designeragent sub-team
UI/UXagent · module catalog
Sprint reviewthree-model review panel
Weeks of team timehours per page
The systems

Four systems: a page factory, a review loop, a meta-optimizer, a content team

All four exist in a real repository with archived runs. One team builds web pages from a module catalog. One reviews and refines page copy. One generates publish-ready content, images included. And one system's whole job is making the other teams better.

System A · The page factory

A catalog of 30+ modules, and agents that pick from it

The first phase of the site work was inventory. I built more than 30 reusable module templates, and each one declares its own constraints: which scenarios it suits, where it belongs on a page, roughly how much text each section holds, and the image dimensions it expects. That turns layout into a catalog an agent can choose from instead of a blank canvas it has to invent against.

A page run then works the way the old team did. The product marketing agent carries the product-capability knowledge base as its context. The writer agent carries brand tone of voice and the writing skills, held as system prompts. A UI/UX agent decides which module each block of content actually needs and picks the scheme from the catalog. The designer is its own sub-team: a visual instruction goes out, an image tool generates the asset, Claude Code inspects what came back, and an agent composites the HTML overlay when the module calls for one. An assembly agent puts the page together at the end.

Every module template predeclares scenario, placement, text budget per section and image dimensions, so selection is a constrained choice rather than a generation problem
One page runcatalog in, assembled page outhours per page
Module catalog30+ templates, constrained
Product marketingcapability knowledge base
Writerbrand voice + writing skills
UI/UXpicks the module per block
Designer sub-teamgenerate → inspect → overlay
Assemblybuilds the page
System B · The review loop

Draft in, launch-ready out

An 8-stage pipeline takes raw page copy to publishable. A context distiller builds a cacheable brief, two prospect personas and a CEO persona score the draft in parallel, a synthesis stage resolves their conflicts into one change brief, and an architect revises. Then the hard part: a fact-check gate where any claim without a source is a must-fix, a de-AI pass, and a re-score by the same three reviewers against baseline. A human holds the publish gate.

The three reviewers run on three different vendors' frontier models, each briefed as a first-time visitor from our ICP with no prior context, asked the same blunt question: how fast can you tell what this is. They score, they read each other's findings, and they argue. Model diversity is the point. One vendor's blind spot stays one vendor's blind spot instead of becoming the review's.

8 personas defined in markdown · one scoring rubric as the single source of truth · every run archived in full
Main loop8 stages, boundedarchived runs
3-persona parallel reviewbaseline
Fact-check gateno source = must-fix
De-AI passstrip AI voice
Re-score vs baselinedelta
System C · The meta-optimizer

The loop that proposes fixes to the team's own rules

This loop's job is making the team better. It attributes every score deduction to a single root cause and splits them honestly: instruction, context, and rubric defects are fixable; missing inputs, human decisions, and inherent tradeoffs are left alone. Concrete diffs are proposed only for the fixable kind, then an adversarial guardrail interrogates each one: real defect or score-gaming, does it generalize, what are the side effects. Survivors become a proposal for human review. Nothing auto-applies.

A quieter kind of improvement runs alongside it. Each page run has checkpoints where an agent can write back what it learned, so the skills and knowledge an individual agent needed on this page persist into its long-term memory for the next one. The meta-optimizer changes the team's rules through a human gate. This just means each agent starts the next page knowing more than it did on the last.

Founding principle: the score is a diagnostic signal, and optimizing against it is forbidden. Judges stay frozen and may only get stricter; adopted changes are re-validated on a different page
Meta-optimizerimproves the teamhuman-gated
Diagnoseone root cause per deduction
Proposefixable defects only
Guardraildefect or score-gaming?
Assembleproposal for human review
The worked example

The one diff the guardrail sent back

In the 2026-07-06 run, all three reviewers flagged the same phrase: “rented LLM,” jargon sitting on the site's strongest differentiator. The obvious fix, diff D8, would let the final Content Master pass rewrite awkward terms into plain English. The guardrail caught what a naive optimizer would ship: the Content Master runs at stage 50, and the fact-check gate runs at stage 40, on the earlier draft, so a blanket rewrite permission would let fact-constrained claims land in final copy with no fact-check behind them. Verdict: REVISE. Ordinary jargon may be rewritten freely; any term touching an honesty red line may only be proposed by the Content Master.

Across all 10 diffs that round: every proposal cited a real failure, none loosened a gate · 9 ADOPT · 1 REVISE · 0 REJECT
Diff D8“rented LLM” → plain EnglishREVISE
Flagged by all 3 reviewersreal
Fix rewrites at stage 50proposed
Fact-check sits at stage 40gap
Red-line termspropose only
System D · The content team

Raw material to published asset, images included

Five agents take source material to a live CMS entry. Product Marketing writes the guideline, outline, and image spec; the Writer drafts under hard de-AI rules; a Reviewer scores each piece through a dual-lens gate and leaves a record. Then the Designer generates the 16:9 cover via Volcano Ark Seedream 4.0, and Assembly builds the Sanity document and publishes it through the HTTP mutation API.

The same skeleton already runs product updates, blog covers, and a case-study specialization. That breadth is the reusability claim made concrete
Content teamsource → CMS, end to end5 agents
PMguideline + outline + image spec
Writer → Reviewerscored gate
DesignerSeedream 4.0 · 16:9
Assemblypublishes to Sanity
The rules that keep it honest

Frozen judges, bounded loops, a human on publish

01 Nothing hill-climbs the score

Hill-climbing the judges' score converges on copy that flatters the judges. Goodhart's law, in production. The score reads like an instrument panel: it tells me where to look, and it is never the thing being maximized.

02 Judges frozen, only stricter

The review personas never get easier to please. Any change to a judge must tighten it. Improvements only touch the generating side, which keeps the delta between runs meaningful.

03 Every diff cites a real failure

No proposed improvement gets in on plausibility. Each diff must point at a documented failure in the run artifacts. In the archived round, all ten did.

04 Personas as markdown, rubric as single source

What agents say lives in markdown; how the loop runs lives in one workflow script; every score traces to one rubric file. Anyone can retune the whole system without touching code. That contract is what makes it portable.

05 Bounded loops, hard gates

Revision loops have a fixed budget, so there is no infinite churn. The fact-check gate is a hard stop: a claim without a source is a must-fix, with one bounded patch. Outputs are schema-validated.

06 A human holds the publish gate

The machine does the legwork end to end, then stops. Publishing a page and adopting a system change both require a person to say yes. Nothing in this architecture auto-applies.

Status

Where this actually stands

Everything operational exists as archived runs and human-gated proposals in a real repository. The one thing this page does not have yet is an external track record.

No external numbers yet

The quality and speed lift is internal so far; there are no hard external outcome metrics yet, and I mark them to-be-measured rather than imply them. The content these systems produced is credited to the CMS Rebuild, with no double counting. This page claims the machinery, and only the machinery.

Reusability

Personas as markdown, rubric as single source of truth, orchestration as a separate script. The system retunes to a new page, content type, or client by editing markdown, with no rebuild.

The systems · honest status
Page factory: 30+ module catalogOPERATIONAL
Review loop: archived homepage runOPERATIONAL
Meta-optimizer: guardrail verdictsOPERATIONAL
Content team: 3+ content typesPROVEN INTERNALLY
External track recordTO BE EARNED
Claude Code Seedream 4.0 Sanity API
Daniel is a fantastic member of the team with his ability to blend very deep technical knowledge with great interpersonal skills. He is able to quickly understand business requirements and then present a solution in a motivational way in terms appropriate for any level of the audience.
Emma Yu Emma YuSenior Product Manager
TikTok
More work

Want this machinery pointed at your function?

It retunes to a new page, content type, or client by editing markdown.