Instacart abriu o código-fonte do Blueberry, um agente de triagem de incidentes nativo do Slack. Em abril de 2026, processou 25.000 passagens diagnósticas em 270 canais, entregando hipóteses de causa raiz em uma média de três minutos por alerta. A empresa o construiu para resolver o verdadeiro problema nos primeiros minutos de qualquer incidente: não diagnóstico, mas coordenação. As equipes gastam esses minutos se perguntando se um deploy causou, qual é a amplitude do impacto e o que realmente está acontecendo.
Blueberry opera dentro da thread do Slack onde a equipe já está trabalhando. Quando um alerta é disparado — página auto-acionada, @mention ou acompanhamento em thread ativo — o sistema lança dez suagentes em paralelo. Um tem como alvo conhecimento interno: postmortems, runbooks, incidentes anteriores. Os outros coletam sinais ao vivo simultaneamente: histórico de deploy, estado de feature flag, propriedade de serviço, logs de erro, verificações de anomalias. O tempo decorrido é limitado pelo coletor mais lento, não pela soma. O resultado chega à thread antes que a maioria das equipes termine de se montar.
A arquitetura tem três camadas explícitas. A entrada é seletiva: Blueberry monitora eventos de thread do Slack e filtra antes de enfileirar. A camada de gerenciamento de trabalho é uma fila durável com suporte a Postgres, não em memória. Se um worker falhar no meio de uma passagem durante um deployment contínuo, outro pega do estado persistido. A camada de processador resolve propriedade de canal, carrega um perfil de equipe e monta os endpoints MCP corretos antes que o agente acesse ferramentas. Três superfícies MCP são costuradas: um MCP em processo para auxiliares locais rápidos e com estado; um servidor MCP compartilhado independente para análise de deploy e busca de dependências; e MCPs remotos hospedados em equipe que permitem que equipes individuais exponham fontes de dados proprietárias sem tocar o núcleo.
A precisão foi a função forçante do design. A precisão diagnóstica do Blueberry subiu da faixa dos 60% para a faixa dos 90% altos após enraizá-la com 14 anos de histórico de incidentes da Instacart. A empresa reportou taxa de sucesso de workflow de 99,9%, 58.000 dispatches de ferramentas MCP em um único mês, e aproximadamente 60 perfis de equipe. Um exemplo concreto: Blueberry triou automaticamente falhas de teste E2E em staging e identificou a causa raiz — uma mudança de código deployada antes de sua migração de banco de dados, acionando um erro de ORM em um atributo enum não declarado — antes do canal de incidente ser formado.
A autoridade é deliberadamente restrita. Blueberry gera hipóteses e expõe evidências; engenheiros retêm todas as decisões de remediação. Sem mudanças de produção automatizadas. O CTO Anirban Kundu e a VP de Engenharia Siby Alappatt enquadraram o sistema como um multiplicador de força para julgamento humano, não uma substituição. Cada passagem diagnóstica registra seu traço de raciocínio, criando tanto um loop de aprendizado quanto um registro de auditoria.
Para arquitetos avaliando adoção, a parte difícil é o corpus. Quatorze anos de histórico de incidente estruturado é o que moveu a precisão de 60% para 90%. Equipes sem esse corpus começarão mais baixo e precisarão de investimento deliberado em documentação de incidentes antes que o enraizamento tenha efeito. O design MCP de três camadas é a abstração certa: equipes montam fontes de dados internas sem fazer fork do núcleo e dimensionam investigadores pesados independentemente. A fila com suporte a Postgres é a escolha correta para qualquer sistema de plantão que deva permanecer vivo através de suas próprias falhas de infraestrutura.
Blueberry é avaliável agora. O lançamento de código-fonte aberto permite que você mapeie custo de integração em relação ao seu stack do Slack e observabilidade esta semana, mas reserve tempo para construir o corpus de histórico de incidentes antes de esperar precisão dos 90%.