agentes de back-office
Agentes de IA que limpam as suas filas, no ar em 14 dias
Alguém na sua empresa lê um chamado, abre três sistemas, copia campos entre eles e escreve uma observação. Esse é um trabalho que um agente faz bem, e é o que construímos: chamadas tipadas para Salesforce, SAP, Jira, o seu AS/400 ou a sua própria API, um passo de aprovação em tudo que escreve e um log por decisão mostrando o que ele leu e por que agiu. O primeiro fluxo leva quatorze dias, e o segundo é mais rápido porque os adaptadores já estão lá.
14 dias para o primeiro fluxo; o segundo é mais rápido porque os adaptadores já existem
O script de RPA está riscado porque ele quebra no dia em que um fornecedor move um botão. Os adaptadores passam por APIs, e onde não existe API a gente constrói uma.
Fila manual
Pessoas triando chamados, copiando entre sistemas e seguindo um runbook que vive como PDF.
- ticket queuehumans triage
- copy-paste between systemsmanual
- runbook.pdftribal knowledge
- RPA scriptbreaks on redesign
Agente com portão
Um agente, adaptadores tipados, um passo explícito de aprovação, uma linha de auditoria por decisão.
- agentGo · tool calls
- system adapterstyped
- human approvalexplicit gate
- audit trailper decision
14 dias para o primeiro fluxo; o segundo é mais rápido porque os adaptadores já existem
Como o trabalho anda
- 01dias 1–2
Escolher o fluxo pela aritmética
Volume vezes minutos por caso, menos os casos que ainda vão precisar de uma pessoa. Fazemos essa multiplicação com você no primeiro dia e começamos pela fila que se paga mais rápido.
- 02dias 2–5
Escrever os adaptadores
Chamadas tipadas para os seus sistemas, com os modos de falha tratados: limites de taxa, registros escritos pela metade, o endpoint que devolve 200 com um erro dentro do corpo.
- 03dias 5–10
Rodar em modo sombra
O agente propõe, uma pessoa decide, e cada discordância volta para o conjunto de avaliação. O trabalho de ninguém muda ainda e você ganha um número de acerto real sobre os seus casos.
- 04dias 9–14
Abrir o portão uma ação por vez
Ações com histórico limpo e raio de estrago pequeno viram automáticas primeiro. As outras continuam sob aprovação pelo tempo que você quiser, inclusive para sempre.
O que a plataforma faz e o que uma pessoa faz
| O que a plataforma faz e o que uma pessoa faz | Quem faz | Notas |
|---|---|---|
| Ler o runbook e o histórico de chamados | Plataforma | Incluindo os casos tratados contra o runbook, que são justamente os interessantes. |
| Decidir o que o agente pode fazer sem perguntar | Engenheiro | Recomendamos por tipo de ação. Você assina, por escrito, antes de rodar. |
| Construir os adaptadores | Os dois | Gerados a partir do contrato da API e depois corrigidos por uma pessoa contra o que a API faz de fato. |
| Julgar as discordâncias do modo sombra | Os dois | Automático onde o registro mostra o desfecho, humano onde dois dos seus especialistas discutiriam. |
| A trilha de auditoria | Plataforma | Entradas, ferramentas chamadas, decisão, quem aprovou. Uma linha pesquisável por caso, guardada tenha a resposta sido certa ou errada. |
| Caminhos de escalonamento | Engenheiro | O que o agente faz quando está inseguro e quem pega o caso às seis da tarde de uma sexta. |
Quem está por trás dos agentes
Dezenas de migrações e mais de dez anos ligando sistemas que nunca foram feitos para conversar entre si: SAP, Salesforce, Jira, Dynamics, um AS/400, um endpoint SOAP de 2006, um CSV largado num servidor FTP toda noite. Agente é a coisa mais nova que construímos. A integração embaixo dele é a mais antiga, e é ela que decide se algo disso funciona.
A prova é o modo sombra, e ele vem antes do compromisso. O agente roda contra a sua fila real, propõe, e uma pessoa decide. No fim você está com um número de acerto medido nos seus próprios casos.
Perguntas que engenheiros fazem
- Em que isso difere do RPA que já compramos?
- RPA dirige a interface, então quebra em um redesenho e não entende nada do caso. Um agente chama APIs e consegue tratar o chamado que não segue o script, que é exatamente onde a sua equipe passa o dia. A troca é que RPA é determinístico e um agente não é, e é por isso que existem o portão e o conjunto de avaliação.
- O que impede ele de fazer algo caro?
- Ele não pode chamar uma ferramenta que não recebeu, e as ferramentas que escrevem ficam sob aprovação por padrão. O raio de estrago é uma decisão de projeto tomada por tipo de ação, antes de qualquer execução, e está no documento que você assinou.
- Como sabemos que ele está certo?
- Dias de modo sombra contra a sua fila, um conjunto de avaliação montado a partir das discordâncias e um log por decisão que você abre quando alguém reclama de um caso específico.
- Vocês precisam dos nossos dados para treinar?
- Sem fine-tuning por padrão. O agente lê o que precisa no momento do caso, e o que ele leu está no log. Se depois você quiser um modelo treinado no seu histórico, isso é uma decisão à parte, com papelada própria.
- O que acontece quando mudamos um sistema com que ele conversa?
- O adaptador é tipado, então uma mudança de contrato quebra o build em vez de falhar em silêncio na produção no fechamento do mês. Essa é a maior parte da razão de escrevermos adaptadores em vez de deixar um modelo improvisar chamadas HTTP.
Mande uma fila
Descreva o trabalho como uma pessoa faz hoje, incluindo o passo em que ela confere alguma coisa. Quantos casos por mês e quanto tempo leva um. Esses dois números e um dia bastam para dizermos quanto isso economizaria.
O formulário pergunta o volume de casos e o tempo de tratamento. Esses dois números decidem quase tudo.