INTENT AIOS é uma plataforma orientada por intenção para transformar ideias, contexto e sinais de um projeto em execução governada com evidência auditável.
A proposta é simples:
o usuário não deveria precisar pensar em branch, issue, PR, backlog ou detalhes internos de runtime para fazer um projeto andar.
Em vez disso, o INTENT AIOS trabalha para:
- capturar contexto sem perder nuance
- transformar caos em estrutura
- converter intenções em missões executáveis
- executar com governança, isolamento e trilha auditável
- devolver evidências claras sem expor a camada técnica como interface mental principal
Chat quando você quer pensar. Intent quando você quer avançar.
O projeto tem duas camadas complementares:
Intent AIOS: camada de produto, voltada para notebook, contexto, hipóteses, missões e evidênciasAIOS runtime: fundação técnica endurecida, responsável por intake, policy, ledger, budget, sandbox e execução governada
Hoje, a fundação técnica está mais madura do que a casca de produto. O notebook continua sendo a unidade principal da experiência, mas está sendo construído sobre um runtime já endurecido e testado.
flowchart LR
U["User / Notebook"] --> P["Intent Layer"]
P --> G["IntakeGateway"]
G --> CI["ClassifiedIntent"]
CI --> M["Mission"]
G --> IL["IntakeLedger"]
G --> BE["BudgetEnforcer"]
BE --> SB["SQLiteBudgetBackend"]
M --> L2["Lote2Runner"]
M --> L3["Lote3Runner"]
L2 --> RL["Runtime Ledger"]
L3 --> RL
L2 --> EV["Evidence / Artifacts"]
L3 --> EV
EV --> GH["GitHub as Infrastructure"]
O desenho acima resume a tese técnica do projeto:
- a camada humana entra por intenção, não por mecanismo de infra
- o
IntakeGatewaytransforma entrada em contrato verificável - budget, ledger e policy existem para governar execução, não para "enfeitar" o runtime
Lote2eLote3representam modos de execução distintos, ambos sob trilha auditável- GitHub entra como motor operacional, não como interface mental principal
flowchart TD
A["Raw Input"] --> B["Classification"]
B --> C["ClassifiedIntent"]
C --> D["Approval"]
D --> E["Mission"]
E --> F["Budget Reservation"]
F --> G["Capability Check"]
G --> H["Runner Execution"]
H --> I["FINALIZING"]
I --> J["Completed with Evidence"]
G --> X["Security Violation / Denial"]
F --> Y["Budget Rejection"]
H --> Z["Fail-Closed Termination"]
O ponto central aqui é simples: sucesso só existe quando estado, budget, policy, ledger e evidência final batem entre si.
O estado atual do projeto já contempla blocos importantes de execução confiável:
- intake governado com contratos explícitos para
ClassifiedIntenteMission IntakeGatewaypara classificação, promoção, execução e encerramento com proveniência- ledger de intake com hash chain, HMAC e validação de lifecycle
- ledger de runtime com integridade criptográfica e postura fail-closed
- runners separados para:
Lote2Runner: execução geral controladaLote3Runner: mutação estruturada com policy e path constraints
- capability gating deny-by-default
- budget backend persistente em SQLite com controle de concorrência e stale cleanup
- isolamento por tenant, run e intent
- detecção adaptativa de anomalias e containment durável
- rollback seguro com snapshot lógico e trilha append-only
- change control formal com baseline imutável, benchmark offline e promotion gating
- active runtime config canônico para mudanças críticas
- documentação de arquitetura e suíte automatizada de regressão
Alguns princípios são constitucionais no estado atual do runtime:
- Fail-closed: se integridade, autorização ou proveniência falham, a execução não prossegue
- Proveniência forte: intents, missões, receipts e eventos de ledger são vinculados criptograficamente
- Privilégio mínimo: nenhuma execução acontece sem capabilities explícitas
- Governança de budget: slots e quotas são tratados como recurso compartilhado e auditável
- Isolamento multi-tenant: estado, paths, workspaces e artefatos devem respeitar o escopo correto
- GitHub como motor invisível: a camada técnica existe para suportar a experiência, não para virar a interface mental do usuário
| Componente | Papel |
|---|---|
IntakeGateway |
Faz classificação, promoção, execução e encerramento com verificação de proveniência |
ClassifiedIntent |
Contrato de entrada classificado e selado antes da promoção |
Mission |
Contrato aprovado e executável, com integridade criptográfica |
IntakeLedger |
Registro imutável do intake, lifecycle e decisões de governança |
SQLiteBudgetBackend |
Persistência de budget, slots, stale cleanup e enforcement compartilhado |
Lote2Runner |
Execução governada de tarefas gerais, com capability gating |
Lote3Runner |
Mutação estruturada com policy guard, path constraints e enforcement de escrita |
O INTENT AIOS não tenta ser "mais um agente que executa coisas". O diferencial do projeto está em combinar:
- interface orientada por intenção
- execução sob governança real
- evidências auditáveis
- separação clara entre produto, runtime e infraestrutura
- base de segurança forte o suficiente para crescer sem improviso
O projeto está em uma fase de consolidação da governança operacional.
O que isso significa na prática:
- a arquitetura de intake e runtime já é tratada como área crítica
- a segurança operacional está acima de conveniência
- a camada de produto está evoluindo sobre contratos e fronteiras mais claras
- a documentação do repositório já separa com nitidez produto, runtime e legado
O foco recente foi fechar a Fase 6 de endurecimento operacional:
- intake seguro
- lifecycle verificável
- capability gating
- ledger com HMAC obrigatório
- budget persistente
- comportamento auditável em runtime
- trust semântico, taint tracking e prompt injection defense
- anomaly detection e containment fail-closed
- rollback seguro com snapshot formal
- change control com baseline, benchmark e promotion gating
Hoje, o runtime já é forte o suficiente para servir como fundação séria de produto. O próximo passo deixa de ser "blindar o motor" e passa a ser consolidar documentação, operação e evolução de produto sem perder o rigor conquistado.
src/
intake/ -> contratos, gateway, ledger de intake, budget, auth
lote2/ -> runtime de execução geral e ledger associado
lote3/ -> runtime de mutação estruturada e enforcement de paths
tests/ -> suíte de regressão e hardening
docs/
intent/ -> direção de produto e arquitetura
runtime/ -> referência técnica do motor
legacy_aios/ -> material histórico
infra/ -> componentes auxiliares de infraestrutura
scripts/ -> automações e utilitários operacionais
artifacts/ -> saídas e evidências operacionais
Se você está chegando agora no projeto, esta é uma boa ordem:
- Documento-base do produto
- Documento mestre de continuidade
- Mapa da documentação de intent
- Referência técnica do runtime
- Arquitetura de segurança e governança
- Python 3.11+
- Windows, Linux ou macOS
- credenciais e chaves exigidas pelo runtime via
.env
python -m venv .venv
.venv\\Scripts\\activate
pip install -r requirements.txtCopie example.env para .env e preencha as variáveis necessárias.
Para rodar a suíte completa:
python -m pytest tests/ -qSe você quiser um caminho mais direcionado, os testes estão organizados por contratos, runtime e fases de hardening.
Alguns pontos de arquitetura merecem atenção especial:
- Abuse and Budget Controls
- Agentic Control Plane
- Incident Response and Forensics
- Prompt Injection Defense
- Semantic Trust and Taint
- State Machine Abuse Controls
- Tenant Security
- Untrusted File Ingestion
O notebook e a experiência principal de produto ainda estão em construção. A fundação atual existe para permitir que essa camada nasça com:
- contratos de entrada confiáveis
- execução governada
- persistência coerente
- rastreabilidade
- segurança operacional
O objetivo não é criar um executor autônomo solto. O objetivo é construir uma plataforma que una ideia, contexto, missão, execução e evidência sem perder governança.
Este projeto está licenciado sob a MIT License.