Não é uma demo de agentes conversando. É uma plataforma de orquestração de sistemas multiagentes, projetada, desenvolvida e colocada em produção como produto de software.
Hoje ela possui uma versão gratuita em beta, aberta para uso, e uma versão paga em beta privado, disponível por convite. A plataforma foi desenvolvida em macOS, utilizando Swift, SwiftUI e AppKit, com SwiftTerm para emulação real de terminal e WKWebView para navegação embutida no canvas, e atualmente está na versão 0.24.0.
O problema técnico
Quando deixamos de tratar agentes como simples prompts e passamos a tratá-los como componentes de software, surgem problemas de engenharia bastante diferentes.
A plataforma foi projetada para resolver:
- descoberta e registro de agentes
- definição de contratos de entrada e saída
- decomposição de tarefas
- orquestração de workflows
- execução sequencial e paralela
- gerenciamento de estado e contexto
- comunicação entre agentes
- tool calling
- integração com diferentes LLMs
- tratamento de falhas, timeout e retry
- observabilidade da execução
- persistência de resultados e estado
- controle de custos e consumo de tokens
- extensibilidade da arquitetura
Nem tudo dessa lista está igualmente maduro na v0.24.0. O que já está sólido é decomposição de tarefas, comunicação entre agentes e tool calling via MCP; timeout/retry formal, controle de custos e observabilidade estruturada ainda são lacunas conhecidas do roadmap.
No núcleo existe uma camada de canvas orientado a grafo, nodes conectáveis com relay de texto entre eles, responsável por coordenar o fluxo de dados entre as execuções.
Um fluxo pode ser composto por diferentes capacidades especializadas, por exemplo:
Cada tipo de node define seu próprio comportamento ao receber dados repassados: um terminal injeta o texto recebido no stdin do processo, um post-it acrescenta o texto como anotação, um navegador extrai e abre a primeira URL detectada no texto — o que desacopla os tipos de node entre si sem exigir um formato único de payload.
A camada de modelos não passa por um gateway próprio: o app é agnóstico por natureza, porque cada terminal roda um processo real — Claude Code, Codex, um shell puro, ou um modelo local via Ollama — e a orquestração acontece no nível do texto que entra e sai desse processo, não de chamadas diretas a uma API de modelo.
E produção muda tudo
Uma arquitetura que funciona em um notebook não necessariamente funciona como produto.
Por isso, também precisei resolver:
Resiliência
Não há retry/timeout/circuit breaker sobre chamadas de LLM — o app não fala direto com APIs de modelo. A resiliência aplicada é outra: limite de "hops" para cortar loops infinitos de relay entre terminais conectados nos dois sentidos, e encerramento garantido (SIGTERM) do processo de cada terminal ao fechar seu node, evitando shells órfãos.
Concorrência
Nativa do SwiftUI/Combine: cada terminal roda seu próprio processo e pty de forma independente; buffer de output por node com debounce configurável evita disparar relay no meio de uma resposta parcial.
Observabilidade
Ainda local — logs de console durante o desenvolvimento. Telemetria estruturada, tracing e métricas de uso são o próximo degrau, não algo que já existe hoje.
Persistência
Arquivos JSON locais, um por workspace, com autosave via debounce, guardados em ~/Library/Application Support/Maestria. Sem banco de dados nem serviço externo — coerente com a natureza local-first do app.
Segurança
Sem auth/RBAC: é um app desktop de uso individual, sem superfície multiusuário. O App Sandbox do macOS é desabilitado deliberadamente, para dar aos terminais acesso real ao shell e ao filesystem — decisão consciente de escopo, não descuido.
Deploy
Distribuição como app nativo: build universal (Apple Silicon + Intel), assinado, com autoupdate via Sparkle e um feed de releases público separado do repositório de código-fonte (que permanece privado).
Testes
Hoje a validação é majoritariamente manual: checagem de tipos a cada fase (swiftc -typecheck / xcodebuild) e um cenário de teste dedicado que valida canvas, múltiplos terminais e relay usando um modelo local via Ollama, para não gastar tokens de API a cada rodada. Suíte automatizada ainda é próximo passo.
Avaliação de IA
Ainda não existe uma camada formal de evals/datasets/LLM-as-a-judge. A validação hoje é funcional e manual, testando os fluxos direto no canvas.
E existe ainda uma camada que muitas implementações de agentes ignoram: produto.
Isso significa pensar em:
- versionamento (CHANGELOG + tag a cada fase concluída)
- compatibilidade entre versões (workspaces salvos em versões antigas continuam abrindo depois de mudanças no formato de dados)
- documentação do que foi construído e por quê
- experiência de quem usa o app no dia a dia
É nesse ponto que, para mim, AI Engineering começa a ficar realmente interessante.
Não é apenas escolher um modelo.
É combinar Software Engineering, System Design, Machine Learning, LLMs e Product Engineering para construir algo que possa sair do notebook e operar como software real.
Esse projeto representa exatamente a direção que venho consolidando na minha carreira:
não apenas usar IA.
Não apenas construir agentes.
Mas projetar sistemas de IA.
E, principalmente, colocá-los em produção.