We Set Out to Build an Autonomous Loop. It Already Existed.

AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.

We set out to build an autonomous write-review-publish loop. We found it already running.

We sat down to build the loop we had been sketching for months and discovered sixteen finished articles already published by the system we’d meant to assemble. Then, in the same session, a mature solution popped up three more times—each rediscovery happening after someone had already started rebuilding. That moment when the new work stopped and everyone leaned in felt like a bad joke and a revelation at once. What replaced our old habits was a structural gate, not another reminder to be careful.

What we tried, what happened, and the click

We began the session exactly as we always do: define the goal, check the archive, and then start coding. We searched the archive for past attempts and solutions with obvious keywords. The search returned little. So a developer started scaffolding the pipeline—data ingestion, model prompts, review hooks. Two hours later a colleague said: “Wait—there’s a live pipeline doing this.”

We dug. The running pipeline had published sixteen articles. It had a queue, a scheduler, and a human-review handoff. None of it showed up in the initial searches because its registry entry hadn’t been created. The loop was real. It had been running for days. It had simply been invisible to the route we used to find things.

The turning point came when we ran a second experiment. We asked the system to enumerate recent deployments by scanning code repositories and runtime instances rather than the archive index. The live pipeline showed up immediately. Shortly after, the archive’s own maintenance bot tried to extend the site and crashed a live page—because it rebuilt a feature the site already had; it had searched every registry except the code base the feature lived in. That incident made two things painfully clear at once: knowledge can exist everywhere, and our primary habit—search-first through the catalog—was brittle.

The three findings that mattered

1) Invisible-but-running systems cost time as repeated reinvention. We watched a mature solution get rediscovered four separate times during a single work session. Each rediscovery followed rebuild work that had already begun. The measurable cost was developer-hours and duplicated change sets; the qualitative cost was wasted momentum and degraded trust.

2) Norms fail faster than structure. We had a ‘read first’ norm in place—voluntary, moral, respected on paper. It failed three times in one day: people built before reading and repeated the same mistake. We replaced the norm with a simple structural gate: a task with an empty “existing solutions” field is not buildable until that field contains either concrete hits or an explicit “none found.” After that change, rebuild-before-checking dropped immediately.

3) Search-first is as honest as the index. A hands-on test proved our catalog was intake-first, not reality-first. A running component remained invisible until someone manually registered it. The archive index can and did lie to us by omission. The same search engine meant to make everything findable was itself unfindable for a week because it had been buried in an archived database under a tombstoned map. If your search surface doesn’t scan reality—the code, the runtime, the registries—then a search-first habit will fail when it matters most.

The rule that fell out: build a structural gate

Put the answer where the work starts. A voluntary lookup has four failure points—remember to search, choose to search, search well, interpret the hit. When we make the existing-solution check part of the task itself, those four failure points disappear. The rule we now follow: a task that claims to be “buildable” must include concrete evidence of prior work inside the task form; otherwise it is blocked.

Why that rule works

First, it removes human forgetfulness. You can’t “forget” to search if the system refuses to continue until the search field is satisfied. Second, it forces a consistent interpretation: the task must cite a concrete hit or a clear absence. Third, it creates a single point to update pointers. When maps and registries declared their roles and pointed home (and when we required changed pointers to be updated in the same operation), the confusion among five competing maps dropped sharply.

A representative detail (a taste, not a recipe)

We changed the task form to validate the “existing solutions” field at submit time and refuse to create the build ticket when that field was empty. That single rule alone stopped three rebuilds in a week. The full, tested and runnable implementation—integrations, checks across runtime and code, the UI flow and recovery options—lives in the members’ library.

A counter-example that keeps this honest

We learned the gate can lie. In one hands-on test the task-gate showed a clean slate because the archive index had never ingested a running service; the running service only became visible after someone manually registered it. The gate prevented work, but it did so because the index was incomplete. So the safety of a structural gate depends on the breadth and freshness of the index behind it.

In short: structure beats norms for preventing premature rebuilding, but structure depends on honest, reality-first indexing. Both fail if the index is intake-first.

How we know this is not random

We recorded multiple incidents. The same mistakes repeated within single days. We saw rediscovery happen four times in one session. We reproduced invisibility by scanning different sources—archive index versus code and running instances—and watched the result change. We also observed the archive’s librarian bot take down a live site by rebuilding a function it had itself already authored because it hadn’t searched the code it was changing. These are concrete failures, logged in our runtime records and postmortems.

FAQ

Why didn’t simple search solve this?

Because our search was tied to the archive index, and the archive is intake-first: it only knows what someone registered. Running services and code can sit outside that index. In our tests, scanning the codebase and runtime instances surfaced things the archive missed.

Won’t blocking tasks slow teams down?

Short-term friction increases. Teams pause, search, and update the form. But the pause prevents longer delays: repeated rebuilds, integration churn, and trust erosion. After the gate, we saw fewer rebuilds, less duplicated work, and faster convergence to a single working solution.

How do we avoid the gate itself becoming a single point of failure?

Make the gate depend on multiple reality sources—not just the intake index. Require that the index be audited and that pointers be updated as part of the same operation that changes other maps. And accept that the gate will need exceptions and recovery flows; blocking alone is blunt, but paired with broad discovery it becomes useful.

We stopped trusting people to remember. We started trusting the task. That fixed repeated rebuilds overnight. But the task trusts the index, and indices can lie. Build both.

Sources: internal archive front-door documents and runtime logs from our content pipeline and AI-to-AI runtime records (June–July 2026).

What the agent-design and search guidance says

Anthropic’s engineering post Building effective agents separates two kinds of system. Workflows are orchestrated through predefined code paths, while agents are systems where models dynamically direct their own processes and tool usage. A write-review-publish loop is mostly the first kind: the steps are known in advance, and the open question is how reliable each step is.

The post’s general advice is to start small, only increasing complexity when needed. One of its named patterns, the evaluator-optimizer, describes a review loop directly: one LLM call generates a response while another provides evaluation and feedback in a loop. It works best, the post says, when there are clear evaluation criteria.

On autonomy, the same post is cautious. Agents can pause for human feedback at checkpoints, and the authors warn that autonomy brings higher costs and the potential for compounding errors. Their recommendation is extensive testing in sandboxed environments with guardrails.

Publishing adds a constraint from search. Google’s spam policies define scaled content abuse as when many pages are generated for the primary purpose of manipulating rankings rather than helping users, typically content that provides little to no value to users. The policy is about purpose and value, not the tool. An automated pipeline is judged on what it ships.

Where this meets what we found

The guidance assumes you know what your system is. Our problem came one step earlier. The loop we planned to build already existed, with a queue, a scheduler and a human-review handoff, and it had published sixteen articles before we found it. A checkpoint design is only useful if people can find the system it lives in.

The compounding-error warning also matches the librarian incident. A bot that searched every registry except the code it was changing rebuilt a feature that already existed and took down a live page. Nothing about the model failed there. The step before the work, finding what exists, did.

Our structural gate is a small version of the evaluator idea applied to planning: a task cannot become buildable until its “existing solutions” field holds concrete hits or an explicit “none found”. It has clear criteria, which is what the evaluator pattern needs. Its weakness is the one we already logged: the gate is only as honest as the index behind it.

A checklist before you automate publishing

1. Search code and running instances, not only the catalog, before you start building.
2. Make the existing-solutions check a required field in the task, not a reminder.
3. Write down the review criteria. If you cannot, a review step will not help.
4. Keep a human checkpoint before anything goes live, and log what it approved.
5. Test the loop on a staging site before it touches a live one.
6. Ask of every published piece whether it helps a reader, not only whether it passed.

More questions

Is an automated write-review-publish loop allowed by Google?

Google’s policy targets pages made mainly to manipulate rankings, and it applies no matter how it’s created. Automation is not the test. Value to the reader is.

Should the reviewer be a second model or a person?

Either can work for a scoring pass if the criteria are clear. Our loop already had a human-review handoff, and the guidance above suggests keeping a checkpoint wherever an error would be costly to undo.