Empresas agent-native

Sponsored by

Do your searches always hit dead ends?

Nearly half of users abandon a search without getting the result they wanted. Instead, they’re stuck in a loop of irrelevant results, slow-to-load articles and contradicting advice.
 
heywa is a whole new way of searching. It gives your result as visual & concise stories, meaning you get answers at a glance. 

And if you want to explore your topic further, you can tap through your search journey without having to re-prompt and start again.

Try heywa for free

Acima temos o anunciante da News dessa semana 🚀 Se puder, clique no link do anunciante acima para deixar seu apoio (é grátis!) ❤️

Toda escrita desse texto foi orquestrada por uma pequena constelação de agentes rodando em paralelo. Não é demo. É operação.

A pergunta não é mais se você usa IA. É se a tua empresa é um lugar onde um agente consegue trabalhar.

Porque a premissa mudou.

Tudo que você faz na frente do pc — ler, escrever, organizar, buscar, decidir sub-rotina — já dá pra automatizar.

O que sobra como trabalho humano não é mais a execução. É o desenho da empresa como ambiente onde agentes são cidadãos de primeira classe.

1. Agent-native não é usar IA. É redesenhar a empresa.

A maioria dos times em 2026 ainda trata IA como plugin. Um ChatGPT aqui, um Copilot ali, um RAG quebrado na intranet. O vocabulário é "adotar ferramenta". A arquitetura é "bolt-on".

Agent-native é outra coisa. É quando cada processo foi reescrito pra ser executável por um agente — e cada ferramenta da stack foi auditada por essa lente.

Karpathy diz que a proporção tá invertendo — 80/20 humano virando 20/80. Não no número de cliques, mas em quem raciocina primeiro. Você deixou de escrever código. Passou a escrever o contexto que produz o código.

O trabalho do founder, nesse cenário, deixa de ser fazer mais coisas.

Vira projetar o sistema que faz.

2. Os quatro eixos que toda empresa agent-native resolve

Na prática, projetar esse sistema é decidir quatro coisas com clareza:

Contexto compartilhado. Teus agentes precisam de um segundo cérebro que saiba dos teus projetos.

Não chat history — arquitetura. Na primeira versão dos meus agente eu tentei o approach de único agente monolítico guardando tudo no mesmo lugar. Ele esquecia contexto entre sessões e eu refazia o mesmo prompt quatro vezes por dia.

Só depois que separei memória durável (fatos que não mudam) de perfil de usuário (preferências estáveis) e de resumo de sessão (reciclável) — três arquivos, três taxas de mudança diferentes — o sistema virou alguém com quem dá pra trabalhar.

Quando o contexto é compartilhado, você para de explicar de novo.

Long-running vs short-running. Hermes Agent e Openclaw rodam 24/7, com cron, gateway, MCP e memória persistente.

Claude Code roda em burst — atômico, auditável, zero estado. Os dois são essenciais, mas servem coisas diferentes. A regra que aprendi na marra: usar o nível mais simples que resolve o problema. Não força um always-on a fazer o que um skill de Claude Code resolve em 20 segundos.

Swarm vs AGI. Muitos agentes especializados (swarm) contra um agente com todo contexto (AGI). Essa é a decisão de qual seu approach para resolver o problema. É melhor um especialista com todo contexto na mesma janela? Ou um “enxame” de agentes que irão trazer pontos de vista divergentes para serem analisados?

Cada tarefa exige um tipo de orquestração. Mas lembre-se: orquestração custa caro.

A Anthropic publicou um relato de engenharia onde a arquitetura orchestrator-worker superou single-agent em mais de 90% — ao custo de ~15× em tokens.

Swarm não é gratuito. É uma escolha de arquitetura com tradeoff explícito.

Custo e modelos locais. O eixo menos sexy é o mais decisivo. Ferramentas genéricas tipo god-MCP perdem de lavada pra purpose-built tooling.

Aqui na Olympus, o wrapper chrome-devtools-axi resolve 100% das tarefas de browser a $0,074 por task — contra $0,101 de um MCP equivalente.

Rodar modelos locais pra subtasks determinísticas (parsing, extração, formatação) libera API budget pra onde acurácia importa de verdade.

3. Como auditar se tua stack é agent-friendly

Pega qualquer ferramenta da tua empresa — Notion, Slack, teu ERP, teu CRM — e passa pelas três perguntas:

1. Ela expõe MCP ou CLI? O MCP virou padrão de facto: 97 milhões de downloads por mês, mais de 10 mil servers vivos, adotado por OpenAI, Google, Microsoft e AWS em 16 meses. A Forrester projeta que 30% dos SaaS empresariais vão shipar MCP próprio em 2026. Se tua ferramenta não tem nem MCP nem CLI, ela é candidata a substituição antes de 2027.

2. A doc dela é legível por agente? Markdown estruturado, exemplos concretos, --help útil, schemas tipados. Documentação pra humano com screenshot de dashboard não serve pra agente.

3. Ela é extensível? Favoreça ferramentas que você pode customizar e adaptar ao seu workflow com facilidade. Ferramentas opensource ou que expõe formas claras de customização (como obsidian) são suas amigas nessa hora.

Três "não" e você tem um gargalo na stack. Três "sim" e você tem uma ferramenta que multiplica por dez.

4. O que isso parece na prática (Olympus hoje)

Não é aspiração. É o que tá em operação diária:

• + 15 Agentic Teams no vault — editorial (Olympus News), infra (Hermes, OpenClaw, manunteção de VPS e sites) além de especialistas nos projetos que executamos. Cada area ou projeto da empresa ganha seu time agêntico.

• 32+ skills compondo operações atômicas — newday e endday encerram o dia; review-agent-hooks faz agentes observarem agentes e extrair learnings para a próxima sessão.

• CLIs (chrome-devtools-axi, gh-axi, obsidian cli, browser harness e etc) como camada agent-ergonomic sobre SaaS que não nasceram agent-friendly.

Cada peça é substituível. Cada decisão é auditável. O humano entra no loop estratégico, não na execução braçal.

Não é sobre ter mais ferramentas. É sobre cada ferramenta saber conversar com o próximo agente que vai rodar.

A empresa do futuro não tem mais gente fazendo tarefa. Tem gente desenhando o ambiente onde a tarefa se faz sozinha — e auditando o que sai do outro lado. 

Essa é a vaga que tá aberta pros próximos cinco anos.

Sua missão para os próximos 7 dias

1. Escolha um processo da tua semana — aquele que você faz toda segunda. Escreve o SOP dele em markdown como se fosse pra um agente. Se você não consegue escrever, o processo não existe.

2. Audite uma ferramenta da tua stack. Pega a que tu mais usa. Ela tem MCP? CLI? Docs legíveis? Se nenhuma das três, marca: candidata a substituição em 2026.

3. Spawna teu primeiro always-on. Pode ser um Hermes, um OpenClaw, ou um cron simples disparando um Claude Code recorrente. O importante é ter um agente que já sabe dos teus projetos quando tu senta pra trabalhar.

Conteúdos recomendados

• Artigo: From Memo to Movement — Shopify's Cultural Adoption of AI — o memo do Tobi um ano depois, agora virado playbook operacional.

• Engineering: How we built our multi-agent research system — Anthropic — orchestrator-worker vence single-agent em 90%+, com tradeoff de custo explícito.

• Roadmap: The 2026 MCP Roadmap — a infra que torna agent-native mecanicamente possível.

Forte abraço,
Equipe Olympus