Automação, skill e Marvin: quem faz o quê

Quem chega ao Hub com um processo repetitivo na cabeça encontra três caminhos que parecem o mesmo: montar uma automação, escrever uma skill ou simplesmente pedir ao Marvin. A confusão não é de nome, é de natureza: os três fazem trabalho acontecer sem alguém repetir a tarefa, e só um deles é o certo para cada caso. Escolher errado não trava nada, o que é justamente o problema: o processo funciona por algumas semanas e cobra a conta depois, em regra frágil ou em consumo de IA que ninguém sabe explicar.

Três mecanismos, três naturezas

A diferença mais útil é a de custo: automação que só movimenta dado não consome crédito de IA, skill consome toda vez que roda. Isso não torna a skill cara, torna cada uma delas uma decisão.

O teste de decisão

Uma pergunta resolve a maioria dos casos: dado o mesmo acontecimento, o resultado é sempre o mesmo?

• Sempre o mesmo. Quando o negócio é ganho, abrir a implantação e criar a tarefa de kickoff. Não há nada a interpretar. Isso é automação, e resolver com IA é pagar por uma decisão que já estava tomada.
• Depende de ler e julgar. Resumir o que aconteceu na semana, classificar a intenção de uma mensagem que chegou, escrever a resposta no tom certo. Isso é skill, e tentar resolver com condições vira uma regra frágil que quebra na primeira frase fora do padrão.
• Muda a cada vez. “Por que este cliente parou de comprar?” Isso é conversa com o Marvin, e não vale empacotar.

Um segundo teste separa skill de conversa: você escreveria de novo o mesmo pedido longo na semana que vem? Se sim, é skill. Se a pergunta só faz sentido hoje, é conversa.

O erro mais caro

Não é usar IA demais. É montar como skill um processo que ninguém combinou ainda. A automação exige que o processo esteja decidido, e por isso ela expõe o desacordo. A skill aceita a instrução vaga e devolve um resultado que parece bom, mês após mês, sem que ninguém perceba que a operação continua fazendo de três jeitos diferentes.

O padrão que combina os três

A maior parte das rotinas reais não é só um ou só outro. O desenho que funciona separa as responsabilidades assim:

A automação dá o quando. A skill dá o julgamento. A automação entrega.

Na Empresa Aurora, a conferência da carteira toda segunda de manhã fica assim: um fluxo com o gatilho de programação decide que são oito da manhã de segunda; o passo Executar skill do Marvin lê os negócios parados e escreve o resumo com o que merece atenção; os passos seguintes publicam o texto no canal do Chat e criam a tarefa para Carla revisar o que ficou de fora.

Nenhuma das três partes faria isso sozinha. O relógio não sabe julgar, a skill não abre tarefa, e a conversa não acontece se ninguém abrir o Marvin naquela manhã.

Em nome de quem cada coisa roda

Os três mecanismos agem em nome de uma pessoa real, e isso não é detalhe técnico: é o que define o que cada um alcança.

Quando o fluxo dispara por causa de um acontecimento, quem responde é quem causou o acontecimento. Quando ele dispara por horário, sem ninguém envolvido, quem responde é quem criou o fluxo ou a skill. Duas consequências práticas saem daí:

• Acesso. Um passo não alcança o que aquela identidade não alcançaria na tela. Automação que falha por permissão quase sempre é isso.
• Consumo. O crédito da IA entra no nome dessa mesma pessoa, e é por isso que o autor de um fluxo agendado costuma liderar a lista de consumo da empresa.

Vale considerar isso na hora de decidir quem cria o quê. O fluxo crítico da operação não deveria depender do acesso de uma pessoa que pode sair da empresa no mês que vem.

Problemas comuns

Onde aprofundar

• Automações: o que roda sozinho entre os apps: o modelo de gatilho, condição e passo.
• Skills: transforme o que se repete em um comando: como escrever a receita que garante o mesmo resultado.
• Automação que roda em horário, não em evento: o gatilho que dá o quando ao padrão descrito aqui.