Free AI Opportunity Audit

I Put an AI Agent in Charge of My Agency's Growth. Here's the Rulebook.

Shyam Verma
I Put an AI Agent in Charge of My Agency's Growth. Here's the Rulebook.

Short answer: Night after night, an AI agent runs this agency's growth function at 03:30 — content drafts, site hygiene, analytics, backlog work. It has never published or sent anything on its own, and it is not allowed to. It works because the governance came before the autonomy: a rehearsal week that caught three real bugs, decision flags that expire, an independent verification layer that has caught an error nearly every time it ran, and a hard allowlist of which numbers it may believe. The honest part comes at the end: the funnel it is growing is still near zero, and the bottleneck turned out to be me.

I run a small agency, and marketing is the function that always loses to client work. This month I stopped pretending I would do it consistently and gave it to an AI agent: an operator with a growth plan, a backlog, a nightly brief it emails me, and rules about what it may touch. This post is the rulebook, with the evidence for why each rule exists.

The permission model: everything is drafts

The core design decision is one sentence: the agent drafts, it never sends.

Lane Examples Who acts
Autonomous Blog drafts, page-copy revisions, site audits, analytics pulls, redirect hygiene, backlog research Agent, alone, at night
Gated Publishing a post, merging anything user-facing, sending any email to any human, outreach of any kind Agent drafts and opens a flag; I approve or reject

A night's output is a stack of pull requests and drafts plus a brief in my inbox at breakfast. Anything that reaches another human — a reader, an index, a prospect — waits for me.

The gated lane is not decorative. Until recently the site still ran Disqus comments across 361 blog posts, and the free tier injects ads into the widget. Rather than assume nobody used it, the agent probed Disqus's own count-data endpoint for all 361 slugs and found zero comments anywhere: the widget was pure ad surface. The replacement (giscus, backed by GitHub Discussions) shipped — as a reviewed pull request, not a midnight surprise. "Probably nobody uses this" turned out to be checkable, and checking it is agent work; deciding stayed human.

Rule 1: Rehearse a compressed week before you trust the schedule

Before the operator ran a single unsupervised night, I made it rehearse a full week of real work — real repo, real analytics, real drafts — compressed into one supervised sitting, with the harness set to halt on any failure. Day one of that rehearsal caught three bugs, all of the class that a quick manual test never surfaces:

  1. Permissions. Two of the agent's own scripts had been committed without the executable bit. Every manual test used bash run.sh and worked; the real scheduler execs the file directly and died with "permission denied".
  2. Silent degradation. A fix that moved the nightly brief email to HTML broke because a cd made the file path relative. The send fell back to plain text and still reported success. Nothing failed; the output was just quietly worse.
  3. The agent invented a fact. Asked to pick its Saturday lane, the model derived the weekday by reasoning about the date instead of running date. It got it wrong and ran backlog work instead of the scheduled audit sweep.

All three were fixed at the shared layer, not the symptom: the exec bit committed properly, missing files now fail loudly instead of degrading, and the weekday is computed in shell and passed in as an argument — the agent's instructions now explicitly forbid it from ever deriving a weekday itself. That last one generalizes: any fact your infrastructure can compute deterministically, compute it and hand it over. Never let the model reconstruct it.

The rehearsal's value was not confidence: bugs of this class only show up under real scheduled conditions, and I would rather meet them while awake.

Rule 2: Decisions expire, and a stale decision is a failure

A gated system has a failure mode nobody warns you about: the human. The agent drafts, opens a decision flag, and waits. If I ignore the flag, the work silently rots.

So the flags age, visibly, and the operator holds a rule against its own interests: when any decision flag passes seven days unanswered, the agent marks its night as failed and stops opening new gated work until the queue moves. It cannot punish me, but it can refuse to pile more drafts onto a queue I am not clearing — which turns my procrastination into a red status I must look at instead of a folder of stale drafts I can ignore.

This rule fired; more on that below.

Rule 3: Never trust one agent's output, and never trust two who agree

Every content and analysis lane runs an independent check pass — a separate agent, no shared context — before anything reaches the gated queue. Reviewing the operator's first weeks, the pattern was stark: verification caught a real error nearly every time it ran. Fourteen issues in one draft. Four errors in another. Two AI-writing tells in a third. Wrong character counts from a subagent. A research tool fabricating a claim outright.

The most instructive failure: two subagents independently agreed on the same wrong root-cause diagnosis for a search-ranking decay. Agreement felt like confirmation. It was two readers of the same misleading data slice sharing a blind spot. The rule now treats agreement between agents as a coincidence to be checked, not evidence — what earns trust is a genuinely independent pass with different inputs or a different method.

If you take one operational rule from this post, take this one. Single-source AI output in a real pipeline has a high error rate, and the errors arrive confident, well-formatted and plausible. In this pipeline, the verification layer is the load-bearing part.

Rule 4: Decide which numbers the agent may believe

When I pulled 90 days of GA4 data for the operator's baseline. The "Direct" channel showed 18,547 active users — and 405 engaged sessions. A roughly 46x gap, almost entirely bot noise mislabeled as direct visits; a shorter pull elsewhere showed the same shape at about 13x. Any trend narrative built on the raw number would have been fiction, refreshed nightly with great confidence.

The fix is a hard metric allowlist baked into the agent's instructions: never report or store raw sessions or totalUsers; steer only by engaged metrics. And one refinement I'd argue matters more: the agent must print the discarded bot-inflated number next to the trusted one, so a human reviewing the brief sees the gap rather than trusting a black-box filter. An agent that quietly filters is only one bug away from an agent that quietly misleads.

Rule 5: Assume the tools lie until they have failed on purpose

The agent's tooling betrayed it three times in a single month, each time silently.

Our site-audit crawler had a hardcoded simplified = true flag that silently skipped the title, meta-description, H1 and alt-text checks. Every prior "427/427 clean" report was clean because the crawler barely looked. A check that has never been shown capable of failing is not a check; it is a false sense of coverage. The rewrite was only trusted after running against a fixture site seeded with one deliberate defect per check, confirming each fires.

The IndexNow script — the thing that pings Bing and Yandex when pages change — was documented as an npm command, but this project runs pnpm, and pnpm forwards the bare -- separator into the script's arguments. The script resolved that stray -- as a relative path and submitted https://readybytes.in/--, a 404, to the search engines on every ping, alongside the real URLs, returning HTTP 200 the whole time. I fixed it the morning I am writing this; unfixed, it would have quietly taught search engines a junk URL forever.

Earlier, the same npm-versus-pnpm gap crashed a setup outright: the project's own docs said npm install throughout, but the repo had migrated to pnpm and nobody updated them. The lockfile was the ground truth; the README was two migrations out of date.

The common thread: test the exact command your automation runs under the exact conditions it runs, not the command in the README, and prove every check can fail before you believe it when it passes.

The honest section: what the rulebook has not fixed

The north-star decision was made the hard way. My instinct was a conversations-first metric — leads, replies. The agent's design process surfaced evidence from another project of mine showing exactly where that leads: visibility with a dead funnel behind it. It took two rounds before I committed to AI-search visibility as the sole north star, with conversations kept as an always-printed, non-goal line in every brief, where it can show zero without false alarm or false success.

It shows zero. Weeks in, the funnel is still near zero, and no governance rule changes that; only the work compounding does. The agent's own entity-resolution work — a site-wide founder identity in the structured data, its identifying URLs matched bit-for-bit against my personal site so answer engines merge the two graphs into one person — is the kind of unglamorous compounding bet the plan is made of. Ask me in six months whether it paid.

And Rule 2 caught exactly who it was designed to catch. Decision flags aged past their window; the constraint on this system was never agent throughput, it was my decision latency. This week I cleared the queue by delegating the decisions themselves to a panel of AI reviewers who argue each flag out and recommend, with me holding the override. Whether that is an elegant fix or the first step of a regress — oversight of agents by more agents — I do not know yet. The queue is empty and the override is real.

What I would tell another owner to copy

If you run an owner-led business and are deciding how far to trust AI in your operations, the transferable part is not my agent. It is the order of operations: governance first, autonomy second.

  1. Draw the draft/send line before the first run. Anything that reaches a human or an index goes through yours.
  2. Rehearse a compressed week of real work, supervised, halt-on-fail, before the schedule runs alone.
  3. Put an independent verification pass on everything, and never accept agreement between agents as proof.
  4. Write down which metrics the agent may believe, and make it show you what it discarded.
  5. Prove every automated check can fail before trusting it when it passes.
  6. Make your own unanswered decisions a visible failure state, because you will be the bottleneck.

None of this required a big team or a platform purchase. It required deciding, in advance and in writing, what the machine is allowed to do — and being honest, in public if you can stand it, about what the numbers still say.


Shyam Verma founded Ready Bytes in 2009 and has been building software since 2005. He writes about legacy modernization, migrations and applied AI at readybytes.in/blog.

Shyam Verma

Shyam Verma

Full Stack Developer & Founder

Shyam Verma is a seasoned full stack developer and the founder of Ready Bytes Software Labs. With over 13 years of experience in software development, he specializes in building scalable web applications using modern technologies like React, Next.js, Node.js, and cloud platforms. His passion for technology extends beyond coding—he's committed to sharing knowledge through blog posts, mentoring junior developers, and contributing to open-source projects.

Comments