The client who never existed
GALAPA* is a digital agency. Like many agencies, we keep a bilingual blog: it's how a prospective client finds us, and increasingly it's also how an AI assistant decides to cite us when someone asks it a question about our field. Since the spring of 2026, the articles on that blog have been produced by three programs working in sequence, with two points where a person decides.
That's not how it started.
On June 2, 2026, while reviewing an article our automated writer had just finished, we found a complete case study. A B2B logistics client, a visibility score that had climbed from 38% to 68% between March and April, a precise figure for how many queries ChatGPT answered by recommending the company. Three convincing paragraphs, written in the right tone, ready to publish.
That client never existed. None of those measurements had been taken. The second article reviewed that day had the same defect, which ruled out an accident. Our engineering log carries the note, dated the same day: structural.
What follows is what we built from there: why the chain now runs on three separate programs instead of one, what broke along the way, and what it changes in a week of actual work.
The hard part was never the writing
Writing a 1,500 to 2,000 word article takes a few days of full-time work. That's slow, but it's the visible part of the problem and the cheaper one.
The part that wears you down is keeping up. Staying current in a field that shifts every week, opening dozens of links, telling signal from noise, gathering sources, deciding which subject deserves an article now rather than in three months. For a small business whose trade isn't publishing, that load is unmanageable. It never appears on a schedule, and it's always the first thing to go.
An agent that writes quickly doesn't solve that. It moves the bottleneck one step down the line, and often makes it worse: the more you produce, the more you have to verify.
Three agents, three jobs
The chain runs on three separate programs. Each has its own codebase, its own release cycle, and its own rhythm.
Why three programs instead of one
The split wasn't designed up front. The writer came first, on May 26, 2026. The curator arrived the next day to feed it. The reviewer existed as a documented problem for nearly three months before it existed as a program.
Four reasons ended up justifying it.
The database acts as the belt. The agents never call each other. They read one status and write another: the curator drops a brief at "To validate", the writer only picks up "Planned", the reviewer hands back "Written". If a service goes down, nothing is lost, because the state never lives inside the service.
We needed a seam to put a person into. A single program offers nowhere to insert a human decision. The split creates that place: not a word gets written before someone has approved the angle. A rejected subject moves to "Rejected", a status the curator reads on every pass so it never proposes that subject again.
The writer can't proofread itself. That one we learned on June 2. The writer produces its text before its sources are validated. No instruction, however well phrased, can make it remove a paragraph that rests on a source which later fell through, because the paragraph already exists. The correction has to come after generation, which means from somewhere else.
Manual review stopped keeping up. This is the reason that actually triggered building the third agent, in August. Review already existed as a documented procedure, but it was carried out by hand. It took time, the backlog grew, and a pile of written-but-unpublished articles formed. Writing had been automated; the next step had become the blockage.
What we ruled out
The curator's first model worked one for one: every article written triggered the creation of exactly one brief, keeping the subject queue at a constant size. The idea was elegant and lasted less than a week. On June 2 it was replaced by a weekly pass that selects three to five subjects from about a dozen candidates. A queue that refills on a fixed schedule beats a queue that depends on output.
We also ruled out strict automated validation, the kind that would block publication whenever a figure can't be matched word for word in a source. Formats differ, models paraphrase, extracts are short: the false-positive rate would have made the whole thing unusable. The rule we kept flags and corrects, without ever blocking on a literal comparison.
Review as a measuring instrument
Here's the mechanism that separates this chain from three programs bolted together.
Every review session writes its findings into a field in the database, article by article. When an error shows up again in a later article, it changes nature: it stops being a defect to fix by hand and becomes a patch to apply in the writer. Review produces publishable articles and, at the same time, the list of what needs repairing upstream.
The counter is explicit in the notes themselves. This one is from June 12, on an article about Google's AI guidance:
Flattening of the AEO/GEO distinction (glossary violation, June 4). 2nd occurrence of the pattern (already seen on GPT-5.5).
Revision note, June 12, 2026
The same note then decides between the two possible moves, in its own vocabulary:
One-shot: 6 rewordings, em dash pass. Structural (agent patch): AEO/GEO flattening → prompt generated for the Writing Agent.
Same note, Modifications section
A one-off error gets fixed in the article. A second occurrence triggers a patch in the program.
The clearest example is dated June 15, and all three moments fall on the same day. That morning, a review session on an article about referral agreements between agencies flagged six fabricated source attributions, three in French and three in English, plus a false premise about a commission model GALAPA* doesn't use. The same day, a patch went into the writer: only sources from the brief can be cited, and the filter is applied by the code rather than by an instruction. Verification ran on that same article: six fabricated attributions before, zero after.
Every June patch came from this. None was dreamed up at a whiteboard. Each was observed in a specific article, on a specific date.
Where a person keeps control
Two stopping points, and they don't move.
The first sits before writing. Briefs arrive at "To validate" and stay there. Reading the title and summary, then planning or rejecting, takes five minutes a week for the whole set of proposed subjects.
The second sits before publication. The reviewer drops a draft in the CMS and stops. It also refuses to demote an article that has already been published, a guard rail added after the fact. Reading both language versions, adjusting and publishing takes 30 to 45 minutes, three times a week.
The reviewer can also refuse an article instead of correcting it. That happened to a piece claiming measured results from agency clients when the brief had asked for nothing of the sort:
Automated review — RED verdict. Destination: back to writing.
Revision note, blog database
A program that can say no is worth more than a program that always produces something.
What changed
Human time for a full week of production, approval included, runs to roughly two hours for three bilingual articles. The monitoring load went from constant to zero.
A secondary number says something about the quality of the curation. Of 125 briefs produced between May 26 and August 26, 13 were rejected on reading, a refusal rate of 10%. That rate falls month over month: 15% in June, 5% in July, none in August among the briefs already ruled on. Two readings remain possible, and it would be dishonest to pick the flattering one: either the curator has calibrated itself, or the sorting has become less strict than it was at the start. Answering that will take a few more months.
What doesn't work yet
The backlog is still there. As of August 26, 2026, 38 articles were written and 7 published. Catching up has started, eight articles have gone through the automated reviewer, three have reached draft stage. There's road left.
The reviewer spent two days out of the circuit. An article about e-commerce platforms surfaced 99 unsourced claims, which came to ten verification batches: forty-five minutes of processing without finishing, and a service we had to restart to interrupt it. Verification was parallelized the same day, but the real fix was elsewhere. We made the writer search for and source its own figures, which dropped the load from ten batches to roughly one on a comparable article.
The reviewer was unplugged while that upstream fix went in, and has since been plugged back. The writer's health check confirms it: connected, all indicators green. Two environment variables to remove it, two to bring it back, without touching the writer's code. A single program would have turned the same decision into a rewrite.
One consequence is worth watching. The reviewer now sees far fewer orphaned claims, because the writer sources its own figures. The learning mechanism described above feeds on exactly those defects: the fewer it finds, the less signal it sends back upstream. A chain that improves ends up starving the thing that made it improve, and we'll need to find what to measure next.
What about your business?
What our clients buy is the published article: sourced, in both languages, on the date agreed. Everything above explains why it arrives in that condition.
The guarantee comes down to two things. No text goes into writing before a person has approved the angle, and no text is published before a person has read it. Between those two points, every figure has to show where it came from, or it gets rewritten. A modest guarantee, and it came from a client who never existed.
If your blog stopped for lack of time rather than lack of ideas, or if keeping up with your industry got away from you months ago, there's a conversation worth having. We'll look at your market, your subjects and the pace you can actually hold, and tell you plainly what a setup like this would do for you. Including when the answer is that it wouldn't do much.