Plans

A media plan is a working document. It holds a window, a budget per line, and the campaigns you intend to run inside it — and nothing in it touches live spend. That is what makes it the right place to argue about a quarter: you can move a flight, halve a budget or delete a line without any of it being a change to an ad account.

When the shape is right, you materialize the plan. Each item becomes a create-campaign draft at the gate, and the plan freezes as the record of what was drafted.

The rest of the planner

A plan is one document. The planner around it is the workspace's operating calendar, and these five pages cover it:

• Timeline — every live campaign and every planned flight on one axis, grouped by ad account, where dragging a bar writes a change request rather than moving anything.
• Pacing — what a target was planned to spend each day, what it actually spent, and the five words Tempio uses for the difference.
• Phases and envelopes — a ceiling per campaign and the dated windows that scale it, so budget follows whichever campaign is in its hot window.
• The allocator — the daily pass that turns those two numbers into budget moves, drafted under your caps and cleared by you or by a rule you wrote.
• Scenarios — variants of one plan compared on one axis, with the totals each adds up to, and a promote that archives the rest.

The three plan pages

Reading a plan needs nothing more than workspace membership. A plan does not need a connected ad account to exist either — an unconnected workspace can still plan a quarter — though materializing one does, because that is the step that needs somewhere to put the campaigns.

What a plan holds

A name and a brief. The brief is prose: what the flight is for, who it is aimed at, what counts as working. Nothing parses it. It is there so the plan still makes sense to the person who did not write it, and so the agent has the intent in front of it when you ask for help with the items.

A window. A start and an end, as calendar days. Every item's flight has to sit inside it, in both directions — narrowing a plan's window under an item that no longer fits is refused, with the item named, rather than silently stranding it.

One currency. A plan carries a single currency and every budget in it is in that currency's minor units, so the total at the top of the page is a real number rather than a sum of unlike things. The picker offers the currencies your connected accounts actually bill in.

What an item holds

One item is one campaign you intend to run.

The budget being a whole-flight total rather than a daily rate is the one field people get wrong. A plan is a statement about a flight — "sixty thousand across March" — and the daily figure the platform wants is derived from it at materialization, over the inclusive length of the flight. Stating the daily number here would make the plan's total a thing you have to work out.

Materializing

Materialize is the one place a plan crosses into spend, and it is validate-everything-then-write: accounts, currency and guardrails are all settled before the first draft exists. A plan half-materialized — items 1 to 3 queued for approval and item 4 refused — is exactly what this refuses to produce.

In order, it:

1. Re-reads the plan and its items. Not the rows it was shown a minute ago: a concurrent edit narrowing the window must not sneak an out-of-window flight into a draft.
2. Checks each item. Its flight sits inside the plan's window, its budget is a whole number of minor units at or above zero, and its dates run forwards.
3. Resolves an ad account for every item. An account named on the item wins. Otherwise, if the workspace has exactly one account on that item's platform, that is the answer. Zero accounts, several, or an account that has since gone or no longer matches the platform, and the item is unresolved. Every unresolved item is collected and named in one message, so you fix them together rather than one refusal at a time.
4. Checks the currency. The resolved account must bill in the plan's currency. Money never silently crosses currencies here: the refusal names the account and what it bills in, and the remedy is to point the item at an account in the plan's currency or to plan that window in the account's.
5. Runs the guardrails. The connection's kill switch and the account's budget guardrails, using the same functions the gate itself runs, so the pre-flight and the gate cannot disagree. Guardrails has the checks.
6. Writes the drafts. One create_campaign change request per item, in board order.

A failure at any of those steps drafts nothing at all.

What comes out

Each item's whole-flight budget becomes a daily budget on the draft — the total divided by the inclusive length of the flight — and the flight days become instants in the ad account's own timezone, with the stop exclusive. The plan's currency is stated on the payload, and the gate re-stamps it from the account regardless.

The drafts are grouped into one batch per connection. A batch is the review unit and the apply unit, and two connections can never be applied together, so a plan whose items land on two connections becomes two batches. Inside a batch the items keep their board order.

A create is one of the operations no approval rule may ever clear, so for a materialized plan the approval is always a person's. Nothing runs and nothing spends until that happens. Every create also lands paused or disabled on the platform, so approving the batch builds the structure without spending; going live is a second change through the same gate.

After it

A materialized plan is frozen. Its name, brief, window, currency and items stop being editable, because the plan is now the record of what was drafted and editing behind that record would make the record a lie. The only thing still allowed is archive, which is how a plan is retired.

The details pane's buttons change with it: while the plan is a draft it offers Materialize, and once it is materialized it offers View drafts, which points at Drafts, where the decisions now are.

Over MCP

The planner is on the same surface as everything else — eight routes, under plan and plan_item.

Editing a plan needs the draft scope even though a plan is not a draft: it is the scope that covers everything which can become one. Materializing needs draft too, and not approve, because what it produces is change requests waiting at the gate. The MCP reference has the calling convention, and MCP keys has the scopes.

The agent works the same way round: ask it for a plan and it creates the plan, adds an item per campaign with its flight and its whole-flight budget, and leaves it for you to shape. Materializing is a separate ask.

The record

Every write here lands an audit row — created, updated, item added, item removed, materialized — with the actor that made it. Ungated is not unrecorded: a plan is free to edit precisely because nothing in it spends, and the log still says who shaped it and when. When a plan is materialized, the drafts it produced carry their own record from there.