Construa um Copiloto de Suporte que Carrega o Runbook Antes de Chamar uma Ferramenta

Uma demonstração de suporte de IA pode parecer finalizada após responder a uma pergunta e chamar uma API.

A tensão na produção aparece mais tarde: o modelo tem instruções, ferramentas, mensagens de clientes e credenciais no mesmo contexto—mas ninguém pode dizer claramente qual parte autoriza o quê.

Isso não é apenas um problema de IA. É um problema de design de sistemas que se esconde atrás da linguagem natural.

Um copiloto de suporte confiável precisa de pelo menos duas camadas separadas:

• Runbooks explicam como investigar uma classe particular de problema.
• Ferramentas fornecem acesso restrito a sistemas ao vivo.

Pacotes de instruções reutilizáveis—frequentemente chamados de habilidades—se encaixam na primeira camada. O MCP pode se encaixar na segunda camada expondo ferramentas através de um protocolo comum. Eles são complementares, não intercambiáveis.

Este tutorial constrói um pequeno fluxo de trabalho que seleciona um runbook de suporte, o carrega apenas quando relevante, permite diagnósticos somente leitura e produz um pacote de escalonamento para um humano. O objetivo não é suporte autônomo. É uma investigação mais rápida sem transferir silenciosamente a autoridade operacional para um modelo.

A fronteira que estamos construindo

Um pedido de suporte deve passar por esta sequência:

mensagem do visitante
    ↓
normalizar e classificar
    ↓
selecionar um runbook permitido
    ↓
carregar suas instruções completas
    ↓
solicitar ferramentas de diagnóstico aprovadas
    ↓
aplicar política fora do modelo
    ↓
retornar evidências, desconhecidos e um próximo passo proposto
    ↓
humano resolve, responde ou escala

O modelo pode propor uma chamada de ferramenta. Ele não decide se tem permissão para fazer essa chamada.

Essa distinção é mais importante do que se o arquivo de instruções é rotulado como uma habilidade, prompt, playbook ou procedimento.

Comece com um contrato de caso de suporte

Mensagens em linguagem natural são entradas não confiáveis, não instruções operacionais. Normalize-as antes de colocá-las perto de um modelo ou de um registro de ferramentas.

import { z } from "zod";

export const SupportCase = z.object({
  id: z.string().uuid(),
  message: z.string().min(1).max(4_000),
  category: z.enum([
    "disponibilidade",
    "autenticação",
    "faturamento",
    "como_fazer",
    "desconhecido"
  ]),
  appVersion: z.string().max(80).optional(),
  accountRef: z.string().max(120).optional(),
  receivedAt: z.string().datetime()
});

export type SupportCase = z.infer<typeof SupportCase>;

Mantenha a mensagem original, mas rotule-a explicitamente ao construir a entrada do modelo:

function formatUserEvidence(c: SupportCase): string {
  return [
    "<mensagem_do_usuario>",
    c.message,
    "</mensagem_do_usuario>",
    `Versão do aplicativo reportada: ${c.appVersion ?? "desconhecido"}`
  ].join("\n");
}

Delimitadores semelhantes a XML não são uma fronteira de segurança. Eles apenas tornam a estrutura pretendida mais clara. A autorização ainda pertence ao código comum.

Faça a seleção do runbook ser entediante

Carregar todos os procedimentos de suporte em cada conversa cria inchaço de contexto e dá a instruções irrelevantes a chance de interferir. Em vez disso, mantenha um pequeno índice e carregue o runbook completo apenas após o roteamento.

Um índice de runbook pode ser dados simples:

const runbookIndex = {
  disponibilidade: {
    id: "investigar-disponibilidade",
    resumo: "Verifique se uma interrupção reportada é global, regional ou local."
  },
  autenticação: {
    id: "