A maioria das ferramentas de feedback deixa você "configurar regras": preencher condições, escolher ações, clicar em salvar. Funciona, mas há um teto — regras são estáticas, o negócio não para de mudar e um processo que você configurou logo fica para trás. Um dos eixos de diferenciação do Loopback é elevar a "configuração" a "evolução": é isso o Coding Loop (também chamado de modo Builder).

De "configurar regras" para "descrever um objetivo"

Ao criar um fluxo de trabalho, você não precisa clicar em um monte de menus suspensos de condição. Você descreve o objetivo em linguagem simples — por exemplo, "negativo relacionado a reembolso → atribuir ao time de pagamentos e rascunhar um pedido de desculpas" — e clica em "Gerar rascunho"; o rascunho aparece no chat com a IA à direita. Dali em diante, você o refina na conversa:

  • Clique em "Editar" para alterá-lo em linguagem natural, por exemplo "considerar também notas abaixo de 3 estrelas".
  • Clique em "Avançar" para entrar na revisão prévia.
  • Quando ele passar, clique em "Publicar" para ativá-lo.

Você e a IA estão escrevendo juntos uma lógica de tratamento, não preenchendo um formulário. É daí que vem o nome "Coding Loop" — iterar sobre um processo do mesmo jeito que você iteraria sobre código, só que em linguagem natural.

Duas barreiras antes de entrar no ar

Um processo executa ações automaticamente, então há uma revisão antes de ele entrar no ar:

  1. Verificação de dependências: um canal que o processo precisa notificar (o Feishu, digamos) ainda não está conectado? Ele sugere que você o conecte primeiro, descarte essa etapa ou troque por um canal já conectado.
  2. Reexecução de impacto: as ações que rodarão automaticamente (atribuir / escalonar / fechar / mudar a prioridade) exigem sua autorização explícita, e você recebe uma reexecução sobre os últimos 30 dias de histórico — se esse processo já existisse, quantos itens ele teria correspondido e quantas ações teria disparado. Assim, você julga se o alcance é razoável antes de entrar no ar.

Limites rígidos de segurança

"Evoluir" não significa "automação sem supervisão". O sistema tem algumas restrições que nunca podem ser cruzadas:

  • Nada de respostas externas totalmente automáticas — um rascunho de resposta precisa ser confirmado por uma pessoa antes do envio.
  • Nada de fechar um P0 automaticamente.
  • Mantenha cada processo com 1–4 regras focadas; amontoar toda a sua lógica em um único processo é desaconselhado.

Um processo no ar pode ser pausado / retomado a qualquer momento; continuar editando cria uma nova versão, a versão antiga é arquivada automaticamente e apenas uma versão de um mesmo processo fica ativa por vez.

Por que as arquiteturas tradicionais não preenchem essa lacuna

Antes de existirem agentes de código, fazer um processo iterar sobre si mesmo significava ou um time de engenharia escrevendo scripts (não reaproveitáveis, e você precisa alocar gente para isso) ou simplesmente não dava para fazer. O SaaS tradicional de tickets é arquitetado em torno de "pessoas configurando regras" e não consegue acrescentar a camada em que "a IA escreve por você e continua aprendendo". O Coding Loop produtiza "a flexibilidade de construir seus próprios scripts": flexível, mas sem precisar de um time de engenharia dedicado à manutenção.

Os planos diferem na concorrência do loop do Builder (o Pro permite 1 execução simultânea; o Max é ilimitado). O jeito mais rápido de experimentar é começar um teste gratuito e aproveitar um teste do Max de 7 dias — o teste te dá o loop do Builder completo. Você também pode começar lendo Modelos de fluxo de trabalho para aprender o caminho a partir de um modelo.