Run one agent across several accounts

A key is bound to one workspace for its whole life. The workspace a request operates on is taken from the verified key and never from a tool argument, because nothing in the capability surface accepts a workspace to name. An identifier belonging to another workspace produces no row, so it produces no answer and no link — the boundary is the query itself rather than a check somebody remembered to write.

Inside one workspace, breadth is free. Several connections, several ad accounts under each, and a single question that covers all of them.

Across workspaces, nothing is shared. A new workspace starts empty: its own connections, its own drafts, its own plans, its own keys. That is deliberate, and it is the same boundary that keeps two clients' accounts apart when one person works on both.

So the architectural question is not "how do I let one agent see everything". It is "which accounts belong in the same room".

Two accounts belong in one workspace when you want to compare them, total them, or move money between them. They belong in separate workspaces when a person who can see one should not see the other.

The second test usually decides it. Agency work, a holding company with genuinely separate businesses, or anything where a client could reasonably ask who else has read their numbers — separate workspaces, every time. The cost is real but small: a key each, a configured entry each, and totals that you compute yourself rather than asking for.

The first test decides the rest. A founder running three brands that share a budget wants one workspace, because the question "which of the three earned the next thousand" is only answerable inside one.

One account belonging to several workspaces is fine and common. The switcher follows you, every query is scoped to the active workspace rather than to your account, and how many workspaces you may own is a plan entitlement.

The reading surface is where breadth pays.

Blended spend and results for the last thirty days, with the per-channel breakdown.

One call, every connected account, blended figures with each channel underneath. The structure reads work the same way: campaigns across every account, newest first, each row carrying the account it belongs to.

Two things to watch when the accounts are not alike.

Currency. Money is an integer in each account's own minor units. A scope covering one currency is exact and nothing is converted. A scope covering several is converted through published rates into whichever currency carries the most spend, labelled an estimate, and stamped with the date of the oldest rate it leaned on, so a stale leg cannot hide behind a fresh one. Where a rate is missing nothing is invented: the blended total is refused, and a list that cannot be ranked comparably comes back in raw order with that fact attached.

Time zone. Every result states the time zone its dates are in. Accounts in different zones disagree about where a day starts, and a week-over-week comparison that quietly straddles that boundary is a week-over-week comparison of two different weeks.

Reads fan out; writes do not, and the reason is worth understanding rather than working around.

A batch is the review unit and the apply unit, and a batch belongs to one connection. Work spanning two connections is two batches by construction. That is not a limitation bolted on afterwards — two connections can never be applied together, so a plan whose items land on two of them materialises into two batches, each keeping its items in board order.

What that means day to day: an instruction like "take ten per cent off the worst performer in each account" produces one batch per connection, each with its own link to the gate, rather than one act you approve once. Approving is per batch. The rows are claimed at approval and moved whole or not at all, and approving the same batch again picks up the rows not yet cleared rather than starting it over.

The arrangement underneath is the same whichever account is involved: your connections read your accounts, a change is written as a draft on the record with the state it would change from and the checks it passed, applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

One key per workspace per client, and name them after the workspace rather than after the product. Two entries both called tempio in a client's configuration is a mistake you make once.

Most clients take several servers at once, so the usual arrangement is one configured entry per workspace, each with its own key and its own name. The agent then has to be told which one to ask, which is a feature: an instruction that does not name a workspace is an instruction that should not run anywhere.

Scope them independently too. A key for the workspace you are actively managing may reasonably carry draft; a key for the workspace you only report on should carry read and nothing else. How to scope an MCP key is the longer argument.

And remember what kills a key: membership is re-read on every call, so a key stops answering the moment its creator leaves that workspace. Across five workspaces that is five integrations dying at once if they were all minted by the same departing person. Mint under an account that is not going anywhere and say so in the name.

Worth knowing when several clients live in one workspace.

Pausing a connection is the kill switch, and it is per connection. Syncing stops and every apply written against it is blocked — whatever is queued, whatever rule would otherwise have cleared it, whoever approves it afterwards — while every other connection carries on. Nothing is rejected: the drafts stay where they are, and setting the connection active again lets them run.

Approval rules name one connection or every connection in the workspace, so a rule can be as narrow as one client's accounts. Account defaults are per ad account and change as drafts like anything else.

Roles are per workspace, not per connection. A member of a workspace reads everything in it, which is the other reason the separation test above is about who should see what.

For the inventory of what a connected client can and cannot see in any of those workspaces, What an agent can reach in your account. For the questions worth asking once it is pointed at the right one, First prompts for your ad accounts.

What the scatter actually costs, and why it is not the tab-switching, is The cost of three dashboards.