Os seis clusters seguem o caminho de "tirar da sua máquina e botar no mundo": primeiro a linguagem do que é agêntico, depois como a IA responde com seus dados (RAG), onde o código mora (versionamento), como ele roda sozinho (execução hospedada), como vira um site (app/frontend) e como se protege e cobra (segurança & pagamento).

Diagrama ilustrativo — a Parte 2 do glossário, do conceito agêntico até proteger e cobrar. Cada caixa é um tópico abaixo.

O que é

Um agente é um sistema que recebe um objetivo e raciocina, se adapta e se auto-corrige para alcançá-lo — em vez de seguir passos fixos. Agêntico é o adjetivo: descreve esse comportamento de "decidir o caminho". Para construir agentes de forma organizada existe o WAT (Workflows / Agent / Tools): W são as instruções em markdown (o "manual"), A é o agente coordenador (o "cérebro"), T são as ferramentas/scripts que fazem o trabalho.

O que torna o agente poderoso é o loop de auto-melhoria: ele roda, bate num erro, diagnostica, conserta a ferramenta e atualiza o manual — para o erro não voltar. Mas há uma armadilha: o agentic gap ("lacuna agêntica") — quando o agente roda sozinho na nuvem, ninguém está olhando para se auto-curar, então a confiabilidade vira responsabilidade sua.

Diagrama ilustrativo — W alimenta A (ciano), que aciona T; a linha tracejada é o loop de auto-melhoria que fecha o ciclo.

Por que aprender

Essas palavras explicam a diferença entre "rodou na minha frente" e "roda sozinho com segurança". O loop de auto-melhoria é o que faz o agente ficar melhor com o uso; o agentic gap é o motivo de você ter que pensar em confiabilidade desde o primeiro prompt quando vai hospedar.

Conceitos-chave

O que é

RAG (Retrieval-Augmented Generation, "geração aumentada por recuperação") é a técnica de fazer a IA buscar a informação certa nos seus documentos antes de responder — em vez de chutar pela memória. Os documentos formam a knowledge base ("base de conhecimento"). O ato de procurar e trazer o trecho relevante é o retrieval ("recuperação").

Para o agente saber o quanto pode confiar no que achou, ele pode emitir um confidence score ("nota de confiança"): alta, média ou baixa, conforme o quão bem a base bateu com a pergunta. Se a confiança é baixa (ou não achou nada), o agente recusa inventar e cai num plano B educado ("vou pesquisar e retorno") — o oposto de alucinar.

Por que aprender

RAG é o que transforma um chatbot genérico num agente que responde sobre o seu negócio com fatos verificáveis. E o confidence score é a peça de segurança: ele faz o agente dizer "não sei" em vez de mentir com confiança — exatamente o comportamento que você verifica no "trust but verify".

Conceitos-chave

O que é

GitHub é um armazenamento de código na nuvem: o lugar onde o código mora, acessível de qualquer máquina, com histórico completo para voltar atrás. Cada projeto fica num repo (repositório) — a pasta do projeto dentro do GitHub. Você salva mudanças em commits (fotografias do projeto com uma descrição) e envia esses commits para a nuvem com um push.

Para o assistente operar o GitHub pelo terminal, usa-se a gh CLI ("interface de linha de comando do GitHub"): a ferramenta que conecta sua máquina à sua conta. E lembre da regra de ouro: o .env (com as chaves) nunca entra num commit — o .gitignore garante isso.

Por que aprender

GitHub é a base de tudo que roda hospedado: o código precisa estar na nuvem para um serviço de execução puxá-lo e rodar. O histórico de commits também é seu seguro — se algo quebra, você volta para uma versão que funcionava. E entender commit/push/repo te deixa acompanhar o que o assistente faz, em vez de só aprovar às cegas.

Conceitos-chave

O que é

Trigger.dev é um motor de execução na nuvem: roda suas tarefas de forma confiável, sem timeout, com retries e logs — como um assistente que faz o trabalho na hora certa. Ele dispara tarefas por cron (um relógio de agendamento — um padrão de 5 campos como 0 7 * * * = "7h todo dia") ou por webhook (uma "campainha digital": uma URL que, ao receber dados, acorda a tarefa).

Os dados que chegam pelo webhook são o payload ("carga"). Você constrói e testa num ambiente de dev (desenvolvimento) antes de promover para prod (produção), o ao-vivo. Cada execução deixa um trace (rastro passo a passo); falhas podem disparar retries (novas tentativas) e alerts (avisos por e-mail/Slack).

Por que aprender

Este é o vocabulário que fecha o agentic gap. Sem ninguém olhando, são os traces que te mostram o que aconteceu, os retries que resolvem falhas passageiras e os alerts que te avisam antes do usuário. Cuidado: retry conserta erro temporário (de rede/tempo), não bug de lógica — saber a diferença evita "tentar de novo" para sempre.

Conceitos-chave

O que é

O frontend é tudo o que o usuário vê e toca: botões, formulários, textos, layout — roda no navegador da pessoa. O backend é o que roda no servidor: a lógica, as chamadas de API, o banco de dados — invisível ao usuário. Os dois conversam num ciclo de request/response ("pedido/resposta"): o usuário clica → um pedido vai ao servidor → ele processa → a resposta volta → a tela atualiza.

Para publicar um frontend na internet usa-se a Vercel: um serviço de hospedagem de sites — você dá um push no GitHub e ele coloca o site no ar, acessível de qualquer lugar. E os segredos do app (como a chave que liga o frontend ao backend) ficam em env vars (variáveis de ambiente): valores injetados em tempo de execução, fora do código.

Diagrama ilustrativo — o frontend (emerald) pede, o backend (ciano) processa e responde. Esse vai-e-volta é o ciclo request/response.

Por que aprender

A separação frontend/backend é o modelo mental que destrava entender qualquer app. É também o que conecta seu workflow ao mundo: trocando o gatilho de formulário por um webhook, qualquer pessoa com a URL pode usar sua automação por um site bonito — frontend na Vercel falando com o backend.

Conceitos-chave

O que é

Quando o app tem usuários, você precisa proteger dados e cobrar. O Supabase é um serviço de banco de dados + login (autenticação). Dentro dele, o RLS (Row-Level Security, "segurança por linha") são regras que vivem no próprio banco para que um usuário nunca veja os dados de outro — uma camada extra, mesmo se houver bug no frontend. Mudanças na estrutura do banco são migrations (scripts que criam/alteram tabelas).

Para receber pagamentos há o Stripe. O usuário paga numa página de checkout ("finalizar compra"); cada plano tem um price ID (o identificador do preço). O Stripe avisa seu app sobre eventos (assinou, cancelou) por webhook, validado por um webhook secret (a senha que confirma que o aviso veio mesmo do Stripe). Um modelo comum é o freemium: um nível grátis limitado + um pago ilimitado.

Por que aprender

Estes termos fecham o ciclo "ideia → app que dá dinheiro com segurança". Sem autenticação e RLS, qualquer um com a URL usa (e gasta) seu app; sem RLS, um bug pode vazar dados de um usuário para outro. E o freemium com Stripe é o que transforma um workflow num produto que se paga.

Conceitos-chave