Review a proposed campaign change in chat. Nothing moves until you approve it.
Ask Mako to cut a budget or pause a campaign and it writes a proposal, never a change. The card carries the value now, the value proposed, the numbers it leaned on, and any warning our own code computed. You press approve. It publishes once, reads the platform back in the same request, and compares the two field by field. A disagreement is recorded as a failed verification and never as a success.
Write access is off on every new connection. You arm it one account at a time, and every single change still needs its own approval.
- 01The platform, derived from the action type by the same rule the executor dispatches on
- 02What changes, current value beside proposed value
- 03Every number the claim leaned on, with its verified source, window and freshness
- 04Warnings our server computed, sitting directly above the button
- 05Approve, dismiss, and on a budget card an edit whose typed figure is re-checked
Section 01 · the three switches
Three switches stand between Mako and your money.
Writes are off when you connect.
Every connection is stored with write access off. While it is off, the change tools are left out of the request we send to the model, so there is nothing for it to call. It cannot propose a change it was never handed, whatever you ask it.
You arm one account at a time.
The switch lives on that one connection and turning it on takes a confirmation that spells out what it enables: the agent may propose live changes, and each one still needs your approval. Arming Meta does not arm Google. Turning it back off takes one click and no confirmation, and it never disconnects the read.
Each change needs its own approval.
There is no bulk approve, no auto-approve mode and no dry-run shortcut around it. One card, one decision. Every write tool re-checks the switch and the platform grant on its own before it will draft anything, and the endpoint that executes checks both again at the moment you press.
Which permission we ask each platform for, and why neither one has a read-only version, is on the integrations page.
Section 02 · one change, start to finish
One change, start to finish.
Six frames, in the order they happen to you. Nothing here is a rendering of a future version: every frame is a step that exists in the code today.
"Prospecting is over my cost ceiling. What should I do?" Plain words, in the chat, with no form and no builder.
Live reads fire at the moment you ask, and the trace above the answer shows each one: the tool, its one-line summary, and whether it succeeded. Meta campaign insights · last_14d · 11 rows. A read that failed shows as failed rather than being dropped so the answer can look cleaner.
The write tool creates a row awaiting your approval and returns a card. It does not execute. A number the agent cannot trace back to a read from that same turn blocks the proposal before a card exists.
The diff, the evidence, the warnings, then approve or dismiss. $420.00 → $320.00 is the whole change, written out. Leave it and nothing happens.
On approve the endpoint re-checks your subscription and that connection's write switch, refuses anything older than 24 hours, claims the row atomically so a double click cannot fire twice, re-runs the propose-time guards against fresh platform state, then sends exactly one write.
The platform is read back in the same request and compared against what you approved. A match settles the row as verified. A mismatch settles it as a failed verification, with the discrepancy in plain words.
Between frame 03 and frame 04 the product does nothing at all. That gap is the feature.
Section 03 · what you see before you approve
What you see before you approve.
The card above is not a mock-up of the product. It is rendered by the same function that turns a stored proposal into the card in your workspace, so every part below is the part you will actually read.
| Part of the card | What it shows | Where it comes from |
|---|---|---|
| Platform label | Meta or Google Ads. | Derived from the action type by the same rule the executor dispatches on, so the label cannot disagree with where the write goes. |
| Title | The change in one line. | The summary stored on the proposal row, composed in code when the proposal was created. |
| Why | One sentence of the agent's reasoning. | The model's claim, stored with the proposal. It is the model's, and the card presents it as the model's. |
| Diff rows | Current value beside proposed value, one row per thing that changes. | Read from the platform when the proposal was drafted and stored as the before state and the requested state. |
| Evidence | Each number the claim leaned on: the metric, the value in your account’s currency, the verified data source, the scope it applies to, the reporting window and the data freshness. | The proposal's evidence list. The parse fails closed, so anything malformed renders as no claim and no receipts, never as invented ones. |
| Before you approve | The tradeoffs, in amber, directly above the approve button, in the awaiting state only. | Computed by our server before the card exists and stored outside the model's own schema on purpose, so the model can neither write these warnings nor suppress them. |
| Buttons | Approve and dismiss, plus an edit on a budget card. | The live card is handed an approve handler, a dismiss handler, and on a budget card an edit handler, so the edit button renders there and nowhere else. |
| Executing checklist | Write to the platform, then verify by re-reading. A budget move shows four rows, one pair per leg. | Built per action type by the same mapper. |
| Change | Platform | What the card shows |
|---|---|---|
| Campaign status | Meta Ads | One status row, ACTIVE to PAUSED or the reverse. |
| Campaign daily budget | Meta Ads | One daily budget row, both figures in your account's currency. |
| Budget move | Meta Ads | One row per leg, with the total held constant. The source falls by exactly what the destination rises by. |
| Campaign status | Google Ads | One status row, ENABLED to PAUSED or the reverse. |
| Permanent campaign removal | Google Ads | Supervised rollout, off by default. The card names the exact already-paused campaign, its budget identity and the permanent loss of its campaign ID, history and learning state. Google validates and receives one non-retried removal. |
| Pause a campaign batch | Google Ads | Supervised rollout, off by default. The card lists 2–10 exact enabled campaigns, requires a second confirmation and applies them as one atomic pause. Every campaign is re-read afterward. Bulk enable, budget, targeting and mixed changes are excluded, and there is no one-click bulk undo. |
| Label relationship | Google Ads | Supervised rollout, off by default. The exact campaign, ad group, ad or keyword and the label’s current relationship are shown before one label is created, attached or removed. |
| Asset relationship | Google Ads | Supervised rollout, off by default. The card shows the exact campaign or ad group, the existing asset’s type and content summary, the current link status and the requested attach, pause, enable or removal before you approve. |
| Performance Max asset-group settings | Google Ads | Supervised rollout, off by default. The card shows the exact current and requested name, enabled or paused status, HTTPS destinations and display paths for one existing asset group. Creative, audience, product, budget and bidding settings stay unchanged. |
| Performance Max signal | Google Ads | Supervised rollout, off by default. The card names the exact asset group and one search theme or existing audience being added or removed, and warns that signals guide Google rather than confining delivery. |
| Shopping product-group leaf | Google Ads | Supervised rollout, off by default. The card names the exact Performance Max asset group or Standard Shopping ad group, existing non-root leaf and inclusion change, or the exact before-and-after Manual CPC bid in the account currency. It warns that the whole tree must remain unchanged and that inclusion can change delivery. |
| Campaign name | Google Ads | One exact name row for one existing campaign. Status, budget, targeting and delivery remain unchanged. |
| Search Partners | Google Ads | Supervised rollout, off by default. One exact On/Off row for an existing Search campaign, with warnings about reach, spend and the limits of undo. |
| Campaign dates or tracking | Google Ads | Supervised rollout, off by default. Exact before-and-after date rows with the account time zone, or exact campaign tracking values. Clearing an end date says No end date; clearing tracking says Not set at campaign level, because inherited tracking can remain. |
| Campaign targeting and delivery controls | Google Ads | Supervised rollout, off by default. One exact operation shows the reviewed country, region, radius or language target, demographic exclusion, device modifier, complete account-time-zone schedule or placement exclusion, with delivery and undo warnings. |
| Standard bidding strategy, target CPA or target ROAS | Google Ads | Supervised rollout, off by default. The card shows the previous and proposed standard strategy or target, with target CPA in the account currency and target ROAS as both a percentage and multiplier. Strategy switches also bind the campaign’s complete conversion-goal evidence. |
| Portfolio target CPA or target ROAS | Google Ads | Supervised rollout, off by default. The card shows the exact strategy and target, every linked campaign and the combined daily-budget ceiling, counting shared budgets once. |
| Campaign daily budget | Google Ads | One daily budget row, both figures in your account's currency. |
| Shared daily or campaign total budget | Google Ads | Supervised rollout, off by default. One exact row shows the budget amount or name before and after, in the account currency where applicable, and names every linked campaign affected by a shared-budget change. |
| End one running experiment | Google Ads | Supervised rollout, off by default. The card names the exact experiment, its traffic split and affected campaigns, explains that treatment stops without being promoted, requires a second confirmation and states there is no one-click undo. |
| Dismiss one Google-native recommendation | Google Ads | Supervised rollout, off by default. The card names the exact recommendation ID and type, says the impact estimate came from Google, and states that dismissal is permanent while campaign delivery stays unchanged. |
| Campaign conversion goals | Google Ads | Supervised rollout, off by default. The card names the exact campaign, goal category and source, whether Google may bid toward it, and whether the campaign will use its own map or the account defaults. Every approval requires a second confirmation. |
| Create a secondary conversion action | Google Ads | Supervised rollout, off by default. The card shows the exact secondary website or call conversion action and its settings, requires a second confirmation, and returns Google’s installation code after a verified create. Sable Mako does not install or verify the tag, make the action primary, or change attribution and account defaults. |
| Create an account-level callout | Google Ads | Supervised rollout, off by default. The card shows the exact 1–25-character text and account-level scope, requires a second confirmation, and warns that Google may still review or limit the new asset. |
| Create a detached call asset | Google Ads | Supervised rollout, off by default. The card shows the exact phone number, reporting choice and complete account-time-zone business hours, requires a second confirmation, and explains that creation does not attach the immutable asset. A replacement leaves the old asset unchanged. |
| Create a detached Google-hosted lead form | Google Ads | Supervised rollout, off by default. The card shows every visible sentence, requested field, privacy policy, post-submit destination and policy attestation, requires a second confirmation, and explains that creation does not attach the form. Leads remain in Google-hosted download rather than Sable Mako. |
| Negative keywords | Google Ads | One row per term, each showing the term and the match type that will block it. |
| Remove campaign negative keywords | Google Ads | One row per exact existing term, including match type, before removal. |
| Manage positive keywords | Google Ads | One row per exact keyword in one ad group, showing match type and the current and requested status, or that a term will be added or removed. |
| Manage an existing ad group | Google Ads | One exact row for ad group status or name, with the current value beside the requested value. |
| Manage Search ad-group structure or an existing audience link | Google Ads | The exact paused creation, removal, Manual CPC bid change, or existing user-list inclusion, exclusion or Observation/Targeting mode. Independent release gate, off by default; removals are permanent. |
| Change location-presence mode | Google Ads | The previous and requested location-presence mode for one Search campaign. Independent release gate, off by default. Existing targets and exclusions remain unchanged. |
| Create a paused Search ad | Google Ads | Every headline, description, pin, destination and display path in an existing ad group. One supervised validation-and-create run passed in an isolated Preview. The family is released in Production for admitted workspaces, and creating the ad still requires exact approval. |
| Change a keyword bid, destination or match type | Google Ads | The keyword identity and current Manual CPC bid, HTTPS destinations or match type beside the exact requested value. Independent release gate, off by default. Match-type replacement changes the criterion id and cannot preserve learning state. |
| Existing ad status | Google Ads | One exact status row for one existing ad, with its ad-group and campaign context. This status operation leaves content unchanged. |
| Permanent paused-ad removal | Google Ads | One exact already-paused ad and its campaign and ad-group context, with a permanent-removal warning. Independent release gate, off by default; the same ad id and learning state cannot be restored. |
| Paused responsive search ad text and destinations | Google Ads | Supervised rollout, off by default. Every headline, description, pin, HTTPS final URL and display path is shown. The exact ad and its parent state are bound to the card, and the ad remains paused after a verified update. |
| A new campaign, paused | Google Ads | No before and after rows, because nothing exists yet. The card shows the campaign itself: budget, countries and languages, every keyword with its match type, every headline and description with its character count against the platform limit, and each image you uploaded. |
| New TikTok campaign | TikTok Ads | No before and after rows, because nothing exists yet. The card shows the campaign itself: budget in the advertiser's own currency, objective, locations, the schedule in TikTok's own time format, which identity the ad runs under, the ad text against TikTok's character limit, and the video id it will use. It also says plainly that TikTok has not validated any of it, because TikTok publishes no way to check a campaign before creating it. |
| Publish the product feed | Google Merchant Center | How many products would be added, updated and removed, and how many are already published unchanged. On a first publish the card also names the Merchant Center account and the data source Sable Mako would replace, because that publish takes over the feed serving your Shopping ads. |
The warnings are the part a model cannot touch. They are computed in our own code before the card is built and stored beside the model's reasoning rather than inside it, deliberately absent from the schema the model writes into. So a model that would rather you did not see a tradeoff has no field to put it in and no field to take it out of.
The card carries no estimated saving and no projected impact. We do not compute one, so it does not show one. A modelled figure on a money decision is the kind of number that gets quoted back at us and cannot be defended, and its absence is deliberate rather than an omission.
You can correct the number before approving. A budget card lets you type the figure you want. It runs the same magnitude, churn and cap checks the agent's figure runs, and it is recorded as a human-stated figure the model can never originate, so an edited number is re-checked rather than trusted blind.
Section 04 · what it can change
What it can change. What it cannot.
Forty operations across four platforms. Google Ads campaign creation is released in Production for admitted workspaces; TikTok Ads campaign creation remains switched off. All thirty-two Google action families have separate supervised release gates and require workspace admission. They include bounded campaign batches, permanent paused-campaign removal, experiment end, recommendation dismissal, Performance Max and Shopping controls, budgets, conversion goals, secondary conversion-action creation with code returned for installation, account-level callout creation, detached call-asset creation, detached Google-hosted lead-form creation, campaign settings, location and delivery targeting, standard and portfolio Smart Bidding targets, paused Search-ad content, ad-group structure and existing audience links, keyword settings, labels, existing asset relationships, new paused Search-ad creation and permanent paused-ad removal. Experiment creation, experiment scheduling, promotion and graduation and Google’s generic recommendation apply endpoint are not implemented. This is the whole implemented list, including gated operations, followed by what is missing.
| Platform | What Mako can propose today | What it cannot do today |
|---|---|---|
| Meta Ads |
| Create or delete campaigns, ad sets or ads. Upload creative. Change targeting, bidding, schedules or objectives. Change lifetime budgets. Change account settings. Set an ad-set budget on its own: an ad-set budget moves only as one leg of a budget move. |
| Google Ads |
| Create or edit most asset content, manage location asset sets, or change Performance Max asset-group assets. Edit image, video or non-responsive-search creative, or edit the content of an enabled ad. Create audiences, upload Customer Match data or build arbitrary Shopping trees. Delete campaigns or enabled ads. Edit or remove an existing conversion action, install or verify tracking code, change attribution, or turn budget sharing on or off. Move budget between campaigns as one conserved operation: there is no Google Ads rebalance tool, and the agent is instructed to say so rather than fake one with two separate writes. |
| Google Merchant Center |
| Change bids, budgets or campaigns. Change your Merchant Center account settings, shipping, tax or returns. Delete a data source. Touch an account you did not connect. Merchant Center accepts products one at a time, so a publish reports each item's outcome and can end partial; it never claims Google approved anything, because approval arrives later and the feed audit is what reports it. |
| Shopify | Nothing. Shopify is read-only today: no write permission is requested and no write path exists in the code. | It is absent from the list of providers the write switch accepts, so the switch refuses to arm for it. There is no proposal tool and the code that executes approved changes has no Shopify branch. |
| TikTok Ads |
| Change anything that already exists: statuses, budgets, bids, targeting and schedules. Delete anything. Upload creative: the video has to be in your account already and we send its id. Touch audiences, pixels or the Events API. TikTok has no all-or-nothing create either, so campaign, ad group and ad are three separate calls; every object is created paused for that reason, and a build that fails part-way names exactly which objects exist rather than reporting a bare error. |
| Google Analytics 4 | Nothing. The permission we request is read-only. | We read your property list and your traffic by source. No write permission, no mutating call. |
| Google Search Console | Nothing. The permission we request is read-only. | We read your site list and your search queries and pages. No write permission, no mutating call, and there is no write path. |
Not built: LinkedIn Ads, Microsoft Ads, Pinterest Ads, Snapchat Ads, Klaviyo, Amazon Ads. No connector, no login flow, no API client and no agent tool for any of them. We write not built rather than planned, because that word is a delivery promise and there is no date behind one.
Two platforms can be written to. Everything else we connect is read-only by construction rather than by policy, and the bound is structural: one function in our code sends a change to Meta and it has four callers, three for the changes above and one that writes the account-level spend cap set at connect. Google mutations compile from closed service-specific operation lists, including exact criterion removals, ad-group changes, existing-ad status changes and a separate permanent-removal operation restricted to already-paused ads. Atomic multi-operation paths carry paused campaign creation, the independently gated Google families and a separate 2–10 campaign pause batch. Separate non-retried Google endpoints can permanently dismiss one exact provider recommendation without applying it, end one exact running experiment without promoting treatment changes or selecting a winner, and create verified detached call or Google-hosted lead-form assets. All thirty-two Google action families are released in Production for admitted workspaces, and every exact change still requires the connected account’s write switch and human approval. No outbound operation can delete a campaign, enabled ad, account or conversion action.
Where this stands today.
Meta is a reviewer-only path. Meta's read and write code is implemented, but Meta app review is still in progress. Access is limited to Meta reviewers and explicitly allowlisted test accounts, and no Meta capability is offered to ordinary beta customers.
Google Ads is the ordinary controlled-beta path. Account reads and recommendations are available to beta customers. All thirty-two Google action families are released in Production for admitted workspaces and every action still requires exact approval. Campaign status, campaign name and one private daily-budget path have supervised Production write-and-inverse evidence; the other released families remain under supervised validation until their own provider acceptance is complete.
Every field we read from each platform, and the permission behind it, are on the integrations page.
Section 05 · the limits, in code
The limits live in code, not in a prompt.
Two kinds of rule. A block means no approval card is ever created, so there is nothing to press. A warning means the card is created and carries the tradeoff above the button.
| Rule | What happens | Where it applies |
|---|---|---|
| A budget increase larger than 300% | Block Blocked. No card is ever created. | Meta campaign, Meta ad set, Google Ads campaign |
| A budget change larger than 20%, up or down | Warning Allowed, with the tradeoff printed on the card above the approve button. | Meta campaign, Meta ad set, Google Ads campaign |
| A Google Ads budget shared with other campaigns | Block Blocked when the proposal is drafted, and blocked again by the executor before it sends, because changing it would move money in campaigns you did not review. | Google Ads campaign budget |
| A Meta campaign whose budget lives on its ad sets, or that runs on a lifetime budget, or an amount of zero or less | Block Blocked. | Meta campaign budget |
| A campaign already in the state being asked for, or deleted, or archived | Block Blocked, with the campaign's real current state named. | Meta status changes |
| A Google Ads campaign that has been removed, or cannot be read from the account | Block Blocked when drafted, and re-checked against live state before the write is sent. | Google Ads changes |
| A budget move whose two sides sit in different ad accounts | Block Blocked, failing closed, because two accounts can bill in two currencies. It is blocked the same way when the account cannot be confirmed at all. | Meta budget move |
| A budget move that would take the source to zero or below | Block Blocked. Turning a campaign off has to be proposed as a pause and approved as one. | Meta budget move |
| A campaign covered by a lock rule you wrote | Block Blocked in code, and the refusal quotes your own words back at you. | Meta and Google Ads status changes |
| A number in the proposal that cannot be traced to a live read from that same turn | Block Blocked before a card exists, with strict matching, so a hundredfold unit error cannot pass as a rounding difference. | Every change |
| A proposal older than 24 hours | Block Refused at approve time. Nothing transitions and nothing is sent. Ask again and the account is read afresh. | Every change |
| Writes switched off after the proposal was drafted | Block Refused at approve time. The card stays pending with the reason on it. | Every change |
| A Google Ads change that could apply to more than one connected account | Block Blocked. Mako asks which account you mean instead of guessing. | Google Ads changes |
| Negative keywords per proposal | Warning Bounded between 1 and 20, in the schema the model is offered and again at runtime. | Google Ads negative keywords |
| Pressing approve twice | Warning An atomic claim on the row means exactly one write goes out. The second press loses the race and is answered with the first one's result. | Every change |
These are not instructions in a prompt the model could talk itself out of. They run in our own code, before the model's output ever reaches a card, and the ones that guard money run again at the moment you press.
Section 06 · the second you press approve
What happens the second you press approve.
Seven steps, in one request. There is no queue, no worker and no callback: the write and the check that proves it are the same round trip.
- 01Your subscription and that connection's write switch are re-checked at the moment you press, not at the moment the proposal was written.
- 02Anything older than 24 hours is refused, and nothing transitions.
- 03The row is claimed atomically, moving from proposed to executing. A second press loses the race and replays the same answer.
- 04Inside the claim, the propose-time guards re-run against fresh platform state. If the account moved underneath, the row settles as failed with the reason and nothing is sent.
- 05Exactly one write goes to the platform.
- 06The platform is read back, in the same request.
- 07The re-read is compared against what you approved, field by field. A match settles as verified. A mismatch settles as a failed verification with the discrepancy stored in plain words, for example "Re-read shows 420 USD, not 320."
A proposal is a claim about a moment. Past 24 hours the numbers on the card describe an account that has moved, so the honest answer is to ask again rather than to execute on a snapshot nobody re-checked.
Activating a Meta campaign counts as done only when the re-read shows it delivering. Meta reports a campaign's own status and its effective status separately, and a campaign can be ACTIVE in name while gated by review, by budget or by an account issue. The check reads the effective one, so accepted is not treated as live.
If the guards cannot be re-run, nothing runs. An action type with no re-checkable guard is refused rather than allowed through on a pass that was a claim about nothing, and a read failure before the write settles the row as failed with the reason instead of executing blind.
Section 07 · the record it leaves
Every change leaves a record you can read.
One row in our database per proposal, approved or not, written as the change moves through its states. This is what the row holds.
| Field | What it holds |
|---|---|
| Summary and action type | What was proposed, in words, and which of the forty operations it was. |
| Target and connection | The campaign, ad set or campaign target, and which connected account it belongs to. |
| Conversation and message | The exact turn of chat the proposal came out of. |
| Decision | The agent's claim, its confidence, its evidence list, and the warnings our server computed and showed you. |
| Before state | What the platform said before, at propose time. |
| Requested state | What you were asked to approve. |
| Executor result | What the platform returned. |
| Verified state | What the platform said when we read it back. |
| Verification result | Whether those two matched, and the discrepancy where they did not. |
| API error | The provider error or host safety reason, mapped into a title, a detail and a suggested fix. |
| Timestamps | Created, decided, executed. |
The states a change can be in
Only finished rows become receipts. A proposal still waiting on you is not a receipt, because nothing has happened. The ledger on your Today screen is built from rows that reached a decision, so it is a record of what was done rather than a list of what was suggested.
One thing we will not claim. The record stores that a change was approved, when, on which account, and which signed-in person pressed the button. Workspaces can include an Owner and Members, so that person-level record is what makes each approval accountable. A proposal that expires because a newer one replaced it records no approver, because nobody approved it.
How long we keep all of this, and how to have it deleted, is in the privacy policy.
Section 08 · when something goes wrong
When something goes wrong, it says so.
The second fear about letting anything touch a live account is not that it refuses. It is that it fails halfway and nobody tells you. Here is every way this can end badly and what you see in each case.
| What went wrong | What you see | What we do |
|---|---|---|
| The platform rejects the write | failed Failed, not confirmed live, with the provider's own reason translated into a sentence and a suggested fix. | Nothing changed. The row settles as failed. |
| The write applied and the re-read disagrees | verification failed A failed verification, with the discrepancy written out. | It is not marked done and it does not go green. The mismatch is stored on the row so a reload shows the real difference rather than a generic sentence. |
| A budget move fails after its first leg | rolled back Which legs applied, and that the account was put back. | Compensation runs on its own: applied legs are restored in reverse order and re-read to confirm they landed. The row settles as rolled back. |
| The compensation itself fails | rollback failed Could not fully undo, action needed, naming the exact entities and the value each should be back at. | We say the true thing rather than the comfortable one: a step failed, we could not fully undo it, and your account may be changed. Check these in Ads Manager. |
| Something throws after the write was sent | failed Failed, with the real error. | The write may or may not have applied, so we say exactly that and tell you to re-check the campaign before retrying. The row is never left stuck mid-flight. |
| The guards refuse before anything is sent | failed The account changed since this was proposed, with the blocker named. | Nothing was sent. The row settles as failed and says so, which is a different sentence from the one above on purpose. |
Undo prepares another approval, not an immediate reversal. Eligible verified Google Ads receipts can prepare the opposite change using their recorded previous state. Current settings and rules are checked again, and the new card waits for your approval. Unsupported or unverified actions need manual review. Undo cannot recover spend, impressions or learning effects. Compensation inside a failed Meta budget move is a separate automatic recovery path. Uncertain platform writes are not automatically replayed.
A mismatch is never recorded as a success. The status a card shows is derived from the re-read, not from the platform's own reply, so a partial cannot be presented as a completion. That is why the verified footer says the change was confirmed live by re-read rather than saying the platform accepted it.
Section 09 · the questions worth asking
The questions worth asking.
Can Mako change my campaigns without asking me?
No, and two separate gates stand in the way. A connection is read-only until you switch writes on for that specific account, and while it is off the change tools are never handed to the model. With writes on, every individual change still creates a card that waits for you. There is no auto-approve mode in the product.
What if I never approve anything?
Nothing changes. Proposals sit there and are refused after 24 hours. Read-only features can continue without enabling writes, but repeat audits, monitoring, alerts and Mako require an active trial or plan.
What happens if a change fails halfway through?
Two cases. A single change either lands or does not, and the re-read tells you which. A budget move has two legs, so if the second fails the first is put back automatically and the row is marked rolled back. If a leg cannot be put back, we say so and name the exact campaigns to check in Ads Manager instead of pretending it resolved.
Can I undo a change?
Eligible verified Google Ads receipts offer an undo that prepares another approval. It restores a supported setting only after current checks and your new approval. Unsupported or unverified actions need manual review, and undo cannot recover money already spent.
What are the hard limits?
A budget increase larger than 300% is blocked outright and never becomes a card. A change larger than 20% carries a warning on the card, because a swing that size restarts the platform's learning. Shared Google Ads budgets are blocked. Budget moves across two ad accounts are blocked. Any campaign you have told Mako to lock is blocked in code, and the refusal quotes your own rule back at you.
Can it invent a number to justify a change?
Structurally, no. Every figure on a proposal has to trace back to a live read from that same turn, the check runs before the card is built, and the metric it can cite is a closed list of the metrics our read tools actually return. A proposal with an untraceable number is refused rather than softened.
Which platforms can it actually change?
Google Ads is the ordinary controlled-beta connection. Its bounded changes require approval of the exact action and remain under supervised validation. Meta has implemented change operations but is reviewer-only while app review completes. Merchant Center publishing is supervised-only. TikTok write actions are unavailable. Shopify, GA4 and Search Console have no customer write path.
What if I click approve twice?
The row is claimed atomically, so exactly one write goes out. The second press gets the same answer as the first, because the endpoint is idempotent rather than because the browser stopped you.
Do you record which of us approved it?
Yes. We record that a change was approved, when, on which account, and which signed-in person pressed the button. Workspaces can include an Owner and Members, so each approval is attributed to the person who made it. A proposal that expires because a newer one replaced it records no approver, because nobody approved it.
Do I need a paid plan to publish?
Google Ads connection and one initial audit need no card. Repeat audits, monitoring, alerts and Mako require an active trial or plan. Merchant Center publishing is not an ordinary beta capability; it remains restricted to supervised validation. Approving a permitted change draws no credits, but the conversation that produced it does.
Controlled beta
Start read-only. Turn writes on only when you trust the evidence.
Apply with one active Google Ads account. Invited partners review the first recommendation before any write capability is considered.
- writes off until you switch them on, per account
- one card, one decision, no bulk approve
- every figure on this page: one demo account
Invited partners connect read-only first. Every exact platform change requires separate approval.
Receipts
- Write access is off on every new connection. While it is off, the agent's change tools are left out of the request sent to the model, so it is never handed them.
- Write access is granted per connected account and can be withdrawn without disconnecting the read. Arming one platform never arms another.
- Every product view and every figure on this page is the Gymszy sample account, labelled as demo data where it appears. Nothing here is presented as a customer result, because there are none to present yet.
- Warnings on a proposal are computed by our server and stored beside the model's reasoning rather than inside it, deliberately outside the schema the model writes into, so it can neither author them nor remove them.
- Google Ads is the ordinary controlled-beta connection, with bounded writes under exact approval and supervised validation. Meta is reviewer-only while app review completes. Merchant Center publishing is supervised-only. TikTok writes are unavailable. Shopify, GA4 and Search Console have no customer write path.
- A budget increase larger than 300% is blocked before a proposal is created. A change larger than 20% in either direction is shown as a warning on the card.
- A proposal older than 24 hours is refused at approve time and has to be asked for again against a fresh read.
- Every approved change executes exactly once and is verified by reading the platform back in the same request and comparing it, field by field, against what you approved. A mismatch is recorded as a failed verification, never as a success.
- The record stores that a change was approved, on which account, and which signed-in person pressed the button. Workspaces can include an Owner and Members, so each approval remains attributable to the person who made it.
- Compensation inside a failed Meta budget move is automatic. Eligible verified Google Ads receipts instead offer an undo that prepares another approval. It cannot recover spend or delivery effects, and uncertain platform writes are not automatically replayed.