
You run paid ads with an AI agent by connecting it to a governed data layer over MCP, so it reads performance with SQL and operates Google, Meta and LinkedIn through an MCP gateway, with human approval and zero ad-platform credentials in the code. The same governed layer that measures attribution is the one that acts, which is why the agent can create, pause and adjust campaigns without a single stored token. This guide walks through the architecture, the data foundation, and the lessons baked into an open-source starter.
You connect the agent to a governed data layer over MCP, let it read performance with SQL, and let it operate the ad platforms through an MCP gateway, every write gated by human approval, with zero ad-platform credentials in the code. That last part is the turn. The classic way to automate ads stored a Google, Meta and LinkedIn token in a .env file, each with its own approval, expiry and rate limit to babysit. The MCP-first way stores none: authentication is OAuth, handled by the protocol, and the credential never touches the repo. The same governed layer that measures attribution is the one that acts, so the agent that tells you a channel is underperforming is the agent that can pause it.
The agent manages campaigns across Google, Meta and LinkedIn with zero API tokens in the repo. Auth is OAuth through MCP, so there are no platform credentials to store, expire or leak.
This is not a thought experiment. It is the design of an open-source starter, workshop-ads-agent-starter-mcp (MIT, nektcom), that anyone can fork and point at their own product. The rest of this guide is how it is built and why each choice is made.
Because the credential is the real maintenance cost, and MCP-first removes it. An API-script setup consumes data through CSV exports or a per-platform SDK, operates ads through scripts that read tokens from a .env, and keeps several platform credentials in the repo. Each token is a small liability: it expires, the platform changes an approval rule, an API version is deprecated, and the automation that worked last month breaks this month. The MCP-first approach reads data as SQL through a data platform's MCP and operates ads through an MCP gateway over OAuth, so the number of credentials in the code is zero.
| Aspect | Classic (API scripts) | MCP-first |
|---|---|---|
| Data consumption | CSV exports or an SDK per platform | SQL through the data platform's MCP |
| Ad operations | Scripts with .env tokens | MCP gateway over OAuth |
| Credentials in the repo | Several platform tokens | None |
| Switching product | Reconfigure everything | Swap one knowledge folder |
The side benefit is portability. Because the product-specific context lives in one folder and the credentials live nowhere, the same agent works for any company by swapping that folder. The hard, recurring integration work is carried once, underneath, by the data platform.
It reads and understands performance, then operates the platforms, and every change waits for a human yes. On the read side it answers the questions a growth or RevOps lead actually asks: what each channel cost per customer, which creative is fatiguing, which search terms are wasting spend. On the write side it creates campaigns, pauses what is not converting, moves budget toward what wins, adds negative keywords, and ships creative and copy. Today it operates Google, Meta and LinkedIn through the gateway.
Two safety rules frame every write. The agent proposes a change and waits for explicit approval before executing, and it uploads tests in a paused state, so a person reviews the creative and copy before anything goes live. It is operating real money, and the responsibility for what launches stays with the human. Copy respects each platform's limits, which the agent knows (as of today, roughly 30 characters for a Google headline, 40 for Meta, 70 for LinkedIn, though platforms change these), so a draft does not get truncated on publish.
Three layers: who the agent is, what it knows how to do, and what it knows about your product. In the starter these are concrete files.
Splitting these is what makes the agent portable and honest. The skills are general craft; the knowledge is specific to you; the agent binds them. Writing a product rule into the knowledge folder, instead of a prompt, is the same discipline as context engineering for AI agents: the rule lives in one place and applies everywhere.
With a weekly loop and a written record of experiments, so it does not relearn the same lesson twice. Paid media is a sequence of tests, and the expensive mistake is running an experiment that already failed because nobody wrote down that it failed. The agent keeps a record of what was tried, what it cost, and what happened, and reads it before proposing the next test. That record is memory in the most literal sense: the difference between a team that compounds what it learns and one that restarts every Monday.
The loop mirrors how a disciplined operator works: review what shipped and what it earned, decide the next test from evidence rather than instinct, launch it paused for approval, and log the result back. Each pass is a little sharper than the last because the layer underneath remembers.
Two modes of data, one consolidated model, and a semantic layer on top. The agent needs both a durable history and a live view, and they come from different places.
Without that foundation, the agent reinvents the account at every question, and the numbers drift between runs, the failure described in why AI agents give different answers on the same data.
The skills encode rules that are cheap to read and were expensive to learn. Five carry most of the weight.
Nekt is a data platform that gives AI agents governed context, and running ads is the case where that context also acts.
The payoff is a loop instead of a report: the layer that measures a channel honestly is the layer that acts on it, and no part of that requires a token in a file.
No. In the MCP-first design, authentication is OAuth handled by the protocol, so there are no Google, Meta or LinkedIn tokens stored in the repo. That removes the usual maintenance of approvals, expiring tokens and rate limits, and removes the risk of a credential leaking from the code.
It operates. Through the MCP gateway the agent can create campaigns, pause what is not converting, move budget, manage negative keywords, and ship creative and copy, across Google, Meta and LinkedIn. Reading performance is the other half; the point of the design is that the same layer does both.
Every write waits for explicit human approval, and tests are uploaded in a paused state so a person reviews the creative and copy before go-live. The agent proposes; the human decides what launches. It is operating real budget, and that boundary is deliberate.