The hard part of marketing engineering starts after the demo

The scheduled run is the real test

Consider an illustrative workflow, not a customer incident. A scheduled campaign review reads yesterday's performance, proposes a budget reduction and sends it for approval. The change is approved. The platform accepts it, but the response times out. The next run sees an unfinished task. Should it try again?

This is where I would start judging the system. Not by the quality of its explanation, but by whether it knows the difference between a failed request and an unknown result. A dependable marketing engineering runbook must define what happens next without asking a model to improvise the policy.

Execution status and business outcome are separate questions. Did the budget change happen? Did that change help the business? The first needs confirmation from the platform. The second needs time, evidence and marketing judgement. Neither is answered by a green tick in the assistant.

End-to-end includes the unattended parts

In his Zero Click New York 26 deck, Nick Lafferty describes a marketing engineer as someone who ‘ships full systems end-to-end’. His emphasis on taste and experience matters too. The judgement is not only in what gets built. It is in deciding when the system should stop.

Profound's introduction to The Marketing Engineer Podcast focuses on production systems: what people built, where those systems broke and what they would do differently. That is the useful conversation after the demo.

Our earlier article on what marketing agents need beyond internet access covers context and permission. I want to go further here: assume the connections and boundaries exist. What operating contract makes the same campaign-review workflow dependable when nobody is watching every step?

Give every run a contract before giving it a schedule

I would write a short contract for this workflow: which workspace and campaigns it covers, when it runs, which evidence it requires, who approves changes and who owns an exception. Include the account currency, reporting timezone, maximum permitted change and conditions that prohibit action.

Define the states explicitly: reading, draft ready, awaiting approval, submitted, confirmed, unresolved and awaiting outcome review. A timeout after submission belongs in unresolved, not automatically in failed. Each state needs a next action and an owner.

Prevent overlapping runs from submitting the same proposal. If yesterday's action is unresolved, today's review can still read data, but it should not silently replace or repeat that action. A schedule is permission to begin a review, not permission to manufacture a fresh decision.

The exception path holds an uncertain write for inspection and reconciliation. This is a recommended runbook pattern, not a claim of universal automatic recovery.

Freshness is a condition for action, not a dashboard label

Record when the workflow fetched each source and the latest period that source actually covers. Those are different timestamps. A successful request can return data that stopped updating days ago. Also distinguish connection freshness from conversion completeness: current spend does not mean yesterday's revenue has finished arriving.

Set a freshness requirement for the particular decision. If Meta is current but the revenue source is stale, the review should explain the missing evidence and withhold a revenue-based budget recommendation. Do not quietly substitute platform-reported returns for the agreed business measure.

The third i MCP documentation provides a concrete product example: it documents connection health that flags stale platform data and links to reconnection. That is a useful input to an operating rule, not proof that every decision made with fresh data is sound.

Approval belongs to an exact proposed change

For this workflow, read means inspect performance and account state. Draft means prepare a proposed change without altering the account. Write means submit the specific approved change. Keep those boundaries in the tools and permissions, not just in an instruction asking the assistant to behave.

The approval record should identify the workspace, platform, campaign, existing budget, proposed budget, currency, rationale and evidence snapshot. Give it an expiry. If the payload changes, the approval expires. If the evidence becomes stale or the live budget no longer matches the approved starting value, stop and request review.

third i publicly documents budget shifts, pauses and similar Google Ads and Meta Ads changes prepared through an assistant or agent, approved in third i, then applied. That is documented product scope, not an independent execution test. The additional contract I am proposing here should not be read as a claim that every control is already shipped.

Do not turn uncertainty into a second write

Return to the timeout. Preserve the approved proposal and its unique operation identifier. Where the receiving API supports idempotency, use the same key for the same operation under that API's rules. Generating a new key on every retry defeats the protection. A local identifier alone cannot make an external write idempotent.

Before retrying an uncertain write, reconcile it. Look up the platform operation if possible, read the campaign's current state and inspect available change history. A matching budget is evidence of current state, but may not prove which actor changed it. Another person could have edited the campaign.

If the evidence cannot establish what happened, keep the action unresolved and assign a person to investigate. Do not blindly retry, and do not automatically reverse a change you have not confirmed. Recovery is a decision with consequences too.

Keep a record someone else can reconstruct

The audit record should connect the run, source timestamps, evidence, proposal version, approver, approval time, submitted payload and platform response. Record the reconciliation checks and final observed state. Keep secrets out of those logs and restrict access to account information.

A transcript alone is not enough. Someone covering the account should be able to answer what was authorised, what was attempted, what is confirmed and what remains unknown without reading a long conversation.

The third i trust page describes platform credentials staying inside third i rather than reaching the AI vendor. Credential isolation is important. It does not establish that a model's diagnosis is correct or that an uncertain action has been reconciled. Those need separate checks.

Close the execution record, then open the outcome review

Once the platform confirms the budget, mark execution confirmed. Leave the business outcome pending. Before acting, define the review window around the conversion lag and business cycle, the measure that matters and the conditions for intervening early.

At review, compare the result with the original hypothesis. Record other changes, including promotions, tracking repairs and sales follow-up. A lower acquisition cost after a budget reduction is not automatically evidence that the reduction caused it. Decide whether to continue, revise or reverse through a new approved proposal.

Pilot the exceptions, not just the happy path

Start with one account, one scheduled review, one permitted change type and a named owner. Run in draft-only mode first. Rehearse stale data, changed payloads, expired approvals and an accepted write whose response never arrives. Agree on who handles unresolved actions before enabling live writes.

My test would be simple: can another operator pick up an interrupted run and know what to do? If not, improve the runbook before expanding the schedule. If you want to work through that contract against your own marketing workflow, talk to the third i team. Bring one recurring decision and its awkward exceptions. That is enough for a useful starting point.