Como você opera mídia paga com um agente de IA?

Como você opera mídia paga com um agente de IA?

Você conecta o agente a uma camada de dados governada via MCP, deixa ele ler o desempenho em SQL, e deixa ele operar as plataformas de anúncio por um gateway MCP, com cada escrita travada por aprovação humana, e zero credencial de plataforma de anúncio no código. Essa última parte é a virada. O jeito clássico de automatizar anúncios guardava um token de Google, Meta e LinkedIn num arquivo .env, cada um com a própria aprovação, expiração e rate limit para cuidar. O jeito MCP-first não guarda nenhum: a autenticação é OAuth, tratada pelo protocolo, e a credencial nunca toca o repositório. A mesma camada governada que mede a atribuição é a que age, então o agente que te diz que um canal está indo mal é o agente que consegue pausá-lo.

O agente gerencia campanhas em Google, Meta e LinkedIn com zero token de API no repositório. A autenticação é OAuth via MCP, então não há credencial de plataforma para guardar, expirar ou vazar.

Isso não é um exercício teórico. É o design de um starter open-source, workshop-ads-agent-starter-mcp (MIT, nektcom), que qualquer pessoa pode clonar e apontar para o próprio produto. O resto deste guia é como ele é construído e por que cada escolha é feita.

Por que MCP-first em vez de scripts de API?

Porque a credencial é o verdadeiro custo de manutenção, e o MCP-first a elimina. Um setup de script de API consome dado por exports de CSV ou um SDK por plataforma, opera anúncios por scripts que leem tokens de um .env, e mantém várias credenciais de plataforma no repositório. Cada token é um pequeno passivo: expira, a plataforma muda uma regra de aprovação, uma versão de API é descontinuada, e a automação que funcionava mês passado quebra esse mês. A abordagem MCP-first lê o dado em SQL pelo MCP de uma plataforma de dados e opera anúncios por um gateway MCP com OAuth, então o número de credenciais no código é zero.

O benefício paralelo é portabilidade. Como o contexto específico do produto vive numa pasta só e as credenciais não vivem em lugar nenhum, o mesmo agente serve qualquer empresa trocando essa pasta. O trabalho difícil e recorrente de integração é carregado uma vez, por baixo, pela plataforma de dados.

O que o agente faz de fato?

Ele lê e entende o desempenho, depois opera as plataformas, e cada mudança espera um sim humano. No lado da leitura, ele responde as perguntas que uma pessoa de Growth ou RevOps realmente faz: quanto cada canal custou por cliente, qual criativo está fatigando, quais termos de busca estão desperdiçando investimento. No lado da escrita, ele cria campanhas, pausa o que não converte, move budget para o que ganha, adiciona palavras-chave negativas, e sobe criativo e copy. Hoje ele opera Google, Meta e LinkedIn pelo gateway.

Duas regras de segurança enquadram cada escrita. O agente propõe uma mudança e espera aprovação explícita antes de executar, e sobe testes em estado pausado, para uma pessoa revisar o criativo e a copy antes de qualquer coisa ir ao ar. Ele está operando dinheiro de verdade, e a responsabilidade pelo que sobe fica com o humano. A copy respeita os limites de cada plataforma, que o agente conhece (hoje, cerca de 30 caracteres para um título do Google, 40 para o Meta, 70 para o LinkedIn, embora as plataformas mudem isso), para um rascunho não ser cortado na publicação.

De que contexto o agente precisa?

Três camadas: quem o agente é, o que ele sabe fazer, e o que ele sabe sobre o seu produto. No starter, essas são arquivos concretos.

• O agente. Um arquivo define as regras de operação e o julgamento do assistente, a personalidade e os limites dentro dos quais ele trabalha.
• As skills. Doze módulos, cada um uma lição que custou budget de anúncio de verdade para aprender: buscar dado via MCP, a fundação de métricas, publicar pelo gateway, teste seguro de criativo, medir a métrica certa, atribuição, regras de copy, fadiga de criativo, descoberta de ICP, posicionamento, contexto de produto e poda de termos de busca. Uma skill é como uma regra conquistada a duras penas vira reutilizável em vez de reexplicada.
• O knowledge. Uma pasta guarda o contexto do seu produto: para quem ele é, como está posicionado, como é um bom lead. O starter vem com uma empresa fictícia para você ver o formato, depois você substitui pela sua.

Separar isso é o que torna o agente portátil e honesto. As skills são ofício geral; o knowledge é específico seu; o agente une os dois. Escrever uma regra do produto no knowledge, em vez de num prompt, é a mesma disciplina de context engineering para agentes de IA: a regra vive num lugar só e vale em todo lugar.

Como você dá memória ao agente?

Com um loop semanal e um registro escrito dos experimentos, para ele não reaprender a mesma lição duas vezes. Mídia paga é uma sequência de testes, e o erro caro é rodar um experimento que já falhou porque ninguém anotou que falhou. O agente mantém um registro do que foi testado, do que custou, e do que aconteceu, e lê isso antes de propor o próximo teste. Esse registro é memória no sentido mais literal: a diferença entre um time que acumula o que aprende e um que recomeça toda segunda.

O loop espelha como um operador disciplinado trabalha: revisar o que subiu e o que rendeu, decidir o próximo teste por evidência em vez de instinto, subir pausado para aprovação, e registrar o resultado de volta. Cada volta fica um pouco mais afiada que a anterior porque a camada por baixo lembra.

De que fundação de dados ele precisa?

Dois modos de dado, um modelo consolidado, e uma camada semântica em cima. O agente precisa tanto de um histórico durável quanto de uma visão ao vivo, e eles vêm de lugares diferentes.

• Histórico guardado, para análise. As APIs das plataformas de anúncio cortam o passado (algumas janelas são de cerca de 90 dias), então uma source que extrai e guarda o dado mantém o histórico que as plataformas jogam fora. Tendências, cohorts e trimestre a trimestre dependem disso.
• Dados ao vivo, para estado e operação. Para ler o status atual de uma campanha ou agir sobre ela, o agente lê ao vivo e escreve pelo gateway.
• Um modelo consolidado. Uma transformação junta o gasto de Google, Meta e LinkedIn com os deals do CRM numa tabela só, para o custo por cliente ser uma consulta única em vez de um cruzamento manual entre quatro exports.
• Uma camada semântica. Cada métrica é definida uma vez: o que é uma conversão, qual número de custo dividir, que uma moeda guardada em milionésimos (uma unidade é 1.000.000) é convertida antes de qualquer métrica de custo. Defina uma vez e todo relatório concorda.

Sem essa fundação, o agente reinventa a conta a cada pergunta, e os números variam entre execuções, a falha descrita em por que agentes de IA dão respostas diferentes para o mesmo dado.

Quais são as lições embutidas?

As skills codificam regras que são baratas de ler e foram caras de aprender. Cinco carregam a maior parte do peso.

• Concentre os testes de criativo, não espalhe. Um conjunto amplo com poucas variações te ensina algo; um conjunto por vídeo estrangula a entrega e não ensina nada. Exemplo: numa rodada, um criativo elaborado rodou com CPA alto e zero ativação enquanto uma copy de dor simples rodou mais barata e trouxe ativações, e um título mais simples cortou o CPA em cerca de um terço. Esses são números de exemplo que mostram o padrão, não um benchmark auditado.
• Meça custo por reunião ou venda, não form fill barato. Um lead de email pessoal é barato e muitas vezes inútil; otimizar por ele compra volume que nunca converte.
• Atribua por UTM e pelo deal fechado, nunca pelo campo de origem do CRM. A origem inferida subconta o pago, a mesma correção detalhada em por que o seu CRM reporta menos leads pagos.
• Não reconstrua a conta a cada pergunta. Uma tabela consolidada mais uma camada semântica ganha de SQL ad-hoc escrito do zero toda vez.
• Não julgue um criativo sem entrega. Um criativo com poucas impressões é "sem dado ainda", não "ruim". Matá-lo cedo joga o teste fora.

Como a Nekt faz isso?

A Nekt é uma plataforma de dados que dá contexto governado para agentes de IA, e operar anúncios é o caso em que esse contexto também age.

• Conectar. Google, Meta, LinkedIn e o CRM caem num lugar só por conectores prontos, cada um se atualizando sozinho, com o histórico guardado em vez de expirado.
• Governar. O dado bruto é limpo e modelado em tabelas consolidadas, com cada métrica definida uma vez e o significado de negócio anotado por coluna, para custo por cliente significar a mesma coisa em todo lugar.
• Servir. Os agentes leem o resultado em SQL por um servidor MCP, e operam as plataformas por um gateway MCP com OAuth. A conexão que lê a atribuição é a conexão que cria, pausa e ajusta campanhas, sem credencial de escrita construída à mão em cada plataforma.

O ganho é um loop em vez de um relatório: a camada que mede um canal com honestidade é a camada que age sobre ele, e nada disso exige um token num arquivo.

Perguntas frequentes

Preciso de credenciais de API para operar anúncios com um agente de IA?

Não. No design MCP-first, a autenticação é OAuth tratada pelo protocolo, então não há tokens de Google, Meta ou LinkedIn guardados no repositório. Isso tira a manutenção usual de aprovações, tokens que expiram e rate limits, e tira o risco de uma credencial vazar do código.

Um agente consegue criar e pausar campanhas, ou só ler?

Ele opera. Pelo gateway MCP o agente consegue criar campanhas, pausar o que não converte, mover budget, gerenciar palavras-chave negativas, e subir criativo e copy, em Google, Meta e LinkedIn. Ler o desempenho é a outra metade; o ponto do design é que a mesma camada faz as duas coisas.

Como o agente evita gastar dinheiro por engano?

Cada escrita espera aprovação humana explícita, e os testes sobem em estado pausado para uma pessoa revisar o criativo e a copy antes de ir ao ar. O agente propõe; o humano decide o que sobe. Ele está operando budget de verdade, e essa fronteira é proposital.