Tempio
Request early access

Draft

Every change is a draft before it is a change

The gate is the point every change passes through on its way to an ad account: written as a draft, checked against your guardrails, applied only once something has cleared it. The record says what that something was.

Approved by you, by a rule you wrote, or by the stages you set. The row carries which of them it was, so nobody has to reconstruct from memory who cleared what, or when, or on whose authority.

Request early accessWhere a batch comes from

An agent with your account, or an agent with your gate

An agent wired straight to the account
  • A change happens the moment the model decides it should, and the first you hear of it is the spend.
  • Nothing holds the state the entity was in, so undoing the change means remembering what it used to say.
  • One credential does everything, so reading last week’s numbers and rewriting a budget are the same permission.
  • A limit is a line in a prompt, and the next conversation does not inherit it.
  • When something lands wrong, the log says a request was made. It does not say who decided, or on what.

A change you found out about.

An agent working through the gate
  • A change is written as a change request first, and the account is untouched while it sits there.
  • The row holds the current state and the proposed state, so reversing it is drafting the inverse rather than recalling a number.
  • Read, draft and approve are separate scopes on separate keys, and approve is opt-in at the moment a key is minted.
  • Guardrails belong to the workspace, not to the conversation, and they run on every draft whatever wrote it.
  • Every row names the authority that cleared it (you, a rule you wrote, or each stage you set), and the ledger keeps the rest.

A change you cleared, on a record that says so.

How a change reaches an account

  1. 01

    It is written as a draft

    Every write from the built-in agent, from the app and from your own agent over MCP lands as a change request: the operation, the entity it targets, the complete payload, and the account’s own currency stamped on the money. The account sees none of it while the row is waiting. Where the platform can dry-run a change first, what it answered is stored on the row beside the payload.

  2. 02

    It is checked, and then checked again

    Your guardrails run when the draft is written, so a change outside them never reaches the queue at all. They run a second time before it is applied, because a draft written this morning may be cleared this evening against an account that has moved underneath it. A batch is evaluated as one thing. If one entry is refused, nothing in it is applied, and a batch that stopped part way resumes from the rows that never landed.

  3. 03

    Something clears it, and the record says what

    Approval is an act with an author: you in the app, a key holding the approve scope, a rule your workspace wrote, or a client signing from a link you sent. The row keeps which of them it was, alongside the time and the outcome the platform returned. The built-in chat agent is never given that scope, so it can fill the queue all day and clear nothing in it.

What the gate holds

The before and the after

Every row carries the state the entity is in and the state the change would put it in. A review compares the two payloads themselves, so nobody has to take a summary of them on trust.

Three separate scopes

Read, draft and approve are separate permissions. A key without the approve scope is never offered the approve tools at all, which is a stronger guarantee than refusing the call after it arrives.

Guardrails that belong to the workspace

There are three: a daily cap derived from the account’s own busiest campaign-day over the last twenty-eight days, a limit on how far a single budget may move from what it says now, and a running twenty-four-hour total of the increases already applied on that connection. The same three hold whether the change came from the app, from the built-in chat or from your own agent. Your plan decides whether the workspace may raise or lower them per account, per connection or across the whole workspace; the twenty-four-hour rule and the kill switch stay ours and nothing moves those.

More than one signature, when you want one

Approved by you, by a rule you wrote, or by the stages you set: a second signature above the amount you choose, and every decision on the record with its author. A chain is stages you write once (any admin, then the people you name, then the client), matched on the connection, on the operation or on an amount, and copied onto the draft the moment it is written, so editing the rule never rewrites a decision already in flight. Separation of duties is a switch beside the chain; when it is on, whoever drafted a change cannot clear it.

Sign-off from someone with no seat

A client signs a change off from a link with no seat and no login: the diff, the amount and the deadline, and one decision that satisfies its stage. The link carries the batch, the money in the account’s own currency and the date it expires. It opens nothing else in the workspace, it answers once, and the name typed into it lands on the record beside the time.

Batches move whole

A batch is reviewed once and applied once. A rejection is terminal and takes the batch with it rather than leaving half the rows applied and half waiting for somebody to notice.

Undo is a draft as well

Reversing something that already landed drafts its inverse at the same gate, never an automatic rollback. Every write is a complete replacement, so restoring a budget, a name or a schedule is exact rather than approximate.

Everything on the ledger

Every draft, approval, rejection and connection action lands on the ledger, scoped to your organisation. The numbers those changes move are kept under the same discipline: counts stored, ratios computed when you read them.

How the numbers are kept

Your own agent, the same gate

A change drafted from your own client is the same change request as one drafted in the app, held at the same gate, under a key whose scopes you chose when you minted it.

Point your own agent at it

Illustrative exchange

Take the daily budget up fifteen percent on the two campaigns that beat their cost per acquisition last week.
draft_changes
Drafting both budget changes as one batch.
2 operations · correlationId 3f9d41c6-0a77-4e1b-9d52-6c8ab0f4e215 · approvedBy pending · reviewUrl /drafts?batch=3f9d41c6-0a77-4e1b-9d52-6c8ab0f4e215
I’ve written two drafts, one per campaign, as a single batch. Each carries the daily budget the campaign holds now and the one I am proposing, in the account’s own currency. Neither has been sent anywhere. The batch awaits approval, and nothing in it can be applied on its own.
What did the guardrails say about them?
list_drafts
Reading the batch back in the order it would apply.
2 rows · status pending_approval · approverKind null · validation ok
Both rows passed the guardrails when they were written: the account’s own daily cap, the limit on how far one budget may move, and the twenty-four-hour total of increases already applied on that connection. I should add that they are checked against all three again at the gate, because an account can move underneath a draft that is waiting.
Approve the batch.
I can’t, and that is deliberate. The key I am holding carries read and draft and not approve, so the tools that clear anything are not in my list to call. The review link on the batch opens both payloads in the app, and approving them there puts you on the record as the authority that cleared them. Applying a cleared change to a live ad account is in private beta.

Questions

Put frontier AI to work on every ad account you run.

Connect your accounts, point your own AI at them over MCP, and read the numbers and draft the work in one place. Every change is a draft until you approve it, or until a rule you wrote does.

Request early access
  • Read and draft by default. Approve is a separate permission you grant.