Os LLMs já conhecem HTTP. Esse é o substrato todo.
Cada capacidade Hoody é uma chamada HTTP. Um LLM treinado na internet pública já conhece curl, JSON e convenções REST. Sem bridge de SDK. Sem adaptador MCP para escrever. O agente pode operar a plataforma na sua primeira rodada de raciocínio.
HTTP em todo lugar · mais de 100 endpoints por contêiner · arquitetura peer · agentes criando agentes
O protocolo que os LLMs já foram treinados.
Todo GPT, Claude, Gemini e Llama leu milhões de exemplos HTTP durante o pré-treinamento — comandos curl, endpoints REST, corpos JSON, códigos de status. Eles conhecem a gramática nativamente. Hoody expõe a plataforma através dessa gramática para que nada precise ser adaptado.
Sem etapa de geração de SDK
Clientes Hoody não precisam de SDK. O LLM lê a spec OpenAPI ou apenas a documentação, depois emite curl. Funciona com todo modelo — hoje e amanhã.
Adaptadores MCP tornam-se opcionais
O cliente MCP (/platform/mcp) estende o conjunto de ferramentas do agente com servidores de terceiros. Mas a própria plataforma Hoody é acessível via HTTP puro — sem camada de tradução.
OpenAPI é o contrato
Cada serviço Kit expõe /openapi.json. Agentes leem a spec, conhecem os schemas e chamam os endpoints. Autodocumentado por construção.
Debug legível por humanos
O agente cometeu um erro? Olhe o curl que ele gerou. O rastreamento está no mesmo formato que um operador humano escreveria manualmente.
Cada contêiner dá ao agente cem ferramentas ao chegar.
Os serviços Kit expõem ~100+ endpoints HTTP documentados por contêiner. Execução de terminal, operações de arquivo, consultas SQL, automação de browser, implantação de scripts, capturas de tela de display, notificações. Um agente que se conecta a um contêiner Hoody tem acesso programático imediato a tudo que um desenvolvedor humano tem.
Executar comandos, transmitir saída, capturar sessões, exportar histórico
Ler, escrever, pesquisar, compactar, transferir para mais de 60 backends de nuvem
Implantar scripts como APIs HTTP, executar com auth, cachear resultados
Consultar, modificar, introspectar schemas, escritas seguras para concorrência
Navegar, capturar tela, interagir, fazer scraping, preencher formulários
Capturar tela X11, listar janelas, observar estado da GUI
Contêineres são peers. Agentes se comunicam diretamente.
Não há orquestrador central. Um agente no contêiner A pode abrir a URL do contêiner B, ler seus arquivos, executar seu terminal, consultar seu SQLite — desde que tenha a URL e a auth. Sistemas multi-agente emergem do HTTP, não de uma camada de coordenação acima.
Cascata de agentes
O agente A aciona o agente B via HTTP. B faz trabalho especializado, retorna. A hierarquia se forma pela função, não pela arquitetura.
Paralelismo fan-out
O agente A cria 10 cópias de uma tarefa em 10 contêineres. Cada um é um agente independente operando em isolamento.
Cadeia de revisão
O agente A redige código. O agente B revisa abrindo os arquivos de A. O agente C executa testes via POST para exec.
Agentes especialistas
Um agente dedicado ao trabalho de sistema de arquivos. Outro ao banco de dados. Outro ao browser. Eles se comunicam via HTTP, não em processo.
O agente não sugere. Ele entrega.
Configurações legadas de agente param em 'diga ao humano o que executar.' Agentes Hoody executam o comando por conta própria. O caminho de falha é rollback via snapshot, não medo de fazer mudanças — o que muda para que o agente seja realmente útil.
Raciocinar
O agente lê, pensa, planeja — igual a qualquer loop LLM.
Agir
O agente faz POST para terminal / exec / files / sqlite. O comando executa em produção.
Observar
O agente lê a resposta, o código de saída, a mudança no sistema de arquivos, o stderr. Feedback do mundo real.
Recuperar
Algo quebrou? PATCH para um snapshot (/methods/data-state) faz rollback. Seguro para assumir riscos.
Agentes criam contêineres. Contêineres executam agentes.
Como a criação de contêiner é um único HTTP POST, um agente pode criar novos contêineres sob demanda. O sistema multi-agente é emergente — sem orquestrador necessário. Contêineres podem ser workers temporários de curta duração, especialistas de longa duração ou qualquer coisa entre os dois.
Agente decide paralelizar
A tarefa é testar hipóteses em 10 branches. O agente reconhece a oportunidade de fan-out.
POST /projects/ID/containers × 10
Dez novos contêineres, cada um com sua própria instância de agente.
Despacho
Cada worker recebe um branch diferente. Agentes trabalham em paralelo, reportando de volta ao contêiner pai.
Desmontagem
O vencedor continua executando. Os perdedores recebem DELETE. Custo: próximo de zero por contêiner descartável.
Cada chamada HTTP é dado de treinamento futuro.
Quando todas as operações são requisições HTTP, elas são todas capturadas como logs de proxy por padrão. O fluxo de trabalho de um usuário vira um conjunto de dados estruturado de tuplas (prompt, ação, resultado) — sem nenhuma instrumentação. Isso é o que torna a plataforma AI-native, não apenas AI-compatible.
Cada ação nos logs de proxy
Logs de proxy capturam método, caminho, corpo (opcional), resposta. Cada operação é rastreável.
Estruturado por padrão
Requisições e respostas JSON já estão no formato certo para pipelines de fine-tuning supervisionado ou RLHF.
Seus dados, seu treinamento
Logs ficam no seu bare metal. A Hoody não vê nada disso a menos que você exporte.
Infraestrutura que se auto-constrói
Scripts MITM podem gerar documentação, otimizar endpoints ou prever as próximas requisições mais comuns a partir do histórico de logs.
Dê curl a um LLM e ele já sabe como usar.
Entregue ao seu agente uma URL de contêiner Hoody e um token. Ele agora pode executar comandos, escrever arquivos, consultar bancos de dados, criar mais contêineres — tudo a partir do protocolo no qual foi treinado.
Veja também — /platform/ai-gateway para o lado do modelo, /platform/mcp para integração de ferramentas externas, /kit/agent para o runtime do agente.