// conceitos · posicionamento
Por que Okami
Okami não tenta ser só mais uma interface de chat para código. O produto é um harness verificável, multi-canal e versionável que reduz dependência de um único model…
Tese
A vantagem do Okami é transformar comportamento de agente em contrato operacional: tool registry, approval, sandbox, exitCriteria, skills auditáveis, memória versionada e traces. O modelo continua importante, mas deixa de ser o único lugar onde a confiabilidade mora.
Comparativo técnico
| dimensão | Okami | ferramentas típicas |
|---|---|---|
| conclusão | task_complete passa por exitCriteria | muitas vezes depende da resposta final |
| skills | arquivos auditáveis + scan + páginas individuais | prompt/policy menos visível |
| canais | terminal, gateway, API, Telegram, Paperclip | normalmente IDE ou terminal |
| modelo | provider trocável com capability profile | otimizado para um provider principal |
| operação | events, replay, audit, retention e policy strict | logs dispersos ou UI-first |
| design system | skill orienta; ui_gate impõe | frequentemente só instrução textual |
Quando Okami faz mais sentido
- Você quer rodar tarefas verificáveis fora da IDE: CI, cron, bot, API ou Paperclip.
- Você precisa operar com modelos diferentes sem reescrever workflow.
- Você quer evidência de execução, não apenas uma resposta confiante.
- Você precisa impor design system e policy de segurança por contrato.
Quando não é a melhor escolha
- Você quer só autocomplete inline dentro do editor.
- Você não precisa de sessão persistente, canal remoto ou auditoria.
- Você prefere depender integralmente de uma plataforma fechada para execução e logs.