Em essência, a API Code define um tipo de canal próprio, criado para tarefas de agentes. A partir de uma conversa, um agente pode criar um canal de código, adicionar as pessoas e os arquivos certos, publicar diferenças de código e prévias, salvar materiais importantes nos favoritos e compartilhar um plano passo a passo e atualizações de status durante a execução. Os canais podem ser arquivados quando a tarefa termina e herdam os recursos existentes do espaço de trabalho para controle de acesso, conformidade e pesquisa. Trata-se de uma camada de integração: o Slack oferece os recursos básicos para que os agentes não precisem recriar do zero interfaces de colaboração, aprovação ou revisão.

Para quem desenvolve, o principal passo é adicionar o Slack Code ao manifesto do agente. O manifesto configura o nome do canal, os critérios de participação, os comandos e as visualizações. Quando identifica que uma solicitação precisa de um espaço de trabalho próprio, o agente cria o canal, convida automaticamente os colegas e as partes interessadas relevantes e publica um plano inicial e os materiais necessários. Durante a execução, compartilha diferenças de código, resultados de testes e marcos; os colegas podem comentar, redirecionar o trabalho ou aprová-lo. Para quem implementa a solução, a recomendação é definir sinais claros para cada etapa do ciclo de vida (abrir, atualizar, solicitar aprovação e arquivar) e ajustar o nível de detalhe das atualizações à atenção das pessoas, para manter os canais úteis.

Uma das escolhas explícitas da API Code é priorizar a visibilidade em vez do sigilo. Os agentes herdam as permissões dos canais e as regras de conformidade de mensagens, oferecendo às equipes de segurança um caminho claro para auditoria sem a necessidade de criar novos sistemas de acesso. Isso é importante para empresas de setores regulamentados e para organizações que precisam rastrear os motivos de uma alteração. Mas a visibilidade também levanta questões de política: quais resultados dos agentes devem ser públicos por padrão? Quando rascunhos temporários devem permanecer privados? Como impedir que materiais confidenciais sejam expostos em um canal amplo? As equipes precisam combinar a API com políticas e filtros adequados ao seu perfil de risco.

Os parceiros de lançamento do Slack demonstram diferentes casos de uso: o Copilot recorre a canais de código quando uma tarefa exige a participação de colegas; agentes de observabilidade podem abrir canais durante incidentes e anexar registros; e ferramentas de implantação podem solicitar aprovações de PR diretamente no canal. Esses exemplos mostram que a API Code não serve apenas para pequenas alterações — ela dá suporte a fluxos de trabalho completos, da triagem à integração do código. Para os fornecedores, a API permite que agentes de marketplace ofereçam uma experiência consistente dentro do Slack, aumentando sua descoberta e reduzindo as barreiras para clientes que querem usar agentes próprios (BYOA).

Tornar público o trabalho dos agentes traz benefícios, mas também pode gerar atritos. As equipes podem sofrer com o excesso de notificações se os agentes publicarem atualizações intermediárias demais. As equipes de governança precisam impedir a exfiltração de dados e aplicar o princípio do menor privilégio. Integrações que dependem de interfaces muito personalizadas ou de estados complexos talvez ainda exijam ferramentas externas. Por fim, os processos de aprovação humana precisam ser bem planejados para não se tornarem gargalos ou simples formalidades. Quem adotar a solução no início deve fazer projetos-piloto, ajustar os limites de notificações e definir regras claras de aprovação antes de liberar permissões amplas aos agentes.