Caso 2 · Encaixe do cérebro OpenAI no androide
Cérebro Multiagente OpenAI ↔ Androide — Mapeamento
Cada camada da arquitetura vira uma peça concreta de software OpenAI e um ponto de contato físico no androide.
Camada Papel Implementação OpenAI (provável) Onde toca no androide
Director Recebe o objetivo em linguagem natural, raciocina, decompõe e escolhe os Managers. Agente planejador via Responses API + function calling; modelo de raciocínio. Consulta a skill memory antes de planejar. Nenhum contato direto — orquestra o resto.
Managers Domínios: navegação, manipulação, tarefa, segurança. Quebram responsabilidades em subtasks. Agentes especializados, um por domínio, cada um com suas tools e prompt próprio. Definem o que cada subsistema do androide precisa fazer.
Execution Traduz subtasks em comandos concretos de baixo nível. Tool-calls determinísticos que passam pela HAL; o LLM escolhe a ação, o código emite o comando. SDK do androide: motores, juntas, atuadores, trajetórias.
Perception Transforma sensores em estado e fecha o loop de feedback. Modelos de visão + Realtime API (áudio/stream) para fusão contínua. Câmeras, IMU, sensores de força, LiDAR do androide.
Skill Memory Guarda e recupera skills validadas; personalização. Vector store (embeddings) — RAG sobre skills. “fazer café” → “fazer o MEU café”. Perfis por usuário e por unidade de androide.
Safety Gate final antes de qualquer movimento. Validadores determinísticos (hard-coded) + um agente-guardrail. Não é só LLM. Limites de junta, colisão, zonas proibidas, botão de emergência.
Princípio crítico: o LLM planeja e decide, mas o gate de segurança e o controle de baixo nível são determinísticos. Nunca se confia o movimento físico só ao modelo — o androide precisa de camadas rígidas de validação entre “a IA quis” e “o corpo fez”.
Mapeamento conceitual — a stack OpenAI é o cérebro; a HAL + validadores determinísticos são a medula que protege o corpo.