Agente de IA para agência de marketing: como aplicar na operação

Quando um sócio de agência de marketing me pede um agente de IA para agência de marketing, eu começo pela operação multi-cliente, não pela demo de “IA que cria posts”. Se no fim do turno não há entrega aprovada para o cliente ou status/ID no sistema de registro da agência (card no Notion/ClickUp/Asana, asset na pasta do cliente no Drive/DAM, linha de retainer/horas, checklist de entrega), a peça não trabalhou: só abriu um chat. Percebi que a SERP mistura geradores de criativo, chatbots de FAQ e o mapa do marketing in-house, enquanto a mesa real ainda cola rascunho no Docs do cliente errado e some a aprovação no WhatsApp do atendimento. Portanto o ouro-teste decide: entrega trabalhada com registro no SoR da agência, senão foi conversa.

O ouro-teste da operação de agência

Antes de qualquer landing de “agente de conteúdo para agências”, eu aplico a frase-teste. Sem entrega aprovada ou status/ID no SoR, o runtime não fechou o job da agência. Por isso a imagem de abertura mostra brief → lote versionado → aprovação → writeback, não um print de chat fluente. Também não é o day-in-life do marketing interno (já mapeado no sibling de agente de IA para marketing); aqui o objeto é a agência que atende vários clientes no mesmo board.

Escrevo em primeira pessoa de implementação: o que eu desenho na mesa de ops da agência, o que recuso e o que atendimento/estratégia ainda herdam. Sistema de registro aqui é board de jobs, pasta por cliente, DAM, planilha de retainer e checklist, não o histórico do GPT sozinho. Na tríade chatbot versus copiloto versus agente, o recorte deste texto é aplicar na operação. Quando slides, imagem ou vídeo aparecem como elo, foreshadowo em uma frase e paro.

Recomendo ler este mapa como playbook BOFU para agências BR. Bem como em outros ofícios deste blog, velocidade sem writeback treina vaidade. Ou seja, “a IA escreveu em dois minutos” sem card atualizado continua sendo demo. Em suma, o turno começa no brief do cliente e termina no SoR da casa.

O que muda quando a agência aplica um agente de IA (vs ferramenta avulsa)

Quem busca agente de ia para agencia de marketing encontra roundups que misturam CapCut com “chatbot white-label” e login em painel self-serve. Eu recorto outro objeto: o que muda na operação com um agente de IA para agência de marketing quando o runtime atravessa o job e deixa ID, versus ferramenta avulsa que só acelera um clique. A cobertura da McKinsey sobre agentic AI no marketing aponta potencial alto nas atividades, rotulo a fonte; uso o insight de redesenhar workflow, não o percentual como KPI da BayAI. Recuso batizar de trabalho feito um chat que só narra “como usar IA na agência”.

Ferramenta avulsa acelera um clique; agente fecha o job

Ferramenta avulsa gera variação de copy, redimensiona criativo ou resume reunião. Não move o card do cliente. Também não aplica o brand kit certo nem grava o path do _vN aprovado. Tríade chatbot versus copiloto versus agente já aparece no guia de chatbot de IA para empresas; aqui aplico o recorte só à operação de agência, sem reabrir CX. Bot que só lista dicas genéricas sem card no SoR é anti-ângulo deste texto: conversa sem ofício.

Consulta de boas práticas continua útil. Continua, porém, sendo conversa. Conversa não substitui brief, lote, aprovação do cliente e writeback. Sócio que mede o dia por prompts respondidos comprou o indicador errado. Indicador deste assento é entrega aprovada ou task fechada no SoR. Por isso eu recuso FAQ de “melhor prompt de carrossel” no slide do job. FAQ descreve outro palco.

Operação que celebra “todo mundo usa ChatGPT” e não encontra o asset na pasta do cliente na manhã seguinte está medindo o assento errado. Resposta fluente não fecha retainer. Status gravado com ID, porém, muda a casa. Eu recuso KPI de “textos gerados” como proxy de trabalho. Proxy errado treina o time a preferir chat fácil. Chat fácil sem writeback deixa a fila igual.

Além disso, ferramenta avulsa treina a diretoria a achar que “ter IA” é ter gerador. Contudo a capacidade da agência não melhora com gerador se o claim do Cliente A vazou no pack do Cliente B. Por isso eu meço o turno pela entrega e pelo ID, não pelo tempo de reply. Em seguida o copiloto aparece como tentação, porque o rascunho fica rápido.

Todavia o rascunho rápido sem pasta versionada some na segunda-feira. Também some a memória do projeto quando o social media sai. Portanto o assento certo pede writeback antes de comemoração.

Chatbot, copiloto e agente na mesa da agência

Chatbot responde “o que é agente de IA?”. Copiloto (ChatGPT, Claude, Gemini) rascunha; humano cola e publica sozinho. Sem identificador no fim do expediente, o nome comercial “agente de ia para agencia de marketing” continua sendo rascunho com branding. Runtime de um agente prioriza brief → lote → QA/aprovação → writeback e grava status ou ID. Recuso copiloto batizado de agente só porque o parágrafo saiu fluente. Fluência não é ofício. Ofício, porém, é turno trabalhado com registro no stack.

O Abradi Talks sobre IA generativa na prática nas agências descreve ganho em tarefas operacionais, rotulo; não invento KPI da página. Uso a definição operacional: o turno atravessa a entrega e deixa log no SoR. Copiloto para no Docs.

Gestor que celebra “a IA fez o pack” e abre o ClickUp sem card atualizado comprou vaidade. Recomendo o teste cru no dia seguinte: a entrega está na pasta do cliente, com versão, com aprovação e com ID da task? Se a resposta é não, você comprou parágrafo. Assim o copiloto continua útil onde o rascunho custa caro. Não ocupa o assento de quem opera o writeback.

Na prática eu vejo três sintomas de copiloto disfarçado de agente. Primeiro: o texto vive só no chat e ninguém sabe qual versão foi ao cliente. Segundo: a aprovação aparece no print do WhatsApp e some na sexta. Terceiro: o card do board fica em “em andamento” para sempre. Então o diagnóstico é simples, falta writeback, não falta modelo.

O que fica de fora deste H2

Day-in-life do marketing in-house (pauta sibling), deep-dive de redes sociais, criação de conteúdo como capítulo isolado, campanhas como tutorial de ads e os siblings criativos de slides/imagem/vídeo ficam de fora dos H2s. Produção entra como lote, versão e ID, não como tutorial de gerador. Quando o asset vira só um elo do ciclo maior, foreshadowo em uma frase e paro. Em suma, o job do ciclo é a mesa da agência com entrega ou ID no stack de ops.

Também fica de fora o deep-dive de vendas, SDR, financeiro e atendimento já publicados neste blog. Agência aqui é o ofício do brief multi-cliente, do lote e da aprovação com registro. Sem misturar funil comercial inteiro neste H2. Dessa forma o leitor sabe o que pedir no diagnóstico, e o que deixar para outro texto.

Brief, escopo e critérios no SoR da agência (antes de gerar)

Fila do ciclo de um agente de ia para agencia de marketing não é, por exemplo, “faz posts para o Cliente X” colado no chat. Um agente de IA para agência de marketing sério recebe o brief, o escopo do retainer e os critérios antes de produzir. Humano ainda manda o que entra no universo: objetivo da peça, público do cliente, oferta, claim permitido, restrição de marca e data-alvo. Máquina manda sugestões e priorização dentro do teto de horas. Sem brief no SoR, o “agente” só espera alguém colar um prompt no ChatGPT.

Brief mínimo que a máquina lê (por cliente)

O brief mínimo inclui cliente/ID, canal, objetivo único, mensagem única, CTA, assets de marca, restrições de claim, data-alvo e slot de horas do retainer. Sem dono (atendimento ou estratégico), o brief vira rumor. Eu recuso kickoff em que “tom” ainda é feeling do diretor de arte, porque amanhã outro analista usa outro claim. Recomendo valores enumerados com dono e data, então a máquina lê o mesmo documento que a mesa.

Além disso, jobs do board entram como candidatos a turno, não como “fazer tudo do mês”. No entanto priorizar demais ainda mata prova social se o brief não avisou o que é intocável. Por exemplo, quem muda o CTA no meio esconde o experimento. Assim, o brief precisa marcar o que é fixo e o que é variável.

O Censo Agências 2026 mostra gestores pedindo skill de prompts e agentes, rotulo; aplico ao planejamento. Eu recuso “automatizar o calendário de todos os clientes” como sinônimo de agente na operação. Automação dispara se/then. Agente lê critério e prioriza o turno do dia por conta.

Quando o brief chega incompleto, eu paro o turno, não invento o objetivo do cliente. Objetivo inventado vira métrica inventada. Métrica inventada vira slide de vaidade na sexta. Por conseguinte o brief incompleto é porta, não detalhe cosmético. Também é porta o brief que muda no meio do dia sem versionar o card. Sem versão do brief, a mesa discute “o que combinamos” e perde a manhã.

SoR da agência: board, pasta e retainer

SoR vive no Notion/ClickUp/Asana (ou equivalente), com card por job: cliente, status, responsável, canal, data, link do asset, horas estimadas/consumidas. Chat que lista ideias sem card não planeja. Também não herda o histórico quando a pessoa sai. Sem card, a memória do mês some no WhatsApp do atendimento.

Recomendo, ainda, separar “ideia do cliente” de “job elegível”. Bem como separar “rascunho de pauta” de “brief aprovado”. Ou seja, o turno só fica honesto quando o card existe antes do prompt. Em suma, board visível vence lista solta no Docs.

Campos mínimos que eu exijo no card: título do job, cliente, canal, data-alvo, owner, status, link do brief, link do asset, horas, KPI do experimento se houver. KPI ausente faz a medição virar feeling. Owner ausente deixa o incidente sem dono. Data-alvo ausente transforma o board em mural de intenções. Então o card é o contrato do turno, curto, legível, auditável.

O que espera e o que fica de fora do planejamento

Espera quem ainda não tem aprovação de claim do cliente, quem depende de jurídico na oferta e quem caiu em silêncio escrito na política (embargo de produto, campanha em revisão legal). Fica de fora quem é caso político marcado para atendimento, quem exige horas acima do retainer sem alçada e quem já tem peça publicada sem mudança de objetivo. Sem as três portas, entra, espera, fora, o planejador vira rajada com cara de inteligência. Eu recuso “encaixa tudo na semana” só porque o chat sugeriu dez pautas. Pauta sem objetivo único é ruído.

Stakeholder com veto, oferta regulada ou peça sob contrato de parceiro entra em “não priorizar automático” antes da produção. Sem essa lista, o runtime devolve exatamente o post que a marca do cliente evitaria. Cadastro sujo de card também é filtro: sem cliente e data, a peça não entra no turno.

Operação que esconde a exclusão para não perder velocidade está treinando passivo. Por isso elegibilidade do brief é porta, não enfeite. Máquina respeita o escrito. Humano decide o caso político que a regra não previu. Assim priorizar deixa de ser “sugerir mais”. Vira escolher o que merece o turno de hoje em cada conta.

Na minha mesa, a fila do dia raramente passa de um punhado de turnos elegíveis por pod. Volume alto sem critério só multiplica retrabalho entre clientes. Desse modo o planejamento ganha cara de ofício: menos ideias soltas, mais cards prontos para produção. Também ganha cara de governança, porque o que ficou de fora está escrito, não escondido.

Produção em lote: do rascunho à entrega aprovada com versão/ID

Produção sem versão, na operação da agência, é rascunho disfarçado. Eu desenho o turno de produção como caminho do draft ao asset _vN aprovado na pasta do cliente, com ID legível no card. Sem isso, o time celebra “a IA escreveu” e amanhã ninguém sabe qual arquivo foi ao cliente. O State of AI da McKinsey mostra adoção de agentes ainda concentrada, rotulo; uso o insight de que escala exige workflow, não tool isolada.

Critério antes do gerador (e isolamento por cliente)

Critério: tom do cliente, comprimento, CTA, claim permitido, formato (post, email, landing, criativo de ads) e pasta de destino. Gerador sem critério inventa fluência. Fluência sem critério vira retrabalho. Eu recuso “gera dez variações” como política sem marcar qual variação vira _v1 e em qual pasta de cliente.

Além disso, assets de marca (logo, tipografia, cores, intro/outro) entram como input, não como afterthought. No entanto brand kit no Figma sem pasta no Drive ainda deixa o aprovado solto. Por exemplo, quem exporta PNG no Desktop e some o arquivo quebra o SoR. Assim, destino do arquivo é parte do critério.

Slides, imagem e vídeo aparecem como elos do ciclo criativo, não como capítulos deste texto. Quando o turno pede um desses formatos, o agente da agência só orquestra critério, versão e ID; o ofício fino fica nos siblings. Dessa forma evito canibalizar o cluster de outubro.

Também recuso misturar “criar do zero” com “editar o que já existe” no mesmo card sem marcar o tipo. Tipo errado gera expectativa errada. Expectativa errada gera “a IA falhou” quando o brief é que falhou. Por conseguinte o card precisa dizer se o turno é criação, adaptação ou edição, antes do primeiro prompt.

Lote com naming e pastas por cliente

_v1 é rascunho. _v2 incorpora revisão interna. _vN aprovado (interno ou cliente) é o único que pode ir ao canal. Naming com cliente, data, canal e versão. Sem naming, o writeback mente. Também mente o card que aponta para “versão final final2”. Eu recuso “final” no nome do arquivo. Aprovo com status e ID.

Recomendo, ainda, preservar o original quando o turno é edição. Bem como preservar o brief ao lado do asset. Ou seja, o turno de produção só fecha quando o card aponta para o arquivo certo. Em suma, versão legível vence pasta “Marketing_IA_novo”.

Pastas que eu uso como padrão mental: clientes/{slug}/briefs/, drafts/, approved/, published/. Cada uma com naming estável. Sem isso, o agente grava no lugar errado e o humano “não acha”. Então achar o arquivo é parte do ofício, não detalhe de TI. Também é parte do ofício o link permanente no card; path relativo no chat some.

Lote significa: várias peças do mesmo brief no mesmo turno, com a mesma regra de versão. Não significa jogar vinte prompts soltos e espalhar arquivos. Desse modo a produção escala sem espalhar caos. Também escala o retrabalho se a regra de pasta falhar, por isso o destino é porta.

Aprovação interna antes do cliente

Aprovação interna não é “gostei do tom”. O checklist cobre claim, CTA, marca do cliente, oferta, restrição legal e isolamento de pasta. Máquina prepara o pacote. Humano assina o risco. Sem porta de aprovação interna, o runtime manda ao cliente o que a marca evitaria. Sem porta documentada, o atendimento não tem trilha.

Operação que pula aprovação para “ganhar velocidade” está treinando incidente. Por isso a porta fica antes do envio ao cliente. Máquina acelera variação. Humano decide o que pode sair da casa. Assim produzir deixa de ser “gerar mais”. Vira entregar asset versionado com ID.

Quando a aprovação demora, eu não “envio provisório”. Provisório vira permanente. Permanente vira incidente. Portanto o status fica em revisão até a assinatura, e o card mostra quem trava. Transparência aqui reduz política de corredor. Também reduz o hábito de aprovar por emoji no WhatsApp sem trilha.

QA, aprovação do cliente e handoff sem virar caos no Drive

QA e aprovação do cliente são o gargalo clássico da agência, e onde o runtime mais falha quando vira só chat. No agente de IA para agência de marketing, eu desenho o elo como pacote auditável: link do _vN, checklist, prazo de retorno e status no board. Sem isso, o Drive vira caça ao “arquivo certo” e o atendimento vira mensageiro de PNG.

Checklist de QA antes do envio

Checklist mínimo: claim, ortografia/nome do cliente, marca (logo/cores), CTA, formato/aspect, pasta correta, horas consumidas vs retainer, owner. Sem checklist, o “quase pronto” vira retrabalho. Eu recuso enviar pack sem marcar o que já foi conferido. Conferência escondida no chat some.

Além disso, isolamento entre clientes é item de QA, não detalhe. No entanto urgência do cliente ainda não autoriza misturar pastas. Por exemplo, quem anexa o criativo do Cliente B no e-mail do Cliente A gera o incidente clássico. Assim, path e nome do cliente no arquivo são porta, não sugestão.

Quando o modelo sugere um claim “mais forte”, eu trato como hipótese, não como copy final. Hipótese vai para revisão. Revisão vai para status. Status vai para o card. Dessa forma a criatividade não some; só deixa de pular a porta.

Aprovação do cliente com trilha

Aprovação do cliente precisa de canal e registro: e-mail/link de revisão com versão, ou comentário no board espelhado no card. Print de “ok” no WhatsApp não é SoR. Também não é SoR o áudio “pode subir”. Eu recuso comemoração sem status “aprovado pelo cliente” e link da versão.

Recomendo, ainda, separar “aprovado com ressalva” de “aprovado limpo”. Bem como separar “pedido de alteração” de “novo brief”. Ou seja, o status do card precisa refletir o estágio real. Em suma, aprovação honesta vence print de tela.

Quando o cliente atrasa, o agente registra a espera no card, não esconde no chat. Espera escondida vira “a agência não entregou” sem causa. Causa escrita acelera o alinhamento. Por conseguinte o writeback de espera é tão importante quanto o writeback de sucesso.

Handoff sem caos no Drive

Handoff interno (criação → mídia → atendimento) e handoff ao cliente pedem o mesmo rigor de ID. Link do aprovado, owner do próximo passo, prazo. Sem isso, a sexta vira caça ao arquivo no celular do social media. Então o handoff não é burocracia, é memória operacional.

Operação que celebra “entregamos o pack” sem pasta approved/ atualizada está medindo o assento errado. Pack sem path é teatro. Path sem status no board também é incompleto. Assim o handoff deixa de ser “mandar no grupo”. Vira fechar o elo no SoR.

Também não conta “anotar depois”. Depois raramente vem. Por isso o handoff é passo do turno, não tarefa residual. Máquina pode preencher campos. Humano confirma o que é alçada do cliente. Em suma, o fim do envio só existe se o SoR mudou.

Writeback: status/ID no board (senão foi só um chat)

Writeback sem board, na operação da agência, é slide de vaidade. Eu desenho o fim do turno como atualização do card: status, link do asset, horas, aprovação, task ID. Sem isso, o nome comercial continua sendo copiloto. O Panorama RD Station 2026 para agências lembra que percepção de valor e ROI importam na retenção, rotulo; aplico ao writeback como prova de ofício, não como promessa de churn zero.

O que grava no SoR da agência

Grava: status (rascunho/revisão interna/enviado ao cliente/aprovado/publicado/medido), asset ID ou path, task ID, link publicado se houver, horas, timestamp, owner, cliente. Não grava: “ficou bom”, print sem ID, parágrafo no chat. Eu recuso métrica que não cabe no card.

Além disso, o writeback precisa ser idempotente o bastante para o dia seguinte. No entanto sobrescrever histórico sem trilha ainda esconde erro. Por exemplo, quem apaga _v2 e deixa só _v3 perde a auditoria. Assim, preservar versões é parte do writeback.

Campos de horas que eu aceito no card são poucos e combinados no retainer. Horas demais viram planilha que ninguém lê. Horas nenhumas viram feeling de “estamos no limite”. Então escolha registrar estimado vs consumido por job. Também escolha a janela de leitura (semana, quinzena), senão a sexta compara números incomparáveis.

Gold test revisitado

Se no fim do turno não há entrega aprovada ou status/ID no SoR, o runtime da agência não trabalhou. Preview no chat, Docs solto e “vou mandar amanhã” falham o teste. Também falha o projeto que vive só na conta pessoal do analista. SoR da agência manda, não a memória do GPT.

Recomendo o teste cru toda sexta: abra o board e a pasta dos clientes do pod. Os cards da semana têm ID? Os assets apontam para _vN aprovado? As aprovações têm trilha legível? Se a resposta é não, você comprou conversa. Portanto o KPI do assento é writeback, não “posts gerados”.

Quando o teste falha, eu não culpo o modelo primeiro. Culpo o desenho do turno. Modelo sem porta de writeback só acelera o caos. Caos acelerado parece produtividade até a auditoria. Então o remédio é redesenhar o card e as permissões, não trocar de LLM toda semana.

O que não conta como writeback

Não conta: e-mail “segue o texto”; WhatsApp com PNG; planilha paralela que ninguém abre; comentário no Docs sem status no card. Conta: campo atualizado no SoR que o time já usa. Eu recuso inventar um segundo sistema “só para a IA”. A IA escreve onde a mesa já olha.

Operação que celebra dashboard bonito sem ID no card está medindo o assento errado. Dashboard sem writeback é teatro. Writeback sem horas/versão também é incompleto. Assim medir deixa de ser “olhar o Ads do cliente”. Vira fechar o turno no stack da agência.

Também não conta “anotar depois”. Depois raramente vem. Por isso o writeback é passo do turno, não tarefa residual. Máquina pode preencher campos. Humano confirma o que é alçada. Em suma, o fim do dia só existe se o SoR mudou.

Papel do atendimento/estratégia/humano na operação

Máquina, no ciclo da operação da agência, acelera rascunho, lote, checklist e log. Humano herda juízo de marca do cliente, claim, escopo do retainer, LGPD e veto político. Eu recuso narrativa de “agência no piloto automático”. Piloto automático sem alçada é incidente com logo do cliente.

Atendimento e expectativa

Atendimento traduz o pedido do cliente em brief e status. Também carrega a conversa difícil quando o claim não passa. Esses dois não saem de prompt genérico. Também não saem de modelo treinado em internet pública quando o cliente tem restrição setorial. Eu recuso publicar claim médico, financeiro ou jurídico sem porta humana.

Além disso, alinhamento de expectativa no onboarding reduz churn por “falta de valor percebido”. No entanto urgência de campanha ainda não apaga o contrato de escopo. Por exemplo, quem promete lote infinito dentro do retainer gera o chamado clássico. Assim, lista de inclusões/exclusões fica escrita antes do turno.

Quando o cliente pede “mais do mesmo”, eu trato como hipótese de escopo, não como default automático. Hipótese vai para revisão de retainer. Revisão vai para status. Status vai para o card. Dessa forma a relação não some; só deixa de pular a porta.

Estratégia, brand e incidente

Estratégia define o que merece o turno e o que é ruído. Brand: tom, visual, promessa do cliente. Incidente (claim errado no ar, asset na pasta errada, vazamento entre contas) entra em runbook humano com trilha no SoR. Máquina pode sinalizar anomalia. Humano decide pausar, corrigir e comunicar.

Recomendo, ainda, separar “anomalia operacional” de “crise de marca do cliente”. Bem como separar “pausar post” de “refazer brief”. Ou seja, a alçada precisa ser explícita. Em suma, humano no ciclo não é falha do agente, é desenho.

Bases de contato do cliente pedem base legal e preferência de canal. Criativo com rosto pede autorização. Retargeting agressivo pede juízo. Sem isso, o agente “eficiente” vira risco de marca e de compliance. Por conseguinte os guardrails de dados entram no mesmo card do brief, curtos, legíveis, obrigatórios.

O que a máquina não deve fingir

Não deve fingir que aprovou brand do cliente. Tampouco deve fingir que leu o contrato de retainer. Também não deve fingir que o jurídico liberou o claim. Quando o runtime “aprova sozinho”, o que ele fez foi pular a porta. Eu recuso essa economia. Porta escrita é produto.

Operação que esconde a porta para parecer “mais agêntica” está treinando risco. Por isso o slide do humano fica explícito neste H2. Máquina no rough work. Humano no risco. Assim o ciclo permanece auditável, e o agente na agência continua sendo ofício, não magia.

Também não deve fingir que “aprendeu a marca” só porque leu três posts antigos do cliente. Aprendizado de marca exige kit, exemplos negativos e veto. Sem exemplos negativos, o modelo só imita o que já viralizou, inclusive o que o cliente não quer repetir. Então o humano curator o corpus. A máquina executa dentro dele.

BayAI, bayai.com.br

Na BayAI eu trato o agente de IA para agência de marketing como Funcionário de IA: diagnóstico da operação multi-cliente, implementação no stack que a casa já usa e operação assistida, não um painel self-serve com login e prompts soltos. O trabalho é redesenhar brief → lote → QA/aprovação → writeback de status/ID. Sem preços neste texto, sem clientes inventados e sem cases fabricados. Se o board ainda vive no chat, o próximo passo é entrar na lista de espera em bayai.com.br e pedir o diagnóstico da operação, piloto em semanas; leitura de resultado costuma aparecer entre 60 e 90 dias.

Conclusão

Um agente de IA para agência de marketing de verdade fecha o turno da operação: recebe brief no SoR, produz lote versionado, passa QA e aprovação com trilha, e grava status/ID no board. Chatbot de FAQ e copiloto de rascunho ajudam, mas não passam no ouro-teste sozinhos. Se no fim não há entrega aprovada ou status/ID no Notion/ClickUp, Drive, retainer ou checklist, foi só um chat.

Recomendo aplicar a frase-teste do agente na operação na próxima sexta. Também recomendo separar este job do mapa do marketing in-house e dos deep-dives de redes e criativos. Portanto o indicador certo não é “quantos posts a IA gerou”. É quantos cards fecharam com ID por cliente. Em suma, ofício com registro vence demo fluente, e a mesa da agência BR ganha ritmo sem perder trilha.

Checklist de aplicação (para colar no board)

Quando você abrir o board amanhã, pergunte só isto: o turno de ontem deixou entrega aprovada e ID no stack por cliente? Se a resposta for não, você ainda está no chat. Se a resposta for sim, você começou a operar um agente de verdade, com humano na porta certa e máquina no rough work. Assim o agente de ia para agencia de marketing para de colecionar demos e passa a colecionar turnos fechados.

Checklist curto: (1) brief no card antes do prompt; (2) pasta clientes/{slug}/ com _vN; (3) QA interno marcado; (4) aprovação do cliente com trilha; (5) writeback de status/horas/ID; (6) humano no claim, escopo e incidente. Sem os seis, a ferramenta avulsa continua mandando na casa, e a capacidade não escala.