How do you run paid ads with an AI agent?

Classic API scripts keep 3 or more ad-platform tokens in a .env file; the MCP-first approach keeps zero credentials, authenticating over OAuth through MCP.

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.

How do you run paid ads with an AI agent?

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.

Why MCP-first instead of API scripts?

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.

AspectClassic (API scripts)MCP-first
Data consumptionCSV exports or an SDK per platformSQL through the data platform's MCP
Ad operationsScripts with .env tokensMCP gateway over OAuth
Credentials in the repoSeveral platform tokensNone
Switching productReconfigure everythingSwap 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.

What does the agent actually do?

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.

What context does the agent need?

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.

  • The agent. One file defines the assistant's operating rules and judgment, the personality and the guardrails it works within.
  • The skills. Twelve modules, each one a lesson that cost real ad budget to learn: fetching data over MCP, the metrics foundation, publishing through the gateway, safe creative testing, measuring the right metric, attribution, copy rules, creative fatigue, ICP discovery, positioning, product context, and search-term pruning. A skill is how a hard-won rule becomes reusable instead of re-explained.
  • The knowledge. One folder holds the context of your product: who it is for, how it is positioned, what a good lead looks like. The starter ships with a fictional company so you can see the shape, then you replace it with your own.

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.

How do you give the agent memory?

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.

What data foundation does it need?

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.

  • Stored history, for analysis. Ad platform APIs cut off the past (some windows are around 90 days), so a source that extracts and stores the data keeps the history the platforms throw away. Trends, cohorts and quarter-over-quarter all depend on it.
  • Live data, for state and operation. To read the current status of a campaign or to act on it, the agent reads live and writes through the gateway.
  • A consolidated model. A transformation joins spend from Google, Meta and LinkedIn with deals from the CRM into one table, so cost per customer is a single query instead of a manual join across four exports.
  • A semantic layer. Each metric is defined once: what a conversion is, which cost figure to divide, that a currency stored in millionths (one unit is 1,000,000) is converted before any cost metric. Define it once and every report agrees.

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.

What are the lessons baked in?

The skills encode rules that are cheap to read and were expensive to learn. Five carry most of the weight.

  • Concentrate creative tests, do not scatter them. One broad ad set with a few variants teaches you something; one ad set per video starves delivery and teaches nothing. Example: in one round, an elaborate creative ran at a high CPA with zero activations while a plain pain-point copy ran cheaper and drove activations, and a simpler headline cut CPA by roughly a third. These are example figures that show the pattern, not an audited benchmark.
  • Measure cost per meeting or sale, not cheap form fills. A lead from a personal email is cheap and often worthless; optimizing for it buys volume that never converts.
  • Attribute by UTM and the closed deal, never the CRM's origin field. The inferred source undercounts paid, the same correction detailed in why your CRM under-reports paid leads.
  • Do not rebuild the account for every question. A consolidated table plus a semantic layer beats ad-hoc SQL written from scratch each time.
  • Do not judge a creative without delivery. A creative with few impressions is "no data yet," not "bad." Killing it early throws away the test.

How does Nekt do this?

Nekt is a data platform that gives AI agents governed context, and running ads is the case where that context also acts.

  • Connect. Google, Meta, LinkedIn and the CRM land in one place through ready-made connectors, each refreshing on its own, with the history stored rather than expired.
  • Govern. The raw data is cleaned and modeled into consolidated tables, with each metric defined once and business meaning annotated per column, so cost per customer means the same thing everywhere.
  • Serve. Agents read the result as SQL over an MCP server, and operate the platforms through an MCP gateway over OAuth. The connection that reads attribution is the connection that creates, pauses and adjusts campaigns, with no write credential built by hand into each platform.

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.

Frequently asked questions

Do I need API credentials to run ads with an AI agent?

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.

Can an agent create and pause campaigns, or only read?

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.

How does the agent avoid spending money by mistake?

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.

  • You run paid ads with an AI agent by reading performance as SQL over MCP and operating the platforms through an MCP gateway over OAuth, with zero ad-platform credentials in the code.
  • The turn from classic API scripts is the credential: a .env token per platform becomes none, which removes approvals, expiry, rate limits and leak risk.
  • The agent operates Google, Meta and LinkedIn (create, pause, budget, keywords, creative), and every write waits for human approval, with tests uploaded paused.
  • It needs a data foundation: stored history for analysis (ad APIs expire the past), live data for state and operation, a consolidated table, and a semantic layer that defines each metric once.
  • The craft is encoded as skills and memory: concentrate creative tests, measure cost per meeting not form fills, attribute by UTM and deal, and never judge a creative without delivery.

More insights