Report · Wednesday 2 September 2026
Dil's question, and it is the right one: can these agents run the services we actually sell? The answer is no, and the interesting part is where each one stops. Every accelerant has the same shape — a person decides, an agent researches and drafts, something publishes, an agent measures. The agents do three of those five, in all seven accelerants. This report draws it, then walks each accelerant to the exact point where it stops and says what would close the gap.
The short answer No, an agent cannot run an accelerant on its own. Not because we do not trust it — because publishing needs a connected account and reaching a customer needs a person. Those are two different walls and they get confused constantly.
But it can do the slow middle of all seven, every month, per client, for pennies. That is the part that does not scale with people.
Newsletter, ads, microsites, the Home Pro Network — different content, identical pipeline.
Almost every argument about what an agent can do collapses once these are separated.
| ① Policy wall | ② Capability wall | |
|---|---|---|
| What it is | We decided a person approves this | There is nothing to publish through |
| Example | An ad that spends money. A review reply in Chad's name | No ad account exists. No vendor list exists |
| Can we remove it? | Not for anything that reaches a customer or the bank. That rule is the product | Yes — connect the account, build the list |
| What happens if we ignore it | Something goes out in a client's name that nobody chose | The agent flails, invents, and gives up. This is what happened to the sixteen |
The test that decides whether to build an accelerant agent Not "would this be useful." It is: is there a real job waiting, and does the agent get the tools that job actually needs? An accelerant agent that would draft into a channel we have not connected fails the second half — and we already know exactly what that costs, because we archived sixteen agents in August for precisely that.
Walked one at a time rather than picking the flattering ones.
| Accelerant | What an agent does alone | Stops at | To close the gap |
|---|---|---|---|
| Client & Agent Newsletter | Finds the content, writes both letters, writes the note on what it used | Sending | Ken's twelve + twelve emails first — that is the voice, and nobody else can write it. Then GoHighLevel to send. Gate ① stays |
| Paid Ad Management | Reads the numbers, writes the report, drafts the changes, spots wasted spend | Nothing to read | ⚠️ Gate ② first: there is no ad account spending money. Then gate ① — a person presses the button. This is why I would not build it yet |
| Google Business Profile | Drafts posts, drafts review replies, spots a missing or wrong listing detail | Posting | ⏸️ Already on hold by standing rule: no agent answers a public review in an inspector's name. Draft and surface it; a human posts. Plus per-client profile access |
| Local Microsites | The monthly town-page refresh, as a pull request | Publishing | A repo token scoped to one repository, and a person merges. ⚠️ Build the sites themselves in Claude Code, free — the agent is for upkeep |
| Trusted Home Pro Network | Writes the directory and the vendor pages, drafts the outreach | Contacting a vendor | ⚠️ Gate ② — the vendor list does not exist. And vendor outreach reaches a real business, so gate ① as well |
| Converting Website | Nothing worth paying for. Measured last week: our 31-page site is ~1.27M characters, $0 extra our usual way, $40–$90 an agent's way. Build it in Claude Code | ||
| Authority Builder | Could draft the press release | Syndication | ⚠️ Still unruled by Ken, it is one-time rather than monthly, and it cannot even be priced — the syndication quote is a known missing input |
Four of the seven have a real job waiting and a way to do the middle of it today: Newsletter, Microsites, Home Pro Network writing, and Google Business Profile drafting. Two are blocked on something that is not technology — an ad account that does not exist, and a ruling that has not been made. One should never be an agent at all.
The full list — client websites, SEO, blog posts, Google Business Profile, social via GHL, Monday.com, Telnyx, Analytics, Search Console, and a report to the client. Walked one line at a time.
Short answer: mechanically, yes to nearly all of it. Two items need a workaround, one is blocked by a rule we already have, and the genuinely hard part is not the agent at all.
First, the thing that makes handing over client credentials sane A vault credential never enters the work space. The agent sees a meaningless placeholder; Anthropic swaps in the real secret after the request has left, and only for the hosts that credential is allowed to reach.
So code running in there — including anything the agent writes itself — cannot read a client's WordPress password or copy it out. That holds even if someone plants instructions in a page the agent reads.
⚠️ One real limit: the swap covers the request's headers and body only, never the web address. Anything that puts its key in the URL cannot be vaulted.
| What you asked for | Can it? | How, and what it needs |
|---|---|---|
| Read the client's website, find SEO problems | ✅ Yes | Fetch the pages, restricted to that client's domain. No credential needed at all |
| Edit an HTML site we built in Claude Code | ✅ Yes | The site is in a repo. A token scoped to that one repo, injected outside the work space. It edits, opens a pull request — a person merges |
| WordPress with an app password | ✅ Yes | WordPress takes the password in a header, so it vaults cleanly. ⚠️ This is the single riskiest thing on the list — see below |
| Write blog posts | ✅ Yes | The writing is the easy part. Where it lands is the decision |
| Post to social via GHL Social Planner | ✅ Yes — best supported of the lot | We already have GoHighLevel connected, and the Social Planner is one of the parts it can write to. Tokens refresh themselves |
| Post to Google Business Profile | ⚠️ Yes, with plumbing | Google logins expire and this route does not renew them on its own. Workable, but it is the fiddliest piece. ⏸️ And our own rule already says no agent posts in an inspector's name — that was written for reviews and it points the same way here |
| Monday.com — document the work | ✅ Yes | Straightforward. Key in a header, vaults cleanly |
| Telnyx call data | ✅ Yes | Same shape. ⚠️ Though we already keep the call data ourselves — worth checking we need Telnyx directly before wiring it |
| Google Analytics + Search Console | ⚠️ Yes, with the same plumbing | Google's service logins have to be signed before the request leaves, which is the one thing the vault cannot do for us. The fix is small — we mint the pass on our side and hand it over — but it is a real piece of work, not a checkbox. Read-only, so no risk once connected |
| Build a report from all of it | ✅ Yes | This is exactly what the checker already did for 54 cents |
| Send that report to the client | ⏸️ Draft yes, send no | It reaches a customer, so it waits for a person. Same rule as everything else |
Not the agent. Three other things, and the first one is the one that bites.
Look at what one client needs: a WordPress password, a Google Business login, an Analytics permission, a Search Console permission, and a GoHighLevel account. That is five. At fifty clients it is two hundred and fifty — to ask for, store, keep working, and take back when someone leaves.
We already know what one bad key costs. Today a single key stopped working and it took down Parker, Josh's web chat, James and the quality reader, on our own site, and nobody noticed until we went looking. Now imagine that on a client's website.
The storage is solved. The asking, the chasing and the taking back are not, and they are people-work that grows with every client.
Everything we have built so far could only read, or could only propose. This is the first thing that can change something a client's customers see, on a site we do not own, without anyone looking first.
That is not an argument against it. It is an argument for not starting there.
A blog post, a Google post, a social post, a report in the client's inbox — all of it is public or lands in front of a customer. That is the gate we already have, and it does not move for this.
⚠️ And do not price this off the 54 cents That figure was a read-only helper reading three files we handed it, with no internet at all. This one visits websites, calls five or six services and writes real content. It will cost several times more, and I am not going to guess how much. The same rule applies: build one, run it once, read the bill.
Draft. Do not publish. WordPress can take a post as a DRAFT. Social and Google posts can sit in GoHighLevel waiting for approval. The report can land in the client's portal instead of their inbox.
That is almost all of the value with none of the "an agent changed my website" risk — and it is the same shape as the rule we already keep for review replies.
Publishing on its own is something a client earns into later, one at a time, not where we start.
A staged way in — each step earns the next
And measure at every step
Two things could be meant by that, and the answer differs. Both are short.
XYZ Home Inspections (xyz) was built on 1 September for exactly this.
It is the wide one — nearly the whole service catalogue, banded pricing, packages,
every follow-up email on. PDF Inspection Services (pdf) is the narrow
one, four services and a flat price, built so refusals can be tested.
Three reasons they beat a fresh account: they went in through the real onboarding
form, not a seed, so the CRM record, the sub-account, the portal login and the welcome
email all exist. They are flagged in code — isTestFirm(slug) — so the
build board does not count them and the CRM note opens with a NOT A CLIENT banner. And the
slugs are reserved, so a real company can never collide with one.
Use xyz for the newsletter test — it has the widest catalogue, so it
is the one that exercises the most content.
A workspace of its own, with its own key, is worth the five minutes:
Agent spend lands on its own line, so the cost-per-client question Beth is working on gets a clean answer instead of one tangled with the q app's usage. And a mistake in an agent cannot touch the key the live app runs on — separate keys, separate blast radius.
⚠️ One gotcha worth knowing before you make it. Session links in the Console are per workspace. If the key belongs to a workspace other than Default, the trace link our script prints will land on "Session not found" — the session is fine, the link is looking in the wrong place. Tell me the workspace ID once and I will put it in the script.
Before anything is built
Then the first accelerant, and only one
xyz. It is the best fit, it has a test firm
with the widest catalogue waiting, and the whole thing can be proven without touching a
real client — draft both letters, read them, and never press send.What I would not start