SafaiKaro: an AI content workflow that a person still has to approve

This is an AI content workflow running on a site we own: SafaiKaro, a pest-control venture owned and operated by Autonomous. Alongside building the site, we needed a way to keep its information accurate and make useful improvements without treating every update as a fresh project.

The site publishes prices and treatment information across service and area pages. That creates a practical responsibility: a change should reach the right places, a new page should include tracking, and claims should reflect what the business can actually deliver. We had already corrected unsupported trust claims and inconsistent price text. The routine was designed around those real mistakes.

Simply put, the routine has to show its working, pointing at a page and a real observation before it proposes changing anything. The workflow collects search, analytics and site-health information, then uses that material to prioritise an opportunity queue. The analyst works from recorded queries rather than inventing figures for a persuasive report. The resulting changes are prepared on a branch so someone can review what would actually change.

This is more useful than asking an agent to improve the website without a defined starting point. A proposal can be tied to a page, an observed problem and a metric. A change ledger records the hypothesis and later review dates, giving the operator a way to revisit whether the change helped, hurt or needs more time.

Workflow: Collect evidence → Draft a change → Independent review → Human approval.

Every mistake we have already made once is written down so a machine can catch it the second time. A versioned claims ledger records phrases that should not return to the site. A deterministic checker examines pages for those phrases, price inconsistencies, broken internal links and structured-data problems. It also checks that new pages include the expected tracking and shared price components.

The checker covers specific known failure modes. It does not understand every possible misleading sentence, and a price value appearing in an approved table does not by itself prove it was used in the right context. That is why the workflow also includes a fresh reviewer for claims, local geography, pricing and the reader’s needs.

The thing that writes the change is not the thing that approves it, and neither of them can publish. The reviewer receives the proposed change and the review criteria without the builder’s reasoning. Findings go back for correction. If a piece still fails review after the allowed correction pass, the workflow drops it and records why rather than quietly treating it as complete.

The routine prepares one pull request and a report linking to it. Its operating instructions do not permit it to merge or deploy. Deployment health is reported as well: comparing the live site with the repository helps reveal when approved changes have not actually reached visitors. A report that says the work is ready is distinct from proof that the site is serving it.

The first verified merged content run was triggered manually on September 6, 2026. Of 22 queue items, 12 shipped, three were dropped, one was handed to a person and six carried forward. Review changed the output, rather than acting as a ceremonial second opinion.

A Monday schedule was configured, but a history of recurring Monday runs was not yet established. The claims checker was also not a required CI status check in the evidence reviewed. The result is a working, reviewable routine with a demonstrated trial, while stronger enforcement and recurring-run evidence remain the next steps.