Eu tive o mesmo pensamento, então estive a brincar com isso no nanochat. Por exemplo, aqui estão 8 agentes (4 claude, 4 codex), com 1 GPU cada, a correr experiências no nanochat (tentando eliminar o logit softcap sem regressão). O resumo é que não funciona e é uma confusão... mas ainda é muito bonito de se ver :) Tentei algumas configurações: 8 investigadores independentes, 1 cientista-chefe a dar trabalho a 8 investigadores juniores, etc. Cada programa de pesquisa é um branch do git, cada cientista faz um fork para um branch de funcionalidade, git worktrees para isolamento, arquivos simples para comunicações, evitando Docker/VMs por simplicidade por agora (acho que as instruções são suficientes para evitar interferências). A organização de pesquisa funciona em grelhas de janelas tmux de sessões interativas (como o Teams) para que seja bonito de se ver, ver o trabalho individual deles e "assumir o controle" se necessário, ou seja, sem -p. Mas ok, a razão pela qual não funciona até agora é que as ideias dos agentes são apenas bastante ruins desde o início, mesmo na maior inteligência. Eles não pensam cuidadosamente sobre o design do experimento, executam algumas variações um pouco sem sentido, não criam bases fortes e não ablatam as coisas corretamente, não controlam cuidadosamente o tempo de execução ou flops. (apenas como exemplo, um agente ontem "descobriu" que aumentar o tamanho oculto da rede melhora a perda de validação, o que é um resultado totalmente espúrio dado que uma rede maior terá uma perda de validação mais baixa no regime de dados infinitos, mas depois também treina por muito mais tempo, não está claro porque tive que intervir para apontar isso). Eles são muito bons em implementar qualquer ideia bem definida e descrita, mas não geram criativamente. Mas o objetivo é que agora você está a programar uma organização (por exemplo, uma "organização de pesquisa") e os seus agentes individuais, então o "código fonte" é a coleção de prompts, habilidades, ferramentas, etc. e processos que a compõem. Por exemplo, uma reunião diária de pé pela manhã agora faz parte do "código da org". E otimizar o pré-treinamento do nanochat é apenas uma das muitas tarefas (quase como uma avaliação). Então - dado uma tarefa arbitrária, quão rapidamente a sua organização de pesquisa gera progresso nela?

Com a iminente tsunami de demanda por tokens, existem oportunidades significativas para orquestrar a memória+computação subjacente *exatamente certo* para LLMs. A restrição fundamental e não óbvia é que, devido ao processo de fabricação de chips, você obtém dois pools de memória completamente distintos (de diferentes implementações físicas também): 1) SRAM on-chip que está imediatamente ao lado das unidades de computação, que é incrivelmente rápida, mas de capacidade muito baixa, e 2) DRAM off-chip que tem capacidade extremamente alta, mas cujo conteúdo você só pode extrair através de um canudo longo. Além disso, há muitos detalhes da arquitetura (por exemplo, matrizes sistólicas), numéricos, etc. O design do substrato físico ideal e, em seguida, a orquestração de memória+computação ao longo dos principais fluxos de trabalho de LLMs (pré-preenchimento/decode de inferência, treinamento/ajuste fino, etc.) com o melhor throughput/latência/$ é provavelmente o quebra-cabeça intelectual mais interessante de hoje, com as maiores recompensas (\cite 4.6T de NVDA). Tudo isso para obter muitos tokens, rápido e barato. Pode-se argumentar que o fluxo de trabalho que pode importar mais (decodificação de inferência *e* ao longo de longos contextos de tokens em laços agentes apertados) é o mais difícil de alcançar simultaneamente pelos ~dois campos do que existe hoje (adjacente ao NVIDIA HBM-first e adjacente ao Cerebras SRAM-first). De qualquer forma, a equipe MatX é de grau A++, então é um prazer ter uma pequena participação e parabéns pela captação!

Os CLIs são super empolgantes precisamente porque são uma tecnologia "legada", o que significa que os agentes de IA podem usá-los de forma nativa e fácil, combiná-los, interagir com eles através de toda a caixa de ferramentas do terminal. Por exemplo, peça ao seu agente Claude/Codex para instalar este novo CLI do Polymarket e solicite quaisquer painéis ou interfaces ou lógicas arbitrárias. Os agentes irão construí-lo para você. Instale também o CLI do Github e você pode pedir para navegar pelo repositório, ver problemas, PRs, discussões, até mesmo o código em si. Exemplo: Claude construiu este painel de terminal em ~3 minutos, dos polymarkets de maior volume e a mudança nas últimas 24 horas. Ou você pode transformá-lo em um aplicativo web ou o que quiser. Ainda mais poderoso quando você o usa como um módulo de pipelines maiores. Se você tem algum tipo de produto ou serviço, pense: os agentes podem acessá-los e usá-los? - seus documentos legados (para humanos) são pelo menos exportáveis em markdown? - você escreveu Skills para o seu produto? - seu produto/serviço pode ser utilizável via CLI? Ou MCP? - ... É 2026. Construa. Para. Agentes.