An AI that can touch your email, your site, your DNS or your books is only worth trusting if it shows the move first, waits for your yes, proves the result went live, and keeps a record you can read back — here is how WALO does each of those today, and where it still falls short.
The pitch for "agentic" software is that it acts. It submits the page, sends the email, books the cleaner, merges the pull request, changes the DNS record. That is also the exact reason it needs a leash. A chatbot that writes a bad paragraph wastes a minute. An agent that sends a bad campaign to 1,400 customers, or deletes a DNS record that carried your email, or confirms a booking that never existed, costs real money and real trust, and the owner usually finds out from a customer rather than from the software.
This piece is about the unglamorous part of WALO, the WhatsApp-first command hub built by AMH — Artificial Mind Hive: the approval cards, the dry runs, the health checks, the rollbacks, the receipts, and the public job board that shows failures next to successes. None of it is magic. Most of it is the boring discipline that the security and AI-engineering literature has been asking for since 2024. We walk the record — what the product's own pages say, what the public job board shows, what the engineering notes behind it admit — and we cite the outside sources that explain why each piece exists.
The Nothing Unseen rule applies throughout: receipts, not verdicts. Where a feature is live, we say what it does. Where it is half built, we say that too.
The problem owners actually have
Picture a Tuesday. A property owner with three short-term rentals is in a hardware store parking lot. Her phone buzzes: a guest checked out early, the cleaner needs to be moved up, and the Airbnb message thread has a question about the lockbox. In the same ten minutes, a plumber's invoice lands in her inbox, and a rank-tracking email tells her a competitor's page passed hers for the only search phrase she cares about.
She does not have a dashboard open. She has a phone, a truck and a half-charged battery. What she wants is to type three sentences and have the right things happen. What she is afraid of is exactly the same thing: that something will happen that she did not mean, and that she will have no way of knowing until a guest complains or a tax preparer asks where the number came from.
That fear is rational, and it is the reason "AI that does things" has stalled with small operators even while the demo videos look great. The U.S. Census Bureau's Business Trends and Outlook Survey found overall AI use across businesses "hovered between 17% and 20%" from December 2025 to May 2026, and that "less than 20% of firms with four or fewer employees reported using AI." The small end of the market, which has the most to gain from one assistant doing five jobs, is the slowest to adopt. Talk to those owners and the reasons are consistent: they cannot see what the tool did, they cannot undo it, and when it is wrong it is confidently wrong.
So the design question is not "how much can the agent do?" It is "how does the owner know, before and after, what the agent did, and how does she stop it?" Every feature in this article is an answer to that question.
How the industry handles it today
There is now a real body of public guidance on this, and it converges on a short list: least privilege, human approval for high-impact actions, logging, and limits on what untrusted content can make an agent do.
The clearest statement is in the OWASP Top 10 for LLM Applications. Entry LLM06:2025, "Excessive Agency," defines the risk as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs," regardless of what caused the model to misfire. OWASP names three root causes — excessive functionality, excessive permissions, excessive autonomy — and the recommended mitigations read like a checklist for any business agent: "Limit the permissions that LLM extensions are granted to other systems to the minimum necessary," "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken," and "Log and monitor the activity of LLM extensions and downstream systems." OWASP also warns against open-ended extensions such as arbitrary shell access, and says authorization should be enforced in the downstream system, not left to the model.
Anthropic's engineering guide "Building effective agents" draws a line between workflows (predefined code paths) and agents (model-directed loops), and says plainly that teams should find "the simplest solution possible, and only increasing complexity when needed." On control, the guide notes that agents "can then pause for human feedback at checkpoints or when encountering blockers," and recommends stopping conditions so an agent does not run forever. OpenAI's practical guide to building agents covers the same ground from the other side of the industry: layered guardrails and a plan for human intervention on high-risk actions.
On the risk side, Simon Willison's "lethal trifecta" is the shortest useful framing of prompt injection: an agent that has access to private data, is exposed to untrusted content, and can communicate externally is an exfiltration machine waiting for the right malicious web page or email. Remove one leg and the attack gets much harder. That framing matters for a WhatsApp assistant that reads your inbox, fetches web pages to audit them, and can send messages. It is the reason approval gates on outbound actions are not a nice-to-have.
The U.S. National Institute of Standards and Technology publishes the AI Risk Management Framework, which is "intended for voluntary use," organized around governing, mapping, measuring and managing risk. It is written for large organizations, but the idea that someone must be able to answer "what did the system do and who approved it" scales down to a three-door rental business just fine.
Two pieces of infrastructure documentation also matter here, because trust is implemented, not declared. Cloudflare's Workers documentation says secret values "are not visible within Wrangler or Cloudflare dashboard after you define them" — once set, a key cannot be read back out by the dashboard, by the command line, or by an agent that only has the dashboard's permissions. And Cloudflare Pages rollbacks "allow you to instantly revert your project to a previous production deployment," with the caveat that "preview deployments are not valid rollback targets." Those two facts — write-only secrets and instant rollback to a known-good build — are the floor that WALO's site-changing features stand on.
Finally, the Model Context Protocol, the open standard that lets AI apps call tools, specifies an authorization layer built on OAuth 2.1 for its HTTP transport. In plain English: an AI client gets a scoped, revocable token after a consent screen, instead of a password copied into a chat. The same principle shows up on WALO's integrations page as a number: zero passwords stored.
What the industry does not yet do consistently is show the owner the record in the place the owner actually is. Most audit logs live in an admin console nobody opens. The interesting part of WALO is that the receipts come back on WhatsApp, and the job board is a public web page.
How WALO does it
The live walohq.com homepage: "Ask once. WALO. handles the rest." with the sign-in card (Continue with Google, Continue with WhatsApp) and, below it, the blue Headquarters app preview with its System Power gauge and "2 of 7 lanes hot" status.
WALO describes itself on its homepage as "your everyday AI command hub in WhatsApp — check email, get alerts, track calories, manage calendars, scan websites, and run business tools when you need them." The sentence that matters for this article comes two lines later on the same page: "Sensitive actions stay approval-gated, so WALO can show the move before anything changes." And on the app's sign-in screen, three bullet points: "Runs on your own Cloudflare and AI account — your keys, your bill," "Every send, booking and payment waits for your approval," and "No account needed to look around. WALO never acts without your approval."
Those are claims. Here is what sits behind each one.
Connecting is not permission
The Connect page at walohq.com/connect: eight lane cards with their status (Ready or Keys needed), the note that "OAuth is the normal path — tokens are the fallback when a provider makes you," and the rule headline "Connecting is not permission."
The Connect page separates two ideas that most tools blur: linking an account, and letting the software act on it. Its rule, in the product's own words: "WALO drafts first, shows exactly what changes, and waits. Nothing writes to code, DNS, payments or a public feed without your word."
The page then lays out the four-step loop that every site or code change follows:
- Ask. "Tell WALO what you want changed — a site fix, an SEO pass, an article."
- Stage. "It prepares the change, lists the exact files and the risk, and holds it."
- Approve. "You reply with the approval phrase. Nothing writes before that."
- Verify. "Browser Agent checks the live page, catches 404s, and sends proof back."
The commands are plain words typed into WhatsApp: connect, connect google, connect github, connections (which "checks your connected services live"), my repos, commits, prs to list open pull requests, merge 1 to "prepare a merge; review the confirmation first," cancel to drop a pending merge, and disconnect github to remove the saved connection. The GitHub card adds a detail worth noticing: "Connect securely in the GitHub screen; no token needs to go into a chat." That is least privilege applied to the channel itself — the chat never becomes a place where a credential is pasted.
The page is also honest about a thing it does not do yet. There is a "power users only" template builder that lets you describe a job setup — repo, branches, allowed folders, checks before it lands — and copy the resulting JSON. Under it, in the product's own words: "The Copy button works right now — it builds the config from your inputs and puts it on your clipboard. Nothing reads it yet. This is an exported planning template. WALO does not execute this configuration from chat." We flag that because it is exactly the kind of disclosure that makes the rest of the page believable.
Approve or Skip cards, per action
The Rental Ops lane is where approval cards are most concrete, because every event has money attached. The page's description: "Every booking, message and payment shows an Approve or Skip card first. WALO drafts the guest reply, books the cleaner, flags the price change — you decide. Turn on auto-approve per action if you want it faster, and switch it back off any time."
Three design choices are packed into that paragraph. First, the default is manual: nothing books, replies or charges until a tap. Second, auto-approve is granular — per action, not a global "trust the robot" switch. An owner can let turnovers auto-book (low risk, reversible, the cleaner is a known contact) while keeping guest messages and price changes on manual. Third, the setting is reversible in the same chat. The same page shows the chat it produces: a question like "whos in maple st this weekend" gets a plain answer with the guest, dates and amount; a photo of a cleaner's invoice comes back as "Logged $95 cleaning for Maple St, Aug 22. Filed under turnovers."; and "how much did i make this month" returns an itemized total with the tax set-aside shown separately and labeled "Rough estimate, not tax advice."
The Developer CRM lane, built for people who buy, fix and sell property, follows the same shape. Its page describes a crew member texting "add $280 toilet to Maple Street" and WALO replying "Logged. Maple Street · Plumbing · $280. Budget left $18,320. Confirm?" — and only after "yes" does it say "Saved." The CRM's own FAQ: "Nothing touches a total until you say yes. Review takes a minute a day, not a weekend a quarter."
Campaigns: a test send, then an explicit yes
The Campaigns page at walohq.com/campaigns: the draft card shows contacts, template and approval state side by side, and step 04 reads "Send a test first. Final send waits for explicit approval."
Email is the action with the widest blast radius a small business can take, so the Campaigns lane is built around a preview and a two-stage send. The flow on the page: "Tell WALO from WhatsApp — birthday invite, follow-up, review ask, event or offer. WALO prepares the draft, pulls the approved contact lane, opens the builder to preview, then waits for approval before anything sends." Step four is unambiguous: "Send a test first. Final send waits for explicit approval."
The page also spells out what belongs in the lane — "Permission-based lists, unsubscribe links, real brand identity" — which is a policy statement as much as a feature. An approval gate does not help if the list itself was never allowed to be messaged.
Buzz: the rule fires, the send still waits
The Buzz page at walohq.com/buzz: automation rules written in plain words, with the example reply making the gate explicit — the rule is saved, the send is not.
Buzz is WALO's automation lane: "when this happens, draft, notify, save, or ask for approval." The example conversation on the page is the whole philosophy in two lines. The owner types "buzz when a lead comes in, text me and add them to my list." WALO answers: "Buzz draft saved: new lead -> text owner + draft follow-up. Sending waits for approval."
The distinction the page draws is between detection and action. "Simple rules can run at the edge; account connectors and sending stay permission-gated." A rule can watch and notify on its own. Anything that leaves the account — a message to a customer, a write to a list — still waits. You see all your rules by texting buzz.
Agent jobs: started, done, and a Next: you can answer
The part of WALO that gets the most attention is the crew. The homepage: "Run your whole AI crew from WhatsApp: Claude, Codex, Grok, Gemini and more. Text an agent's name and the job, or everyone for the whole team. Each one texts you when it starts and reports back when it's done, with a rollback ready. They run in the cloud, so no PC or terminal is needed."
The receipts here are the texts themselves. From the engineering notes behind the product, the pattern each agent follows:
- A job starts with a message that says it started, where it is running, and a rough time estimate based on that agent's recent jobs of the same kind.
- A report comes back when it is done or when it could not finish — the agents are instructed to report "done" or "not done," never silence.
- A report can end with a "Next:" list of options. The owner replies with "yes," a number like "1," or "2 but change the color" and that becomes the next job, assigned to the same agent. No re-typing the context.
stop,pauseandcontinueact on the last job. A hanging check watches for a job that has not started after twenty minutes or has been running for eighty, and sends a notice with a one-word reroute option.- For a team job — "team: rewrite the hours section" — every agent proposes and votes, but nothing goes live until the owner texts
team go. That is the rule the founder set for his own crew and it is the one WALO enforces.
There is also a live check on claims. When an agent's report says something is "live," the runner reads each link it named back from the host and either appends "Live check passed" or "Live check failed" and hands the job to another agent. This was added after an agent claimed a preview page and branch that did not exist. Receipts, not verdicts — including for the robots.
The Agent Board: a public ledger of SHIPPED and FAILED
The Agent Board at walohq.com/board on the day of capture: the live feed shows SHIPPED and FAILED side by side, with token counts on the shipped jobs. Job details stay private; the outcomes do not.
The Agent Board is the single most unusual trust feature in the product, because it is public. The page: "AI agents at work. Jobs come in by WhatsApp, an agent picks each one up, hands it off when another one is better at it, and ships. Job details stay private; this is the live feed." Each row carries the agent's name, the job type — site job, question, or handoff — how long ago it ran, the tokens it used, and one of two badges: SHIPPED or FAILED.
On the day we captured it, the feed showed a ClaudeAMH site job marked FAILED two days earlier, a GrokBucktooth question marked SHIPPED at 134k tokens, several CodexAMH site jobs with both outcomes, and a run of unassigned "any" questions that failed nine days back. We are not quoting that to embarrass anyone. We are quoting it because a job board that only showed green would be marketing, and this one shows the record. The board's own explanation of the pipeline: "Every change gets a dry run, a live health check and automatic rollback. You get the report on WhatsApp." And of the engine: "Agents never hold your keys; they ask Walrus Tusk, and it only does what its guardrails allow. Bounded tools, not raw access. Dry run first, then a health check, then auto-rollback. Keys stay on the server, never with the agent."
For the owner who is signed in, there is a private layer on top of the public feed: an Agents page with each agent's status and ETA, the recent jobs with the exact report that was texted, a per-job "See how it did it" step log, a seven-day bar chart of jobs and tokens per agent, and a Stop button. The step log is the part that answers "what did it actually do" without a single line of AI involved — it is a record, not a summary.
Walrus Tusk: dry run, verified deploy gate, rollback
The Walrus Tusk page at artificialmindhive.com/WT: "The terminal runs on GitHub Actions. You can leave your PC off," and the one-line pipeline every agent job follows before a result is reported.
Walrus Tusk is the engine under WALO's site, DNS and code work — an approval-gated Cloudflare operations server that AI agents call instead of holding an account credential. Its headline is the whole thesis of this article: "AI can plan it. You approve it." The longer version: it connects AI agents "to Cloudflare operations — with dry runs, explicit approval, deployment checks and an audit trail between intent and production."
The page lists seven capabilities, and three of them are specifically about proof rather than action:
- Verified deploy gate. "Checks the public target for an explicit 2xx status, rejects redirects, and optionally requires an expected release marker before reporting success." In other words, "deployed" is not a status the system is allowed to claim until the public URL answered correctly and, optionally, contained the exact text the change was supposed to add.
- Deterministic site health. "Zero-AI HTTP checks remain useful for small valid pages and can require an expected text marker to catch a 200 response serving the wrong site." This exists because a site can return 200 OK while serving the wrong homepage — a failure mode the founder's own hub site has suffered more than once from stray deploys.
- Self-catching email loopback. It "exercises the configured sending/routing path and records delivery evidence; it does not claim to prove placement in a provider's inbox tab." Note the refusal to overclaim, written into the feature description.
The safety model, quoted from the page: "Dry-run by default. Scan before write. Never delete as a side effect. Token hygiene, scoped token only, BIMI precondition, and an audit log for every apply." And under the safety-controls capability: "Read-only defaults, explicit approvals, narrow adapters instead of a generic shell, tenant isolation, retention limits, and a tamper-evident audit chain." "Narrow adapters instead of a generic shell" is OWASP's "avoid open-ended extensions" implemented. "Tamper-evident audit chain" means the log entries are hash-linked, so a missing or edited entry breaks the chain and shows.
The specific mechanism agents use to change a live site is a patch tool that applies only the files the agent sends on top of the current live deployment, re-attaches the site's server bundle, runs a health check — page title plus a few known endpoints — and rolls back automatically if any check fails. A dry run comes first and shows the diff. The rollback target is the previous production deployment, which, per Cloudflare's documentation, can be restored instantly. The page is also candid about scope: the hosted service is version 0.14.1 with "51 built-in tools, 120 with the linked services," the downloadable self-host build is 0.5.3 and "covers the core DNS, email, cache and Turnstile tools; the newest tools run only on the hosted service for now," and "QuickBooks is coming soon."
Receipts for messages: accepted is not delivered
This one is subtle and it is the reason the article has "receipts" in its title. When WALO sends a WhatsApp message, Meta's platform answers with an acceptance — a message ID and an HTTP status. For a long time, that acceptance was the only thing the bridge kept, and it threw away the error codes when a send failed. The result was a class of bug where the owner texted "status" and nothing came back, and nobody could say why.
As of late October 2026, the bridge records a sanitized receipt for every owner-facing send: the message ID, the HTTP or error code, timing, and any delivery or read callback that Meta later posts. It keeps no message bodies and no phone numbers, and the records expire after seven days. The rule the engineering notes draw from it is worth repeating verbatim because it applies to every messaging product, not just this one: a send result of "accepted" does not mean delivered; only a delivery or read callback means the handset got it.
The same discipline shows up in how the bridge treats Meta's rules. WhatsApp's pricing documentation describes a 24-hour customer service window that opens when a user messages the business; inside it a business can send free-form replies, outside it only pre-approved template messages go out. WALO's send endpoint refuses free-form text to a number outside that window and only accepts named templates — the engineering notes call this "the bridge correctly enforcing the 24h-window rule for you — don't 'fix' it." A tool that silently accepted a message it knew would never be delivered would be lying by omission.
The no-fabrication rule
In September 2026, WALO answered a question about a local barbershop's phone number with a number it had invented. The founder's reaction — "straight lied" — became a rule in the code: every phone number in an AI answer must appear digit-for-digit in the material WALO actually read in that turn, or the answer is replaced with an honest refusal that says what it could not look up and how to connect the source that would let it. The rule was replayed against prompts like "just make one up" and it refuses.
The same thing happened with links. The first article WALO drafted from a WhatsApp text and published to Nothing Unseen invented three of its six source URLs. The fix was structural: a research step that reads official pages first, and a verification pass that fetches every link before the preview is sent — dead links are stripped, and the preview reports how many pages were read and how many links were verified. Only after the owner replies "YES" does the article commit, deploy and come back as a live link, texted to the phone.
Neither of those is a feature you will find on a marketing page. They are in this article because they are the receipts for the claim that the product refuses to overclaim.
QuickBooks: dry run by default, and in progress
The Integrations page at walohq.com/integrations: the counter block says "0 passwords stored," and the note beneath it reads "No fake connected claims. A lane shows Ready only when you have authorized it in your own account."
WALO's QuickBooks lane lets a user connect their own QuickBooks Online company and let their AI read it — company info, lists, read-only queries, reports such as profit and loss, balance sheet, cash flow and aging, plus a searchable catalog pulled into WALO. On WhatsApp the commands are books who owes me, books P&L last month, books cash. Writes and sends are the interesting part: they run as a dry run unless the user explicitly passes an apply flag, every attempt is audited, and in the shared agent hub, write and send are policy-gated so an agent must get approval before either goes through. Stored tokens are encrypted and each user's key reaches only their own books.
Status, honestly: the lane is built and verified end to end except for one thing. It is waiting on the developer app keys from Intuit, so no real company can be connected yet. The homepage integrations marquee lists QuickBooks, the WALO app has the QuickBooks card under Business, and the Walrus Tusk page says "QuickBooks is coming soon." Treat it as in progress.
Zero passwords stored
The Integrations page counts 33 listed lanes, 30 ready, 12 one-tap OAuth, and 0 passwords stored. Its FAQ answers the question everyone should ask: "Does connecting give WALO my password? No. OAuth means you sign in on Google's or Meta's own page and they hand WALO a token. We never see or store a password, and you can revoke the token from your account settings at any time." The three steps on the page: pick the account ("you land on that provider's own sign-in page — Google, Meta, Microsoft. Not ours."), approve the scope ("You see exactly what is being asked for before you agree. Decline anything and the rest still works."), and use it from chat ("Ask in WhatsApp and WALO handles it, then reports back what it did.").
Where a provider does not offer OAuth, the page says so per lane — Cloudflare is "API token," Turnstile is "Site key," the AI models are "API key" — and labels the one legacy lane (Vercel) and the one beta lane (Browser Agent) as such. "No fake connected claims. A lane shows Ready only when you have authorized it in your own account."
Under the hood, in plain English
Here is the whole machine as a chain, with no secrets and no hostnames.
The channel. You text WALO on WhatsApp. Meta delivers your message to WALO's server over a signed webhook — the server rejects unsigned requests, which is what stops a stranger from forging "your" instructions. The server also treats your inbound message as the thing that opens the 24-hour window Meta's rules require, so it knows whether a free-form reply is even allowed.
The brain. A language model reads the message with your recent conversation context and decides what you mean. WALO's free default brain is a hosted open-weights model; you can set your own — Claude, ChatGPT, Grok, Gemini, or a local model you run yourself — and WALO tests the key once before saving it. The model does not have your passwords. It has a list of tools.
The tools. Each tool is narrow: read inbox, draft reply, grade site, list repositories, prepare merge, book turnover, file receipt. Reads run freely. Anything that writes to an outside system is tagged as needing approval, and the model cannot change that tag — the tag lives in the tool layer, which is what OWASP means by enforcing authorization downstream rather than trusting the model.
The approval. For a write, WALO sends you the staged change — the draft email, the list of files, the booking card — and waits. Your reply, in words, a number, or a tap, is the approval. The server, not the model, checks that the approval phrase matches a pending action before it runs anything. If you do nothing, nothing happens.
The engine for site and code work. When the job is a site, DNS or code change, the tool call goes to Walrus Tusk. It holds the Cloudflare and GitHub credentials as write-only secrets on the server side. It dry-runs the change, shows the diff, waits for approval, applies, then runs the verified deploy gate — public URL answers 2xx, no redirect, expected marker present — and rolls back to the previous production deployment if any check fails. Each apply is appended to a hash-chained audit log.
The crew. If you addressed an agent by name, WALO posts a job to a shared board and wakes a cloud runner. The agent works through Walrus Tusk's tools — it cannot run a shell, and it never sees a key — and texts you when it starts, when it finishes, and what it suggests next. A handoff passes the job to a different agent, up to three hops. The board shows the outcome publicly; the step log shows you, privately, what it did.
The receipt. The reply is sent, and the send result and later delivery callbacks are recorded for seven days without the message body, so "did my message actually arrive" has an answer.
That is the loop: messaging channel → model → narrow tools → approval → engine with dry run and verification → log → receipt back on the phone. Nothing in it depends on the owner opening a console.
What it costs, and what is free
Only what the sites state.
- WALO core is free. The homepage's access section: "Core WALO stays free. Power lanes can grow with you." The free tier is described as "Everyday AI chat, starter WALO help, free site checks, basic reminders, simple logs, and first setup guidance." The app's sign-in screen says "Core lanes free forever."
- Power AI and Teams / Enterprise are listed as "when needed" and "for serious ops" — heavier model use, deeper memory, shared approvals, audit trails, more connectors — with the line "can be added later." No price is published for either.
- Rental Ops is the one paid lane: $199 per month, "Unlimited doors. Not per unit, not per booking," cancel any time, first seven days refundable.
- Developer CRM: Solo at $149 per month (up to five open jobs) and Crew at $250 per month (unlimited jobs and people), billed through Stripe, "Free while you set it up. No card to start."
- Your own accounts. The app's sign-in screen says WALO "runs on your own Cloudflare and AI account — your keys, your bill." If you set a paid model as your main brain, you pay that provider directly.
- Walrus Tusk is open source under the MIT license; the hosted service is what WALO uses.
- WhatsApp itself. Per Meta's pricing documentation: messages from users to businesses are free; business-sent messages moved to per-message pricing on July 1, 2025; and from October 1, 2026, each business phone number gets 1,000 free service messages per month, after which service messages are charged. A new "Meta Business Agent" message category was introduced July 1, 2026 at a token-based rate the page estimates at roughly four to five cents per message. These are Meta's charges to the business that runs the number, not WALO's.
Honest limits and what is still being built
- QuickBooks is built but cannot connect a real company until Intuit app keys are in place. In progress.
- The WhatsApp number's production status. WALO's number moved to a real production line in late October 2026 after months on Meta's shared test number, which could only message an allowlist. Business verification with Meta was still pending at the time of writing, which can cause intermittent rejections of plain-text replies. If a reply does not arrive, the receipts log is where the answer lives — but the fix is on Meta's side, not WALO's.
- Delivery callbacks. The receipt log records send results reliably; delivery and read callbacks were not yet arriving at the time of the roundtrip test. "Accepted" is the status you will usually see.
- The job-setup template on the Connect page is a planning export only. "Nothing reads it yet."
- Browser Agent is marked beta. The verify step that "checks the live page, catches 404s, and sends proof back" depends on a connected runner.
- The Agent Board shows failures. Handoffs fail, cloud agents hit usage limits, and when a provider's free tier is exhausted the job is handed to another agent. That is working as designed, but a FAILED badge is not a rollback — it means the job did not ship, and the report tells you why.
- Audit depth varies by lane. Walrus Tusk keeps a tamper-evident chain for applied changes. Chat-level actions like reminders and drafts are logged, but not hash-chained. Rentals and CRM keep per-action confirmations. Do not assume every lane has the same evidentiary weight.
- Undo is not universal. Site deploys roll back instantly. A sent email does not un-send; the gate is the test send and the explicit approval. A merged pull request can be reverted in GitHub, but WALO prepares merges, it does not revert them for you yet.
- Memory. WALO keeps your connections, your saved sites, recent conversation context and lane-specific profiles. A fuller saved business profile — voice, services, banned claims, standing permissions — is on the roadmap, not in the product.
A 30-day playbook
Week 1 — read before you write. Sign in at walohq.com, connect one account (Google is the smoothest path per the sign-in card), and spend the week on reads: "what needs me today," inbox summaries, a free SEO grade of your own site. Text connections and confirm the list matches what you actually authorized. Note that the Integrations page shows "Ready" only for lanes you turned on.
Week 2 — one approved write a day. Draft an email reply and send it only after you edit it. Set a reminder. If you have a site on Cloudflare, connect it and ask for a scan; read the plan WALO proposes, then approve one small change and look for the verify step's proof. Write down what the staged change said versus what went live.
Week 3 — automate the notify, not the send. Create one Buzz rule that alerts you — "buzz when a lead comes in, text me a draft" — and leave sending gated. If you run rentals, turn on auto-approve for one low-risk action only (turnover booking) and keep messages and prices manual. If you use campaigns, send yourself the test every time before you approve.
Week 4 — give an agent a job and audit it. Text one agent one job with a clear scope ("claude: fix the broken link on my services page"). Watch for the started text, the done text, and the Next: offer. Open the Agent Board and find your job's outcome; open the Agents page and read "See how it did it." Then ask for the rollback once, on purpose, so you know how it feels before you need it.
Standing rules. Never paste a key into a chat. Treat "accepted" as "sent," not "delivered." Treat any number WALO gives you that you cannot trace to a source as a question, not an answer — the product is built to refuse those, and you should be too.
FAQ
Does WALO act without my approval? Not on writes. Reads and drafts happen when you ask. Anything that sends, books, charges, deploys or changes DNS is staged and waits for your yes. The homepage, the Connect page, the Rentals page and the app's sign-in screen all state this; the Walrus Tusk page says every write is "dry-run or approval-gated."
Does WALO store my passwords? The Integrations page says zero. Accounts connect through each provider's own OAuth consent screen and hand WALO a revocable token. Where a provider only offers an API token or key, the page says so for that lane.
Can the AI agents see my Cloudflare or GitHub credentials? No. Agents call Walrus Tusk's tools; the credentials are write-only secrets on the server, and the tools are narrow adapters rather than a shell. "Keys stay on the server, never with the agent," per the Agent Board.
What happens if a site change breaks something? The deploy gate checks the public URL for a 2xx response, no redirect, and optionally an expected marker. If a check fails, the previous production deployment is restored automatically — Cloudflare Pages rollbacks are instant.
How do I know a WhatsApp message I sent through WALO actually arrived? The bridge records a receipt per send. "Accepted" means Meta took it; only a delivery or read callback means the phone received it. If callbacks are missing, the honest status is "sent, delivery unknown."
What does "team go" do? A team: job makes every agent propose and vote. Nothing from a team or crew job goes live until you text team go.
Can I turn approvals off? Per action in Rentals ("auto-approve per action ... switch it back off any time"). Not globally. Sends and deploys always wait.
Is the Agent Board really public? Yes. Outcomes, agent names, job types and token counts are visible to anyone; job details and the step-by-step log are private to the owner.
Is QuickBooks live? Built and tested, but waiting on the Intuit app keys, so you cannot connect a real company yet. In progress.
What does any of this cost? Core WALO is free. Rentals is $199 a month for unlimited doors. Developer CRM is $149 or $250 a month. WhatsApp's own per-message pricing is Meta's charge to the business running the number.
Where to learn more
- The product itself: walohq.com — the Connect, Integrations, Agent Board and Rental Ops pages are where the approval language lives. The engine: Walrus Tusk and its docs.
- WhatsApp Becomes the Business Command Line — the channel this whole loop runs on.
- WALO and the Agentic App Shift — why "does work under rules" is the category.
- The Local Business AI Stack — search, replies, quotes, campaigns and memory as one loop.
- Review Replies and Yelp Responses — approval gates applied to public replies.
- Small Business SEO Audits — the scan → fix → approve → watch loop.
- IndexNow and Sitemap Submission and Rank Alerts and Competitor Watch — the low-risk writes WALO automates.
- Cloudflare Ops MCP and the Agent Harness — the earlier NU piece on the engine.
- Service Pricer and Quote Follow-up with Service Pricer — the sister product at servicepricer.app, and the AMH Agent Book for the rest of the fleet.
Sources (the record)
- WALO — AI Assistant and WhatsApp Command Hub (homepage) — walohq.com
- Connect — link your accounts to WALO ("Connecting is not permission") — walohq.com
- Integrations — every service WALO connects to (0 passwords stored) — walohq.com
- Agent Board — live feed, powered by Walrus Tusk — walohq.com
- Rental Ops — Approve or Skip cards, $199/month — walohq.com
- WALO Campaigns — test send, explicit approval — walohq.com
- WALO Buzz — automation rules, sending waits for approval — walohq.com
- WALO Developer CRM — "Nothing touches a total until you say yes" — walohq.com
- WALO Legal Center — walohq.com
- WALO — Sign in — walohq.com
- AMH WT — Walrus Tusk (capabilities, safety model, verified deploy gate) — artificialmindhive.com
- Walrus Tusk docs — artificialmindhive.com
- OWASP Top 10 for LLM Applications — LLM06:2025 Excessive Agency — OWASP Gen AI Security Project
- OWASP Top 10 for LLM Applications 2025 (index) — OWASP Gen AI Security Project
- Building effective agents — Anthropic
- A practical guide to building agents (PDF) — OpenAI
- The lethal trifecta for AI agents — Simon Willison
- AI Risk Management Framework — NIST
- Model Context Protocol — Authorization (specification 2025-06-18) — modelcontextprotocol.io
- Model Context Protocol — Getting started — modelcontextprotocol.io
- Secrets — Cloudflare Workers docs — Cloudflare
- Rollbacks — Cloudflare Pages docs — Cloudflare
- Cloudflare Workers docs — Cloudflare
- WhatsApp Business Platform — Pricing (per-message pricing, customer service window, free tier) — Meta for Developers
- WhatsApp Business Platform — About the platform — Meta for Developers
- WhatsApp Business Messaging Policy — WhatsApp
- Large Firms With at Least 20 Employees Biggest AI Users (Business Trends and Outlook Survey, May 26, 2026) — U.S. Census Bureau
- Be There for Every Customer With Meta Business Agent (June 3, 2026) — Meta Newsroom
- Americans' Use of Mobile Devices in 2026 (Mobile Fact Sheet) — Pew Research Center
Originally published on Nothing Unseen, an Artificial Mind Hive (AMH) site. AMH is owned by Austin Little. Product pictures are screenshots of the live sites; tap any picture to open the product.