Inside the Local Search Growth workflow
AgentBiz is the white-label AI marketing team agencies run under their own brand. This page is the mechanics of the workflow we're building with our first design partners — what will be read, what will be drafted, what has to be proven, and where you still have to say yes. The proof-and-approval machinery underneath it is live today.
The lifecycle of one piece of work
Six stages. The delivery steps are what our first design partners will run; the approval, evidence, and reporting machinery they sit on exists today. Each stage either produces something the next can verify, or it stops.
-
01 / BASELINE
Connect and baseline
You'll connect a client's web presence. Before any work starts, the platform will capture where the business stands — so every later claim is measured against a real starting point, not a feeling.
-
02 / FIND
Find the opportunity
The AI will read real data about how the business shows up in local search and pick the highest-priority thing to fix or improve. Every conclusion has to point at real data. If it cannot reach the data, it says so — it does not fill the gap with a plausible answer.
-
03 / DRAFT
Draft the action
A listing fix, a content update, a review reply. The work will be drafted in full — what will change, where, and why — not silently executed.
-
04 / APPROVE
You approve
Anything that reaches a client or the public waits for your yes — that approval gate exists today. A denial isn't an error; the drafted work is handed back for a human to use.
-
05 / PROVE
Act and prove
Approved work will be executed in real systems, and each action has to return evidence from the system it touched — that evidence rule is enforced today. This is the part most tooling skips, so the rules are spelled out below.
-
06 / REPORT
Report under your brand
What reaches the business owner goes out under your brand, after you sign off — the white-label weekly report is live today. Your logo, your color, your name.
The evidence contract
Most AI tooling asks you to trust a “done”. We treat an unproven “done” as a bug.
Evidence comes from the response, not the request.
When an agent changes something in another system, the proof it records is the identifier that system sent back — not the one the agent sent in. An action cannot vouch for itself.
No evidence, no success.
If a write reports success but carries no evidence field, the platform rewrites the result to failed and logs it as a silent failure. The agent then cannot tell anyone the work is done, because as far as the system is concerned, it isn't.
Evidence is inspectable, not buried.
Your agency can open any recorded action and see what ran and the evidence it came back with — action by action, not a rolled-up status. Client reports are put together separately, from completed work that clears our quality checks, and nothing reaches a client until you sign off.
Why the rule exists.
It came out of a real incident in our own system: an integration returned success with an empty id, and the agent confidently reported a publish that had never happened. The contract exists so that failure mode cannot repeat quietly.
Governance boundaries
What the AI is allowed to touch is a property of the platform, not of how carefully someone wrote the prompt.
- Boundaries are declared, not implied.
- What an agent cannot do is declared in the agent's own configuration — a cannot-list the platform enforces — not left to prompt discipline.
- Inside the agent runtime, outward writes are denied unless authorized.
- When an agent tries an action that touches the outside world, the runtime classifies it as an external side effect and denies it by default. It runs only when that specific task carries an explicit authorization. A denial isn't an error — the agent hands the content back for a human to send. How far this guard extends beyond the runtime is disclosed below, not glossed over.
- Nothing touching money is implemented.
- Actions that spend or move money — ad budgets included — are deliberately out of scope today. Not gated — not built.
- Authorization is per task, never a standing grant.
- A yes covers one task, not the account — the runtime guard reads that task's own authorization, so there is no blanket key an agent can reuse. The deeper check, that an authorized task really belongs to the client whose account is being touched, runs today on our first integration's API path; how far it extends is stated plainly below, not assumed.
- Where a human stays in the loop.
- Approvals for pending work, review for anything that fails a quality check, and sign-off before any weekly report reaches a business owner.
What we're not claiming yet
A page like this is easy to overstate, so here is the other half of it.
- Google Business Profile and review-platform integrations. They are not live yet — Google's API approval process is underway. What you see above is the mechanism they will run inside.
- A customer track record in local marketing. No agency or local business is running this in production yet.
- Automatic lead attribution. We promise verifiable evidence for every action and visibility signals measured against a baseline. Counting leads stays human-confirmed until attribution is actually built — we will not promise lead volume on autopilot.
- This governance depth on every integration path. Two different layers do two different jobs today: the agent runtime denies outward writes unless the task carries an explicit per-task authorization, and the check that ties an authorized task to the requesting client's own account runs at the API layer of one integration so far. Other write paths still rely on the runtime guard alone. Closing that gap is engineering work on our side — not something we paper over with copy.
Want to shape what it delivers next?
The first design partners decide which client work gets built out first, and what the client-facing side looks like.
Become a Design Partner →