Teams keep evaluating models when they should be evaluating deployments. A frontier model that can reason brilliantly about an ad account still cannot operate one without four things around it: persistent context, permissioned tools, an approval gate, and a record. Get those right and the model becomes swappable, which is exactly what you want.
The gap between a demo and a deployment
Paste a performance export into a chat window and the analysis that comes back is often better than the one in last quarter's deck. That demo convinces a lot of teams they are three weeks from an autonomous account. They are not, and the reason has nothing to do with the model.
A demo answers a question. A deployment carries responsibility: it has to know the account's history without being retold, act on real budgets under real limits, pass through a named approver, and leave behind a record someone can audit in November. Every one of those is infrastructure, and none of them arrive with the model. If you want the honest version of what a chat interface can and cannot do here, we wrote it up in the MCP assessment.
The four layers of a real deployment
Context
The model needs your account's history, guardrails, and business reality, not a prompt written from scratch every session. Without a persistent context layer, every run starts from zero and the quality of the output tracks the quality of whoever typed the question.
Tools
Reading a report is not operating an account. A deployment needs typed, permissioned write access to the ad platforms, with each action validated before it is proposed.
Approval
Every proposed change lands in a queue with its evidence attached and a named human on the other side. This is the difference between an assistant and an operator you can defend in a QBR.
Record
What was proposed, what was approved, what shipped, what happened after. The audit trail is the only artifact that makes an agent deployment reviewable months later.
Notice that only one of the four is about intelligence. That is the point: once the other three exist, the model becomes a component you can upgrade, which is why we built Adlyse to be model-agnostic from the start.
Where Claude fits, and where it doesn't
Strong reasoning models earn their cost on judgment-heavy steps and waste it on volume work. A sane deployment routes per step:
| Task | Verdict | Why |
|---|---|---|
| Long-context reasoning over an account's history | Strong fit | Synthesis quality holds up across large evidence sets |
| Drafting change proposals with written rationale | Strong fit | The reasoning is the deliverable; the change is the easy part |
| High-volume classification of search terms or placements | Poor fit on cost | Route to a smaller, cheaper model; save the reasoning budget for decisions |
| Numeric optimization: bid math, pacing curves | Wrong tool | Deterministic code, not a language model, and it should sit outside the model entirely |
The last row is the one teams get wrong most often. Bid math and pacing are deterministic problems with correct answers; handing them to a language model adds variance and removes auditability, and it should sit in code where you can test it.
Three workflows worth deploying first
Start where the reasoning is valuable and the blast radius is small:
"Compare yesterday against the trailing 14-day baseline for every account over $5k/day. For each anomaly, tell me the most likely cause with the evidence, and propose one change with its expected dollar impact."
"Find spend with no conversions across the last 30 days that isn't part of an active test. Propose exclusions, and flag anything that looks like a tracking problem rather than a performance problem."
"Before I approve this budget shift, argue the other side: what would have to be true for this to be the wrong move?"
All three produce proposals, not changes. That is deliberate: the first month of any deployment should be spent grading judgment, which is also how the first 90 days should be sequenced.
The pre-production checklist
| Control | Why it matters |
|---|---|
| Spend caps live outside the model | Hard limits enforced in code, never in a prompt, because a prompt is a suggestion and a cap is a contract |
| Every write action is approved | No silent execution paths, no "low-risk" exemption that quietly grows |
| Prompt injection surfaces are scoped | Ad copy, landing pages, and competitor text are untrusted input, never instructions |
| Rollback is one action | If a change is wrong, undoing it should not require reconstructing what happened |
| The trail is exportable | Clients and finance will eventually ask; the answer should take minutes, not a week |
If you cannot check all five, you do not have a deployment, you have an experiment with production credentials. The failure modes are catalogued in our honest risk guide.
FAQ
Skip the scaffolding. Adlyse ships the context, tools, approval gate, and audit trail already wired.
Start a free audit
