Na minha última conferência, eu quis deixar uma ideia muito clara: o problema não é o hype em torno dos agentes de IA. O problema real é ficar apenas observando o hype enquanto outras pessoas já estão construindo sistemas que funcionam, respondem, executam tarefas e geram valor de verdade.
Foi por isso que dei a esta palestra o título OpenClaw: do hype à prática. Minha intenção não era vender uma fantasia futurista nem repetir o discurso de sempre sobre agentes autônomos. Eu quis mostrar algo muito mais útil: como desenhar, implantar e operar agentes de IA que realmente possam viver em produção com critérios concretos de custo, arquitetura, identidade, segurança e execução.
Do ruído midiático para uma arquitetura operacional
Hoje vivemos em um mercado saturado de promessas. De um lado, estão as manchetes que apresentam agentes como se fossem magia. Do outro, estão equipes que precisam de sistemas estáveis, previsíveis, baratos e governáveis.
Essa tensão foi o ponto de partida da minha conferência.
Minha tese é simples: um agente não deve ser entendido como uma demo bonita nem como um truque de marketing. Um agente útil deve ser entendido como infraestrutura operacional.
Na apresentação, eu expliquei isso com uma arquitetura muito fácil de visualizar:
- VPS na nuvem como espaço operacional
- OpenClaw como framework
- LLM como motor de raciocínio
- Telegram como interface conversacional
O mais importante aqui não é a ferramenta específica, mas a mudança de mentalidade. Quando alguém entende essa separação, deixa de pensar em “um bot” e passa a pensar em um sistema que pode operar 24/7, receber instruções, executar ações e evoluir com novas capacidades.
Começar bem não significa começar complexo
Uma das mensagens mais importantes que eu quis deixar é que não é preciso ter hardware caro nem uma infraestrutura absurda para começar a trabalhar com agentes.
Minha recomendação é começar na nuvem, com o mínimo de complexidade e com disponibilidade permanente. Isso obriga a tomar decisões melhores desde o primeiro dia: isolar ambientes, reduzir a superfície de ataque, controlar credenciais e definir fronteiras de confiança.
Essa visão está alinhada com a própria documentação do OpenClaw, que recomenda separar ambientes e limites de confiança quando existem usuários ou credenciais com diferentes níveis de risco, em vez de assumir que tudo deve conviver em um único espaço compartilhado. OpenClaw Security
A identidade do agente também precisa ser desenhada
Outro ponto que destaquei bastante na conferência foi a identidade.
Eu acredito que uma das ideias mais subestimadas no universo dos agentes é achar que tudo se resolve apenas com código. Não se resolve. Um agente também precisa ser escrito, orientado e treinado por meio da linguagem.
Arquivos como SOUL.md, IDENTITY.md e USER.md ajudam a definir:
- o tom do agente,
- o papel dele,
- suas prioridades,
- o contexto do usuário,
- e a forma como deve tomar decisões.
Para mim, essa camada é o que transforma o agente em algo mais próximo de um colaborador operacional do que de um assistente reativo. Não basta dar ferramentas; também é preciso definir como ele pensa, o que considera importante e como responde quando a realidade é imperfeita.
Skills: ensinar tarefas, não apenas conectar funções
Também dediquei uma parte importante da palestra para explicar as skills de uma maneira menos abstrata.
Minha visão é bem direta: uma skill não é apenas uma integração técnica. Uma skill é um conjunto de instruções empacotadas que ensina o agente a executar uma tarefa específica, quase como quando treinamos uma pessoa nova dentro de uma equipe.
Isso muda tudo, porque nos obriga a pensar menos em funcionalidades isoladas e mais em capacidades operacionais reutilizáveis.
A documentação oficial do OpenClaw explica isso muito bem: as skills funcionam como unidades instrucionais empacotadas em pastas com SKILL.md, e podem ser carregadas ou filtradas conforme configuração, ambiente e allowlists. OpenClaw Skills
O valor real não está em substituir pessoas
Nesta conferência eu também quis mover a conversa para um lugar mais honesto.
Não me interessa vender a narrativa de substituição humana. O que me interessa é falar de ampliação de capacidade operacional.
Quando uma pessoa ou equipe adota agentes bem desenhados, não está “eliminando trabalho humano”. Está absorvendo execução repetitiva, delegando operações rotineiras e liberando tempo para estratégia, julgamento, criatividade e direção.
É por isso que eu insisto que hoje uma única pessoa, com poucos dólares por mês e uma boa arquitetura de agentes, pode alcançar uma capacidade operacional que antes exigia equipes muito maiores.
Não porque a IA seja mágica, mas porque automação bem governada multiplica foco.
Do agente individual para um sistema distribuído
Um dos momentos mais importantes da apresentação foi mostrar a arquitetura distribuída do Dragons Team.
Nesse ponto, já não estamos falando apenas sobre “o que é um agente”, mas sobre como construir um sistema multiagente com especialização por contexto, orquestração centralizada, custos controlados e inferência híbrida.
Nesse modelo:
- Nia atua como orquestradora principal
- Majisto foca em infraestrutura e automação de baixo consumo
- Astra se especializa em sinais, scraping e síntese
O valor dessa topologia não está apenas no fato de funcionar. Está no fato de que cada nó possui uma responsabilidade clara e uma carga cognitiva proporcional ao seu papel. Isso torna possível combinar nuvem e inferência local sem explodir custos nem perder governança.
Custos baixos, decisões mais inteligentes
Outra ideia central da palestra foi desmontar o mito de que trabalhar com agentes exige orçamentos gigantescos.
Quando o processamento pesado é enviado apenas para onde realmente faz sentido, e os nós periféricos operam com APIs leves ou funções bem delimitadas, o custo operacional pode permanecer surpreendentemente baixo.
Esse ponto foi essencial para mostrar que a conversa sobre agentes já não é um luxo de laboratório. É uma possibilidade real para criadores, developers, startups e equipes pequenas que querem construir sistemas úteis sem comprometer toda a operação.
Segurança: o momento em que a conversa fica séria
Se existe um segundo ato na minha conferência, ele é este: segurança.
No momento em que conectamos um LLM ao mundo real por meio de ferramentas, APIs, filesystem ou execução de comandos, deixamos de falar apenas sobre geração de texto. Passamos a operar uma superfície de risco completamente nova.
Por isso insisti que aplicações com LLM não podem ser protegidas apenas com controles tradicionais. Riscos como prompt injection direta ou indireta, abuso de ferramentas e escalada de privilégios já são documentados pela OWASP como ameaças centrais para agentes e aplicações baseadas em LLM. OWASP Prompt Injection Prevention OWASP AI Agent Security
Minha proposta de defesa em profundidade se organiza em camadas:
- arquitetura e isolamento,
- identidade e acessos,
- execução e rede,
- ameaças vindas do conteúdo,
- visibilidade operacional.
Essa abordagem também está alinhada ao framework do NIST para IA generativa, onde a gestão de risco não se limita ao modelo, mas cobre governança, operação, monitoramento, controles técnicos e contexto de uso. NIST AI RMF
Três princípios que considero inegociáveis
Se eu tivesse que resumir a parte mais madura da conferência, deixaria em três princípios.
1. Mínimo privilégio e separação de ambientes
Um agente compartilhado, com acessos amplos e fronteiras pouco claras, é uma má ideia.
Por isso eu defendo contêineres, gateways separados, usuários dedicados do sistema e credenciais segmentadas. Segurança real começa quando deixamos de assumir que tudo pode coexistir no mesmo lugar sem consequências.
2. Aprovação humana não substitui sandboxing
Pedir confirmação ao usuário não basta.
Esse é um dos erros de design mais comuns em sistemas agentic: acreditar que um clique de aprovação compensa um isolamento fraco. Não compensa. O controle real está no host, no sistema operacional, na rede, nas permissões e nas ferramentas expostas ao agente.
3. Todo input externo deve ser tratado como potencialmente malicioso
Uma página web, um e-mail, um anexo ou um bloco de texto podem conter instruções ocultas ou maliciosas capazes de alterar o comportamento do agente.
Por isso eu insisto em nunca confiar cegamente em conteúdo externo, manter proteções ativas e redigir segredos em logs e rastros. Segurança de agentes não é um tema teórico; é uma disciplina operacional.
Por que essa conferência importa agora
O que eu quis construir com essa palestra foi uma ponte.
Uma ponte entre entusiasmo e implementação. Uma ponte entre o agente individual e a arquitetura distribuída. Uma ponte entre a promessa de produtividade e a responsabilidade de operar IA com segurança.
É aí que, para mim, está a relevância real dessa conversa. Os agentes já não são apenas uma curiosidade de laboratório nem uma demo bonita para redes sociais. Eles estão se tornando uma nova camada operacional do software.
E se vamos construir essa camada, precisamos fazer isso direito: com identidade, com skills, com topologias pensadas para o mundo real, com custos sustentáveis e com princípios sérios de segurança.
Minha conclusão
Para mim, OpenClaw: do hype à prática não trata apenas de OpenClaw.
Trata de uma forma de pensar a IA aplicada com mais critério e menos espetáculo.
Trata de parar de consumir o futuro como narrativa e começar a operá-lo como arquitetura.
Essa foi a mensagem da minha conferência, e continua sendo a mensagem que mais me importa defender: agentes de IA não têm valor por parecerem inteligentes. Eles têm valor quando são úteis, governáveis, escaláveis e seguros.