IronShell
EntrarComece agora

Capabilities

Memória em três camadas, squad multi-agente, JIT, self-healing, consenso, automação desktop.

Panorama

O IronShell ganha sua profundidade de capacidades através de módulos independentes que cooperam via contratos estáveis. Esta página cobre as capacidades de produção disponíveis hoje, com descrição, casos de uso e números medidos.

Memória em três camadas

A memória do IronShell está organizada em três camadas com ciclos de vida distintos. Cada camada tem circuit breaker próprio e não depende do estado das outras.

Memória episódica

Guarda eventos da sessão corrente e de sessões anteriores, indexados por timestamp, tópico e importância. Roda em SQLite WASM dentro do processo — sem servidor externo, sem dependência de rede. O circuit breaker impede crescimento descontrolado; episódios com menos de 3 usos em 90 dias são podados automaticamente.

Quando usar: você quer que o agente lembre de decisões passadas, de convenções do codebase, de preferências do usuário, entre reinicializações do processo.

Throughput medido: 407 mil operações por segundo em recall de 5 pares KV.

Knowledge Graph

Cristaliza entidades, relações e snippets de código que passaram no teste do kernel e foram usados com sucesso. A busca interna usa BM25-lite com boost por frequência de uso e por descrição completa. Quando o agente precisa gerar código novo, o Knowledge Graph é consultado primeiro — se existe snippet similar, reutiliza; se não, gera novo.

Quando usar: você quer reaproveitamento semântico de soluções que já funcionaram em contextos similares. Especialmente valioso em JIT, quando o agente está compilando código em runtime.

Comportamento: deduplicação automática por descrição, poda de snippets inativos por 90 dias com menos de 3 usos.

Workspace RAG

Busca híbrida sobre os arquivos do projeto, combinando BM25 (keyword), Jaccard (overlap de tokens) e Reciprocal Rank Fusion. O resultado é uma lista ranqueada de trechos relevantes para qualquer query em linguagem natural.

Quando usar: o agente precisa encontrar referências cruzadas no código ou em documentação, sem ter que ler arquivos aleatoriamente.

Throughput medido: 885 buscas BM25 por segundo em corpus de 50 documentos com 8 queries. RRF fusion a 2.977 operações por segundo.

Squad multi-agente

O IronShell embarca 6 agentes especializados que podem ser invocados explicitamente. Cada agente tem prompt de sistema próprio, conjunto de skills permitidas e budget dedicado.

| Agente | Responsabilidade | | --- | --- | | @dev | Implementação. Escreve código novo com foco em corretude. | | @qa | Validação. Executa testes, verifica cobertura, aprova ou reprova. | | @architect | Decisão de design. Avalia tradeoffs e propõe alternativas. | | @pm | Priorização. Quebra features grandes em tarefas menores. | | @analyst | Análise. Lê logs, métricas, dados e extrai insights. | | @sm | Scrum master. Orquestra o fluxo de outros agentes. |

Além dos 6 core, o IronShell tem mais de 1.400 skills descobertas automaticamente via scanner de library. As skills são importadas no formato markdown frontmatter — compatível com o padrão Anthropic Skills e com OpenClaw.

Sovereign Council (modo extendido)

Para decisões críticas, o IronShell suporta um modo estendido de consulta com 7 conselheiros epistemicamente divergentes. Cada conselheiro tem perspectiva própria e credibilidade calibrada por Beta-bayesiana com base em outcomes verificados.

| Conselheiro | Perspectiva | Poder de veto | | --- | --- | --- | | Alinta | Segurança e alinhamento | segurança operacional | | Benedikt | Sistemas distribuídos | escalabilidade | | Chen Wei | Verificação formal | qualidade de código | | Divya | Arquitetura de software | arquitetura | | Elena | Eficiência computacional | escalabilidade | | Fatima | Auditabilidade e compliance | auditabilidade | | Gabriel | Red team e adversarial | resistência adversarial |

Cada conselheiro tem uma distribuição Beta(alpha, beta) por domínio, inicializada em Beta(7, 3) (média 0.70). Acertos incrementam alpha, erros incrementam beta. Anti-gaming: conselheiros que votam sempre com a maioria em mais de 90% dos casos têm peso penalizado em 10%.

Quando ativar: decisões arquiteturais com mais de 100 linhas, mudanças em segurança, gates de fase de projeto.

JIT Skill Compiler

O agente pode compilar e executar código novo em runtime, dentro de um sandbox V8 estrito. O sandbox tem acesso apenas às primitivas JavaScript (Math, Number, String, Boolean, Array, Object, JSON, Date). Não há process, fs, require, I/O, ou acesso ao filesystem.

Fluxo típico:

  1. Agente identifica necessidade de uma função não existente (parser, cálculo, transformação).
  2. Gera o código.
  3. Kernel de segurança audita o código antes de rodar.
  4. Sandbox V8 executa com timeout de 5 segundos.
  5. Se sucesso, resultado é retornado e o snippet é cristalizado no Knowledge Graph.
  6. Se falha de runtime, entra o self-healing loop.
  7. Se falha de segurança, bloqueio terminal — nunca retenta.

Caso de uso típico: "calcule a soma dos valores da coluna X", "parse este CSV específico e retorne JSON", "encontre o maior número primo menor que N". O agente não precisa ter uma skill pré-existente para cada tarefa — ele sintetiza na hora.

Self-Healing Loop

Quando o código do JIT falha com erro de runtime, o loop intercepta stderr, classifica o tipo de erro e aplica uma heurística de correção antes de tentar de novo. Até 3 iterações.

Classes de erro tratadas:

  • syntax_error — correção automática, normalmente ajuste de aspas ou parênteses.
  • reference_error — inserção de null check ou declaração ausente.
  • type_error — coerção explícita ou guard de tipo.
  • timeout — sinal que a computação está muito pesada; abort, não retry.
  • security_blocked — terminal; nunca retenta código bloqueado pelo kernel.
  • runtime_error — tratamento genérico com logging estruturado.

Resultado típico: para erros simples como acesso a propriedade em objeto potencialmente nulo, o loop resolve em 2 iterações. O usuário vê só o resultado final, não o histórico de tentativas.

Byzantine Consensus (PBFT)

Para decisões que envolvem risco alto, os agentes do squad votam via Practical Byzantine Fault Tolerance com quórum de 2/3. Cada voto é assinado com Ed25519, e o resultado só passa com quórum verificado.

Uso típico: deploy em produção, merge em branch protegida, execução de migração irreversível. O agente principal propõe a ação; os 6 especialistas recebem a proposta com contexto completo; cada um vota; se 2/3 aprovam, a ação executa com auditoria.

Propriedade de segurança: mesmo que um agente fique comprometido (LLM alucinando, prompt poisoning), a maioria ainda barra a ação. Manipulação silenciosa do resultado é criptograficamente impossível.

IronDesktop (automação cross-OS)

Automação de aplicativos nativos em Windows, macOS e Linux via nut-js. Cada ação (click, type, scroll, screenshot) passa pelo kernel antes de executar.

Quando usar: interação com apps que não expõem API (legacy desktop, ERP antigo, CAD, software industrial).

Limite: não funciona em sessões RDP remotas. Para isso, use IronRemote.

IronBrowser (automação web)

Wrapper Playwright tipado, cross-browser (Chromium, Firefox, WebKit), com auditoria por ação.

Quando usar: scraping estruturado, testes end-to-end, automação de SaaS, preenchimento de formulários complexos.

Features:

  • Navegação, click, type, extract, evaluate.
  • Screenshot para auditoria visual.
  • Auditoria de scripts executados via evaluate() pelo kernel.

IronRPA (flow engine)

Flows de automação definidos em JSON declarativo, com condicionais, loops, interpolação de variáveis e política de erro por passo.

Exemplo de flow:

{
  "name": "login-and-export",
  "steps": [
    { "id": "open", "action": "navigate", "url": "https://app.example.com/login" },
    { "id": "user", "action": "type", "selector": "#email", "value": "{{EMAIL}}" },
    { "id": "pass", "action": "type", "selector": "#password", "value": "{{PASSWORD}}" },
    { "id": "submit", "action": "click", "selector": "button[type=submit]" },
    { "id": "export", "action": "click", "selector": "#btn-export",
      "condition": { "variable": "EXPORT_ENABLED", "equals": "true" }
    }
  ],
  "onError": "abort"
}

Quando usar: processos repetitivos em múltiplos sistemas, migrações de dados, tarefas de backoffice sem API.

IronVision (computer vision e OCR)

Análise multimodal de telas com duas engines e fallback automático.

  1. Tesseract.js — local, sem API key, funciona offline.
  2. Gemini Multimodal — fallback se Tesseract não instalado ou output de baixa confiança.

Operações suportadas:

  • OCR de screenshots para extração de texto.
  • Template matching para encontrar elementos visuais por imagem de referência.
  • Análise semântica "o que está ativo nesta tela".

Caso de uso: automação de apps legacy sem DOM accessible, validação visual de frontends, extração de dados de imagens de faturas/documentos.

IronPTY (terminal sessions)

Sessões de terminal stateful com auditoria por comando. Navegue diretórios, rode scripts, responda a prompts interativos, sempre com o kernel inspecionando cada comando antes da execução.

Propriedades:

  • Máximo de 100 comandos por sessão (histórico).
  • Fallback para spawnSync quando node-pty não está instalado.
  • Session IDs UUID sem colisão.
  • Runs como processo Node.js — sem privilégios de root.

Channels (canais de comunicação)

O IronShell implementa 8 canais de comunicação nativos, cada um com handler dedicado e assinatura HMAC/timestamp para prevenir replay.

| Canal | Protocolo | Uso típico | | --- | --- | --- | | Telegram | Bot API | Chatbot pessoal, alertas | | Discord | Bot + Webhooks | Comunidade, notifications | | Slack | Bot + Events | Enterprise chatops | | Matrix | Client-Server | Federated chat | | Email | IMAP + SMTP | Processamento de tickets | | MQTT | Pub/Sub | IoT, sensores | | WhatsApp | Cloud API | Suporte cliente | | IRC | Raw TCP | Comunidades legacy |

Governança e qualidade

Cinco módulos de governança ao estilo militar completam o sistema de capacidades.

Lock manager

14 tipos de lock para controlar concorrência em recursos críticos: host:shell, database:write, infrastructure:modify, repository:write, filesystem:write, ai:inference, test:execution, secrets:access, ui:interaction, collaboration:modify, policy:enforce, ml:operations, reasoning:complex, general:mutation.

Propriedades: idempotency keys, TTL por lock, liberação automática no sucesso ou erro.

IronMission

Orquestração de missões como DAG com dependências, idempotência, timeout por passo e política de erro configurável (fail, skip, continue).

IronSemanticGuard

Engine anti-falácia que detecta 6 categorias de armadilha no raciocínio do agente.

  • SPECULATION — afirmações sem evidência.
  • CIRCULAR — raciocínio que depende da própria conclusão.
  • ASSUMPTION — premissas não declaradas.
  • OVERCONFIDENCE — alta certeza sem base.
  • SCOPE_CREEP — resposta fora do escopo perguntado.
  • HALLUCINATION — alta probabilidade de fabricação.

Score 0-100, veredito safe, warn, blocked.

IronGrade

Classificação de qualidade de skills e tools em 5 tiers: OMEGA, DELTA, GAMMA, BETA, ALPHA. Cinco critérios: NanoShield (25 pontos), testes (25), zero-any types (20), JSDoc (15), error handling (15).

IronRisk

Cálculo de risco por Expected Utility com pesos Wardley. Permite escolher entre alternativas em cenários de tradeoff complexo.

Capacidades avançadas

Os módulos abaixo são opcionais, mas expandem o que é possível quando necessário.

Fine-tuning local (IronML)

Pipeline completo para treinar modelos via LoRA em hardware doméstico (GTX 1060 ou superior). Integração com Unsloth. Exporta para GGUF compatível com Ollama.

MCP Client

Cliente do Model Context Protocol para consumir servers MCP externos. Integração JSON-RPC, OAuth 2.1 com refresh de token, tool discovery dinâmico.

Skills marketplace

Mais de 1.400 skills já indexadas, instaláveis via ironshell skill install <nome>. Cada skill passa por verificação de licença, scan de segurança e deduplicação por content hash antes de ser aceita.

ADE (Autonomous Development Engine)

Pipeline de 5 fases para geração de código autônoma: spec → design → implementação → review → merge. Cada fase é um agente especialista com contexto dedicado.

IronForge (roadmap v9.5)

GitHub issue entra, PR sai. Pipeline ADE completo rodando em background, com reviews automáticos pelo @qa e @architect antes de abrir o PR.

Métricas de escala

Para dar ideia do tamanho do sistema em produção atual:

  • 774 arquivos TypeScript no src.
  • 185.122 LOC de código.
  • 6.865 testes em 322 suites.
  • 322 test files, 97,98% coverage em statements.
  • 0 erros TypeScript strict mode.
  • 0 dependências circulares medidas por CrossCodeEval.
  • 100/100 CodeGuard score, Grade A+.

Próximos passos

  • Provedores LLM — SmartRouter, IronBudget, os 14 provedores suportados.
  • Integrações — channels, MCP, skills, API REST em detalhes.
  • Deployment — cenários de self-host, enterprise, air-gapped.
  • Benchmarks — tabelas completas com números reais.