O motor de integrações
É o caminho pelo qual o agente age em serviços de terceiros — e-mail, agenda, arquivos, mensagens — usando a conta que a pessoa autorizou. Conectar exige um clique humano.
O motor de integrações
Camada funcional
O motor de integrações é o caminho pelo qual o agente age em serviços de fora — e-mail, agenda, arquivos, mensagens — usando a conta que a pessoa autorizou. Conectar é um ato humano: o agente pode pedir, a autorização é sempre um clique de alguém.
Catálogo vivo, não lista fixa
A conexão aceita qualquer serviço devolvido pelo catálogo, validado ao vivo em vez de conferido contra uma lista escrita no código. Consequência: serviço novo aparece sem precisar de uma nova versão da plataforma.
O mesmo vale para a leitura de estado: a plataforma devolve todos os serviços que a pessoa conectou, não apenas os de uma lista curada.
Dois alcances de conexão
| Alcance | Uso |
|---|---|
| Da pessoa ou da organização | inicia o fluxo de autorização |
| Para um agente específico | depois da autorização na conversa, vincula aquela integração ao agente |
O segundo existe para o fluxo dentro do chat: a pessoa autoriza numa janela e a plataforma anexa aquela integração ao agente com quem ela está falando.
O espelho local de conexões
Perguntar ao motor de integrações a cada desenho de tela custaria uma lentidão inaceitável. Por isso existe uma cópia local do estado, atualizada nos três momentos em que ele muda:
- Quando a autorização volta bem-sucedida.
- Quando alguém desconecta pelo painel.
- Quando o próprio motor avisa que algo mudou.
O espelho guarda ainda uma quarta coisa, que nenhum desses três momentos produz: o registro de que o provedor recusou a credencial. Quando a pessoa revoga o acesso direto no provedor (no Google, por exemplo), nada disso acontece — nenhum aviso chega, e o espelho continuaria dizendo "ativo" para sempre.
Como o agente usa as ferramentas
As ferramentas das integrações não ficam carregadas no catálogo do agente. O caminho é em dois passos: descoberta semântica (que retorna os identificadores e os esquemas já embutidos) e execução em lote (várias ações independentes numa chamada só).
O motivo é economia de contexto: carregar o catálogo inteiro, com mais de mil serviços, consumiria o espaço útil do agente sem que ele use quase nada daquilo.
Mensagens de erro: uma regra de produto explícita
Quando algo falha aqui, a mensagem não fala em nome de fornecedor: fala no motor de integrações, aponta a causa e o caminho de correção. É regra escrita, não estilo — quem lê não tem por que conhecer o encanamento, e um nome que ela não reconhece só atrapalha.
E há um caso concreto por trás: a mensagem genérica anterior fazia o agente insistir, achando ser uma instabilidade passageira. Hoje os motivos são tipados: sem chave, sem integrações habilitadas, sem conexões ativas, a conta de quem conversa precisa reconectar, ou indisponibilidade temporária — este último explicitamente marcado como passível de nova tentativa.
Erro bom não é só informativo: ele diz ao agente se vale tentar de novo.
O que dá para fazer
| Ação | Onde |
|---|---|
| Ver o catálogo de serviços | painel e API |
| Ver as contas conectadas e o estado de cada uma | painel e API |
| Conectar e desconectar | painel |
| Vincular uma integração a um agente | painel e conversa |
| Receber eventos do provedor | webhook da plataforma |
GitHub App
A organização instala um aplicativo do GitHub, escolhe repositórios e pessoas vinculadas, e o agente passa a clonar, ler, criar branch e abrir pull request.
Saúde da conexão, reconexão e desconexão
Uma integração pode morrer sem avisar ninguém. A pessoa entra no provedor (Google, Microsoft) e revoga o acesso por lá. A conexão deixa de existir do outro lado — sem que nada…