In one paragraph
Growth hacking is a job description before it is anything else: run many cheap experiments against a channel, keep what measurably works, throw away what doesn’t, and do it again next week. This is that job description handed to software. When someone asks an AI assistant how to do something on their computer, the assistant names a product — for a consumer software publisher that sentence is now a distribution channel, and on a lot of the queries that matter most, the assistant was naming a competitor. So: one agent watches the answer engines and finds the gaps, a second drafts a page change an editor can paste in five minutes, a third watches the result for four weeks and hands what it learnt back to the second. The fourth piece is the one that makes the other three a colleague rather than a cron job — an operating surface where the whole queue is sorted by what it is worth, every claim is labelled with where it came from, and a human spends fifteen minutes each morning deciding. Twenty-three days from the first commit to a loop running in production, 107 capabilities shipped one at a time, and the whole thing is deliberately more arithmetic than artificial intelligence: exactly four code paths ever call a model.
The problem in business terms
Answer engines have quietly become a bottom-of-funnel channel, and the audience that arrives through them converts several times better than ordinary search traffic — but nobody on a content team can see the channel. There is no console that says “you were not mentioned on this question today, and here is who was.” So the work that would close the gap is invisible work: someone would have to notice the absence, work out what structural quality of a competitor’s page earns the citation, write the fix, ship it, and then remember to check four weeks later whether it moved. That is five disciplines and a calendar reminder, per page, forever — which is why it does not happen.
- Nobody knows which commercial questions the answer engines answer without you.
- A competitor's page is read by hand to guess what earns the citation.
- The fix is written from scratch, from whatever the writer remembers about the product.
- It ships, and no one revisits it — the result is a feeling, not a number.
- What worked last quarter is folklore, held by whoever was in the room.
- Every morning the team opens a deck sorted by what the gap is worth, top first.
- Each card carries the raw answer-engine response as proof, one click away.
- A paste-ready fragment arrives with the ticket — where to paste it, and what.
- The same query is re-checked on a 28-day watch; the card shows before → after.
- Measured wins and losses are read back into the next draft automatically.
What makes this different from “point an agent at the website”
The central decision was to make the machine mostly not-AI. There is no autonomous tool-calling loop, no planner, no agent that fetches or decides for itself. Exactly four code paths ever reach a model — find the gap, watch a competitor, draft the fragment, review the draft — and every single thing a reader would assume is “the agent deciding” is arithmetic, regular expressions, and SQL: the scoring, the ranking, the value estimate, the deck balancing, the learning weights. The model writes prose. Deterministic code decides everything that gets scored, ranked, or shipped. That split is what makes the system auditable by a non-engineer, and it is why a bad model day degrades the quality of a suggestion rather than the integrity of the board.
The second decision is that the machine is not allowed to touch the site. The content-management client is GET-only and refuses every write verb at the transport layer, so the read-only property is a code invariant rather than a promise in a document — belt and braces, the publishing account holds a no-edit role too. Everything the loop produces is a proposal that lands in a human’s queue. The third decision is the one that surprises people: every prompt in the system is transcribed verbatim into an architecture decision record, and a test byte-compares the recorded prompts against the running ones. Edit a prompt without updating its ADR and the build fails. It sounds like bureaucracy until you notice what it buys — the document describing how the agents think can never quietly become fiction, which is the failure mode every AI system in production eventually has.
| criterion | Autonomous tool-calling agent | Narrow LLM surface, deterministic orchestration, human gate chosen | Pure heuristics, no model at all |
|---|---|---|---|
| Can explain why a card ranks where it does | no | yes | yes |
| Writes publishable prose | yes | yes | no |
| Blast radius of a bad model day | the site | one suggestion | none |
| Auditable by a non-engineer | no | yes | partial |
| Cost per turn, predictable | no | yes | yes |
| Improves as the models improve | yes | yes | no |
Three agents, one session
A machine that proposes, and a room that decides
The loop is one turn repeated: find where an answer engine cites someone else, work out what structural quality earns that citation, draft the change, let a human ship it, then measure for four weeks whether the mention came back. Three agents own one phase each, and the phases hand each other data rather than instructions.
Two files travel with every session. One is the working agreement — what ships, what never ships, and where the hard invariants are. The other is the architecture record, which transcribes every prompt in the system verbatim; it is context because it is also enforced, byte for byte, by a test.
What follows is three real working sessions, one per agent, in the order a card moves through them. Each one is a capability being built rather than a bug being chased — the moment that phase of the growth hacker got its judgement.
The trust property underneath all of it: the content-management client is GET-only and refuses write verbs at the transport layer. The machine can read the site all day and cannot change a character of it.
SENSE learns what it is looking at
An idea-generating agent that hands every idea to the same downstream worker is not really thinking. Some of what it finds is a small additive block a machine can draft cleanly; some of it is a three-year-old article that needs a person and an afternoon. Routing the second kind into a drafting queue burns model budget and, worse, burns reviewer patience on output that was never going to be usable.
The interesting part is where the judgement comes from. The obvious signal is the verb in the recommendation, and it is nearly right — until you find two cards that ask for the same thing on pages three years apart. Going to the pages and reading their actual age turns a plausible rule into a correct one, and the threshold gets placed in the empty gap in the data rather than tuned until the answer looks good.
The other move here is a refusal. The obvious next step is to have the machine learn from how often humans overrule it — but there is nothing to learn from yet, so the change records both opinions in separate columns and stops. Disagreement has to be countable before it can be useful, and building the learning before the data is how systems end up confidently wrong.
For the business it means the drafting agent’s time goes to work it can finish, and the work that genuinely needs a writer arrives labelled as such instead of arriving as a disappointing draft.
STEAL produces something an editor can act on
The gap between a good analysis and a usable deliverable is where most content automation quietly fails. The first live draft this system produced was technically impressive and practically useless: ten bullets under a heading that means “too long, didn’t read”, a structured-data script nobody asked for, and an internal diagnostic comment that would have shipped to the public page.
Every one of those defects traces to a specific line of a specific prompt, which is the argument for transcribing prompts into the architecture record — a complaint from a non-engineer becomes a code review. The fix is not a better model; it is a tighter output contract. The model must now say where the fragment goes before it says what the fragment is, and an automated check measures whether it complied, three times per release.
The deeper change is conceptual. The patch stops being an artefact that needs interpreting and becomes the instruction itself. An editor opens one file, reads where to paste and what to paste, and is done. The analysis that justified the change moves to the ticket, where the people who care about justification actually work.
The business meaning is a throughput one: a page change goes from a research memo somebody has to translate into work, to five minutes of copy-paste by whoever has the CMS open. That is the difference between a system that suggests things and a system that gets things shipped.
LEARN closes the loop back onto the draft
Most systems that claim to learn are collecting data at one end and never reading it at the other. This one had exactly that shape: every shipped change was measured for four weeks, the verdict was stored, and the drafting agent was writing its hundredth fragment with no idea how the previous ninety-nine had done.
Closing that gap needed no new database column. A coarse change-type is derived from the wording of the recommendation, precedents are matched on the same change-type or the same page, and the winners are injected into the drafting prompt with their real click deltas attached — mirror what won, do not repeat what lost. Where an old card has no stored implementation, the agent reads the live published page to recover what actually shipped, which works precisely because the winning change is still there to read.
The ranking rule is where the human judgement sits, and it is deliberately not the mathematically optimal one. Recency beats magnitude, so the newest tactic leads even when an older variant scored higher. The machine counts clicks; the room owns reader perception — and the room chose to keep a human introduction alongside the summary block even though the bare summary scored better on clicks.
The moment this landed, the architecture record contained a false sentence about the system it describes, and a test said so. That is the whole discipline in one beat: the documentation cannot drift into fiction, because drifting fails the build.
Recency beats magnitude even when magnitude is bigger, and that is a human call rather than a maths one. The machine counts clicks; we own reader perception. That is why the shipped play keeps a written introduction alongside the summary block, and not the bare summary that scored better.
What is built, and what the machine could become
Three agents and the surface they work at. The status labels are honest: live
means it runs in production today, in-progress means it exists and is being
shaped, planned means it is designed and not built.
- ● 01citation monitoringtracked commercial queries, checked against the answer engines
- ● 02gap detectiona competitor is cited, we are not → a card is born
- ● 03gap investigationour page vs theirs → the structural difference, as prose
- ● 04content auditdeterministic decay + click-gap scan of our own pages
- ● 05disposition routingpatch or handoff — decided before anything downstream runs
- ◐ 06competitor watchbuilt, manual CLI only — not yet on the nightly schedule
- ○ 07brand-fit gateblock queries the platform vendor itself answers
- ○ 08trend hijackingRSS + forum signal → clustered into a weekly brief
- ● 01gap analysiswhat structural quality earns the citation here
- ● 02freshness groundingweb search for current facts — the model may not guess a version
- ● 03precedent retrievalour own measured wins and losses on this kind of change
- ● 04fragment generationplacement + a paste-ready additive block, one artefact
- ● 05adversarial reviewa second model tries to reject the draft; up to two reworks
- ● 06ticket deliverypatch attached to the task, two-key switch before it goes live
- – 07full-page rewritesdeliberately out of scope — handoff cards go to a writer
- ● 01outcome watch28 days after Done, re-check the query and record before → after
- ● 02golden-set closurepre-launch experiments judged on real clicks, never on citation
- ● 03lesson accrualrejects and outcomes become weighted lessons, origin-tagged
- ● 04deck reranka bounded factor, 0.4–1.15, shown on the card with its reason
- ● 05outcome-calibrated valuethe capture band learns from our own results past 5 outcomes
- ● 06precedent feedbackmeasured outcomes injected into the next draft
- ○ 07attribution to revenuedesigned, deliberately out of scope until citation is proven
The fourth piece: where the three of them report
Three agents on their own are three scheduled jobs writing rows to a database. What makes them read as a growth hacker — something a team works with rather than something that emails them — is the surface in front of them, and it took about as much of the build as the agents did. The queue is a board a human drags cards across, sorted by what each opportunity is worth rather than by when it arrived. Every card is addressable by a short key, so an opportunity can be pasted into a chat message and opened by anyone. Alongside it runs a journal of short, voice-coded entries — what the agents did overnight, what moved, what got auto-archived and why — which is the difference between a system you trust and a system you audit.
The two decisions worth stealing are both about honesty. The first is that every number on a card is labelled with its own provenance: an estimate derived from a fixed prior says so in as many words, and only starts calling itself learned when it has actually learned. A card drafted without the page body being readable is badged as a blind draft. Nothing on the surface is allowed to claim a measurement that was not taken — which sounds obvious until you find half a board doing it. The second is the operator’s brake: a kill switch that survives a restart and stops every agent entry point, and a ticket integration that needs two independent keys — one in the environment, one in the running app — before it can write anything to anybody’s project tracker.
- ● 01opportunity boardfive columns, drag to triage; the machine cannot move a card into Done
- ● 02event journalvoice-coded entries — system, agent, human — with bulk actions grouped
- ● 03card detail + short keythe full decision narrative, addressable as a link you can paste in chat
- ● 04honest provenanceevery claim badged: real model, stub fallback, blind draft, prior vs learned
- ● 05autonomy panelkill switch that survives a restart; two keys before a ticket is ever real
- ● 06analytics + ship markersnorth-star charts with a marker on every day the team shipped a change
- ● 07copy contractcharacter budgets defined once in code, enforced by test on every surface
- ○ 08health admintoken spend, server load, backups — designed, lowest priority
How it was built: one capability at a time
The delivery discipline is as load-bearing as the architecture, and it is the reason 107 capabilities landed in three weeks without the codebase turning into a swamp. Every one of them followed the same six steps.
- One capability, one change folder. A written proposal, a spec, a design note and a task list land before any code — and the change ID, the branch name, and the commit message are the same string.
- Build in a fixed order: interface first, then API, then domain logic, then the database, then tests, then docs. Starting at the surface keeps the thing being built answerable to what a human actually sees.
- Every commit carries real behaviour proof. A command and its output, an HTTP trace, a screen recording. A script enforces it at commit time — a commit message without a proof section is rejected.
- One command is the definition of done. Format, lint, typecheck across every package, tests, build, and a strict spec validation, chained so the first failure stops the gate. The same command runs in CI and on push.
- Architecture decisions get a record, and the record is enforced. Eight so far. Every prompt in the system is transcribed verbatim into one, and a test byte-compares them against the running code.
- Any prompt change re-runs the live eval scorecard against the real models — three repeats per case, hard checks that fail the release and soft checks that only warn.
Historically that check passed three times in six. It has now passed three in three, which is six of nine — call it two thirds. One clean run on a stochastic model is not “fixed”, it is “lucky this time”. What actually changed is that a miss now fails the gate instead of passing quietly.
What one closed gap is worth
The card headline that drives triage is an estimate, and it is worth understanding because it is the number the room argues about each morning. It is not a model output — it is arithmetic over search-console data: how many impressions a page gets, how far its click-through rate sits below what its position should earn, and what fraction of that gap a change realistically captures. That last fraction started as a conservative fixed prior and now learns from the publisher’s own measured outcomes once there are at least five of them.
The value math behind a card
Plug in a page of your own. The capture band is the honest part — it says what share of the theoretical gap a real change tends to bring back, and it is deliberately a range rather than a number.
runs locally · 0 network calls · deterministic
The default values are a real page from the live board, and they carry a second story: a click-through rate of 0.1% at position 8.4 on thirty thousand monthly impressions is anomalously low for that position. Something is eating the clicks before the page ever gets them — which is the hypothesis the whole system exists to test, showing up as a number rather than an argument.
The verdict from the room
The loop is young enough that the honest claim is about the machinery rather than the results: the citation outcomes it will report are still inside their first measurement windows, and the system says so on every card that has not concluded rather than implying a win. What is already real is that a content team can see a channel that was invisible three weeks ago, sorted by what it is worth, with the raw evidence one click away — and that the changes they ship now come back as measurements instead of as opinions. The interesting thing to watch is the second-order effect: once the drafting agent is reading a hundred measured outcomes instead of fourteen, the quality of a draft stops depending on which model is fashionable.
It makes a distribution channel we could not previously see into a queue someone can work through in fifteen minutes a morning — and it does it without ever letting a machine near the live site, which is the version of this I can actually approve.
Keeping the model surface down to four call sites and making everything scored or ranked deterministic is the decision that ages well; so is failing the build when a prompt drifts from its record. The corner I would watch is the change-type matcher — it is keyword-based, and a mis-derived type quietly yields worse precedents rather than an error anyone sees.
It is boring to operate, which is the compliment: the schedule is off by default, there is a kill switch that survives a restart, and the ticket integration needs two independent keys turned before it can write anything real.
Twenty-three days. One builder. Three agents, one surface to work them from, 107 capabilities and eight architecture records — a growth hacker that never asks permission to look, and never gets to skip asking permission to act.
This case describes architecture and patterns. The publisher, its products, the hostnames, and the specific commercial queries are deliberately left abstract; what matters here is the shape of the loop and where the human sits inside it, not whose catalogue it runs against.