AI Agents em Produção

Lições do LinkedIn Hiring Assistant, padrões de arquitetura, evals e guardrails

Agente em produção ≠ POC com ChatGPT. POC funciona em 80% dos casos felizes; produção exige 99%+ correto, custo controlado, observabilidade, fallback. As lições abaixo vêm de times que escalaram agentes para milhões de usuários (LinkedIn, GitHub Copilot, Anthropic Claude apps).

Componentes de um agente em produção

┌────────────────────────────────────────────────────────────────┐ │ Agent System │ │ │ │ ┌──────────────┐ ┌────────────────┐ ┌────────────────────┐ │ │ │ Input │ │ Conversation │ │ Tools / Functions │ │ │ │ Guardrails │ │ Memory │ │ - search_db │ │ │ │ (PII, abuse) │ │ (short / long) │ │ - send_email │ │ │ └──────┬───────┘ └────────┬───────┘ │ - update_status │ │ │ │ │ └────────┬───────────┘ │ │ ▼ ▼ │ │ │ ┌──────────────────────────────────────────────▼───────────┐ │ │ │ LLM Orchestrator │ │ │ │ (ReAct loop, tool calling, retry, model routing) │ │ │ └──────────────────────┬───────────────────────────────────┘ │ │ ▲ │ │ │ │ ▼ │ │ ┌──────┴───────┐ ┌────────────────┐ ┌────────────────────┐ │ │ │ RAG │ │ Output │ │ Action Guardrails │ │ │ │ (vector DB, │ │ Guardrails │ │ (permission, conf │ │ │ │ re-rank) │ │ (schema, fact) │ │ irmation, sandbox)│ │ │ └──────────────┘ └────────────────┘ └────────────────────┘ │ └────────────────────────────────────────────────────────────────┘ │ │ ▼ ▼ ┌─────────────┐ ┌────────────────┐ │ Observability│ │ Eval Pipeline │ │ (logs, traces│ │ (offline + │ │ cost, qual.)│ │ in-prod sample│ └─────────────┘ └────────────────┘

Loop básico ReAct (reasoning + acting)

# Loop ReAct (Reasoning + Acting) while not_done: thought = model.generate("Given task X and state S, what next?") if thought.is_final_answer: return thought.answer action = thought.tool_call # qual tool, com quais args if needs_human_approval(action): wait_for_user_confirmation() observation = execute(action) # roda a tool state.append(thought, action, observation) if state.iterations > MAX: raise TooManyIterations # circuit breaker # Variantes: # - Plan-then-execute (plan inteiro antes de executar) # - Tree of thoughts (explora múltiplos paths) # - Reflexion (auto-crítica entre passos)

Decisões de arquitetura

DecisãoTrade-off
Single agent vs Multi-agentSingle é simples e debugável; multi escala melhor pra tarefas heterogêneas mas é difícil de orquestrar e debugar
Sync vs AsyncSync é UX simples; async permite tarefas longas (10+ min) mas exige notificação e UX de "trabalhando"
Tool use vs RAGRAG é estável; tools dão poder mas espaço de erro maior; combinar é comum
Modelo único vs routerRouter (Haiku pra tarefa simples, Opus pra raciocínio) reduz custo 5-10x; complexidade extra de roteamento
Memória curta vs longaCurta cabe no contexto; longa precisa vector store + retrieval; introduz staleness
Human-in-the-loopPara ações irreversíveis (delete, send email, charge); pausa fluxo mas previne desastre
Comece simples. Single-agent + ReAct + tools bem desenhados resolve 80% dos casos. Multi-agent, dynamic routing, memory complex são otimizações para depois.

Tipos de tarefa de agente

  • Assistente conversacional — ChatGPT-like, multi-turn, baixo risco por ação
  • Workflow agent — executa tarefa multi-step até completar (Hiring Assistant LinkedIn)
  • Coding agent — modifica código, alta autonomia, sensores como harness (ver página)
  • RPA-like — automatiza ação em UI, mais brittle
Quando NÃO usar um agente, e usar workflow determinístico?
Se o problema tem solução determinística clara, não use LLM. LLM é caro, não-determinístico, e introduz novos modos de falha. Use agente quando: (a) o input é livre/ambíguo (linguagem natural, conversa); (b) o caminho de execução varia por contexto; (c) tradução semântica é necessária (não regex). Para fluxos estruturados (workflow BPMN, ETL), use orquestrador tradicional — vai ser mais barato e confiável. Anti-pattern comum: LLM substituindo um if.