Especialização · Integrações e automatizações

Os vossos sistemas a falar entre si, sem que alguém volte a introduzir os mesmos dados.

Ligamos o sistema de marcações, a loja, o CRM, as folhas de cálculo e os canais de mensagens, para que um agente ou uma regra agendada possa ler e escrever neles em tempo real. As chaves ficam no servidor, as ferramentas têm limites escritos e cada integração é testada também no caso de o outro sistema falhar.

Fale sobre um projeto

Já construídoIntegrações próprias, escritas e executadas, medidas hoje em código: o conector para o sistema de marcações Altegio (946 linhas, com seis ferramentas expostas ao agente), o conector de CRM amoCRM (2.888 linhas na plataforma de mensagens, mais 12 funções de servidor na plataforma vocal), Bitrix24 (903 linhas, mais 4 funções), Google Sheets (615 linhas, mais 10 funções e uma conta de serviço dedicada), o catálogo vivo sobre a loja (serviço de plataforma, 318 linhas), notificações de lead no Telegram (1.776 linhas), SMS via Infobip com limites antiabuso, automatizações agendadas (1.088 linhas) e o canal de chat de uma plataforma local de anúncios (2.459 linhas). Em execução, o agente pode chamar 15 tipos de ferramentas internas, além de ferramentas por webhook e ferramentas com código próprio executado em isolamento.

Uma integração não é um logótipo numa página. É a resposta a uma pergunta muito concreta: este sistema pode ser lido e escrito em tempo real, por quem, com que direitos, e o que acontece quando não responde? Por isso, a nossa primeira pergunta em qualquer integração não é “com que API”, mas “que gate público tem”. Às vezes, a resposta muda completamente o custo do trabalho: as lojas em WooCommerce, por exemplo, expõem publicamente uma API de loja que não pede nenhuma chave de consumidor, portanto um novo cliente liga-se apenas com o endereço do seu site — não com credenciais que tem de gerar, enviar e depois rodar.

Na nossa plataforma de mensagens, uma ferramenta que o agente pode chamar durante a conversa tem um de três tipos: chamada a um webhook, código próprio executado de forma isolada, ou uma ferramenta interna da plataforma. As ferramentas internas são as que preferimos, porque mantêm as chaves fora da base de dados: hoje são quinze, desde a leitura de uma página e a escrita numa folha de cálculo, até à disponibilidade e criação de uma marcação, ao envio de um SMS e à interrogação do catálogo de produtos.

A diferença entre uma integração que se mantém e uma que se rompe está quase sempre em pequenos detalhes, encontrados no terreno. O sistema de marcações não devolve nada se perguntar os horários de um especialista para um serviço que ele não faz — o serviço e o especialista viajam sempre juntos. O mesmo sistema responde com recusa se o pedido vier com o cabeçalho predefinido da biblioteca HTTP, por isso cada pedido tem de se identificar explicitamente. Uma loja pode reportar preço zero para produtos com variantes, e uma pesquisa com palavras vazias devolve todo o catálogo. São dez desses detalhes por integração, e nenhum está na documentação.

Por cima das integrações estão as automatizações: regras que são executadas ao longo do tempo, não a pedido de alguém. No nosso caso, são agendadas com um programador em processo — retoma de conversas sem resposta, a primeira mensagem para um novo contacto, colocar em pausa e reiniciar o agente após o horário de trabalho — cada uma com contadores próprios, para se ver quantas execuções houve, quantas mensagens foram enviadas, quantas foram ignoradas e porquê. Uma automatização sem contador é uma automatização sobre a qual você não pode dizer se funciona.

Automação transparente — integrações que podem ser verificadas · vídeo em romeno, com legendas e transcrição em português

A transcrição completa

Vamos entrar diretamente no assunto. Hoje vamos dissecar as realidades técnicas e, sinceramente, muitas vezes ignoradas, da automatização por assistentes baseados em inteligência artificial. Vamos focar-nos numa abordagem super pragmática da plataforma iCat.md desenvolvida pela Mega Promoting. Hoje não temos promessas de marketing e, com certeza, não temos conceitos vagos. Estamos a falar de uma plataforma em produção direta, com funcionalidades explicadas diretamente a partir da arquitetura da base de dados. Então vamos ver como é, de facto, a automatização totalmente transparente. A agenda desta análise é simples e direta ao ponto. Passamos pelo problema do tempo, pela mecânica da tecnologia, por um caso real, pelos limites claros do sistema, pela gestão dos dados e pelos próximos passos. Começamos pela primeira secção, o problema do tempo.

Vocês todos conhecem aquela pergunta extremamente frustrante? Porque é que uma equipa inteira de suporte perde horas boas, dia após dia, a escrever à mão respostas para exatamente as mesmas cinco perguntas? A informação já existe no site da empresa, mas, mesmo assim, os clientes continuam a pedir os detalhes repetidamente. E é exatamente isso que está no centro do nosso problema. Sem uma solução técnica adequada, todos estes pedidos repetitivos simplesmente entopem a mensageria direta, não importa se é Instagram ou Messenger. Como consequência, as respostas atrasam-se muito para os clientes que têm mesmo um problema complexo, os pedidos perdem-se no mar de mensagens e todo o processo de suporte torna-se praticamente uma caixa negra que não se pode nem verificar nem medir.

Parte dois. Como funciona, de facto, a tecnologia por baixo do capot? Então é isto. A configuração da plataforma baseia-se em quatro passos muito lógicos. Primeiro ligamos os canais de comunicação usando código próprio. Depois é indexada toda a base de conhecimento. Segue-se a ligação das ferramentas que podem executar ações nos vossos sistemas existentes. E no fim, e este detalhe é vital, configura-se um percurso claro registado diretamente na base de dados através do qual o bot entrega a conversa a um operador humano. Tudo é um sistema visível e perfeitamente configurável. Agora, um aspeto absolutamente fascinante. Não estamos a falar de plânio daqui. Estas são definições extraídas diretamente do esquema da base de dados. Quando o assistente precisa de uma resposta, ele usa a chamada pesquisa híbrida.

Por defeito, o algoritmo extrai 5 fragmentos de texto, aplica um limite rigoroso de similaridade de 0-70 e atribui 30% de importância à correspondência exata das palavras. Tudo é processado através do modelo Text Embedding 3 Small. Na prática, o sistema transforma palavras em conceitos matemáticos para captar o contexto exato. As respostas não são adivinhação, mas matemática pura. Reparem neste número. 15. É um limite técnico absoluto no sistema. Representa o tempo máximo, em segundos, alocado para correr qualquer ferramenta ou pesquisa. Se uma integração externa demora mais do que isso, digamos que precisa de 40 segundos, não a podemos deixar no fluxo vivo da conversa. Ela tem de ser processada de forma assíncrona, caso contrário quebraria completamente o ritmo natural do diálogo.

E há mais uma coisa. As pessoas escrevem no chat em rajadas, não é? 2, 3, 4 mensagens curtas enviadas uma atrás da outra. Para não enlouquecer o sistema, existe um tampão de concatenação de 15 segundos. Tudo o que entra nesta janela cola-se e torna-se um único pedido claro. Além disso, em plataformas como a Meta, onde às vezes vocês se deparam com mensagens duplicadas enviadas por erro, o sistema aplica um filtro de memória de 120 segundos sobre o ID da mensagem. Assim, o cliente recebe uma única resposta coerente, não 3 falsos alarmes. Secção três. Vamos ver um caso real. Temos este cenário clássico de e-commerce. Temos uma loja online, com um catálogo impecável no site, mas que recebe uma avalanche de mensagens privadas no Instagram e Messenger?

Ainda há stock? Qual é o preço? Aqui a integração foi feita de forma elegante, ligando o assistente diretamente à interface pública Store API da WooCommerce. Sem complicações de segurança, o catálogo vivo da loja foi simplesmente colocado nas mãos do assistente. Só que aqui entra a realidade técnica de cada plataforma, mesmo sob a mesma empresa, como a Meta. No Messenger, o assistente pode mostrar-vos carrosséis de produtos fantásticos. No Instagram, o bot vai responder-vos apenas com texto e, no máximo, uma imagem simples. Porquê? Simplesmente porque a Meta não suporta esses modelos genéricos no Instagram. O assistente tem de jogar exatamente pelas regras do canal onde está. Aqui está o ponto crítico. O que acontece quando o bot é ultrapassado pela situação?

Bem, na base de dados a conversa tem estados explícitos. Quando uma pergunta sai da zona de conforto do catálogo, o fio da conversa passa imediatamente do estado bot para o estado humano. E a parte genial é que o sistema contabiliza o tempo em que o operador humano responde, marcando tudo de forma clara, status OK, aviso ou prazo ultrapassado. Todo o contexto é passado ao humano, sem que absolutamente nada se perca pelo caminho. Secção A4 Limites do sistema Porque transparência significa sabermos o que não pode fazer. Há alguns limites firmes que temos de aceitar. Vocês não podem enviar mensagens proativas no WhatsApp se tiverem passado mais de 24 horas desde a mensagem do cliente. A Meta vai devolver um erro, mais precisamente o erro 131047, e a ação vai falhar.

O sistema não faz ficheiro RPDF, não lê anexos. Na parte das línguas estrangeiras, as traduções funcionam apenas num sentido. O cliente recebe a resposta traduzida, mas o operador vê o original. E, embora a integração com 999.md funcione, ela é não oficial e baseia-se nos cookies do browser. Se a plataforma alterar os seus mecanismos, a ligação cai e precisa de reparação. E lembrem-se disto com atenção. O assistente é o espelho dos vossos dados. Um preço errado no site vai tornar-se garantidamente num preço errado na conversa. Ele age como leitor, não como gestor de loja. Não vai corrigir por iniciativa própria os erros humanos nos catálogos. A infraestrutura técnica aqui não é brincadeira. Tudo é mantido num servidor privado Microsoft Azure.

Estamos a falar de uma base de dados MySQL extremamente estruturada, com mais de 80 tabelas modeladas de forma clara para separar os canais e para auditoria. As chaves de acesso para WhatsApp, que são super-sensíveis, usam encriptação fernet. Além disso, ao nível da web, os domínios para o widget de chat são adicionados manualmente a uma lista branca. Ninguém se liga sem permissão explícita. No entanto, temos de abordar uma realidade evidente. As pessoas vão escrever todo o tipo de dados pessoais nessas janelas de chat, números de telefone, endereços. Tecnicamente, não há forma de bloquear um campo de texto livre. Por isso, a solução é administrativa. Quando implementa um sistema deste tipo, precisa, desde o segundo 1, de políticas claras de retenção que definam exatamente quem pode ver esses dados e durante quanto tempo são armazenados.

E chegámos ao ponto 6. Os passos seguintes. A filosofia central de todo o sistema pode ser resumida por esta citação. Um assistente útil não é aquele que compõe poemas ou escreve de forma bonita, mas sim aquele que está ligado a informações reais e, muito importante, sabe exatamente onde deve parar. A automatização eficiente nos negócios significa a recolha correta dos dados e a segurança com que cede o controlo a um operador humano no momento oportuno. Portanto, o passo seguinte não é comprar um software, mas analisar com atenção os seus processos atuais. Avalie que fluxos de trabalho realmente merecem ser construídos e automatizados, como podem ser ligados em segurança e, o mais importante, defina como vai medir os resultados com dados reais, não com ilusões de marketing.

E deixo-lhe esta questão para pensar. Entre todos os processos de comunicação numa empresa, quais são aqueles que realmente exigem a empatia e o tato de um ser humano e quais são, na verdade, apenas tarefas repetitivas que esperam simplesmente ser ligadas com precisão à base de dados correta? Qualquer plano de automatização deve partir desta pergunta. Obrigado por estarem connosco nesta análise!

Qué incluye

El trabajo, por componentes

Primeiro verificamos qual é o gate público que o sistema tem

Para lojas em WooCommerce usamos a API pública da loja, que não exige chave de consumidor: o cliente liga-se apenas com o endereço do site. É uma escolha que tem consequências reais, não apenas estéticas — substituímos por ela ferramentas escritas à mão que guardavam chaves da loja em claro na base de dados. Quando o sistema não tem gate público, passamos para autenticação, mas aí a chave torna-se uma peça que se gere, não uma que se esquece numa linha da base de dados.

As chaves ficam no servidor, não na ferramenta e não na página

A ferramenta de SMS é interna da plataforma precisamente porque o ambiente em que o código próprio de uma ferramenta é executado não tem acesso às variáveis de ambiente — se o envio fosse feito a partir do código da ferramenta, a chave teria de ser escrita na base de dados, e essa chave pode enviar mensagens à custa de todos. O mesmo no sistema de marcações: o token de parceiro é um só, guardado no ambiente do servidor, enquanto o cliente insere apenas o identificador da sua empresa.

O agente chama a ferramenta durante a conversa, com parâmetros e prazo

Cada ferramenta tem uma descrição escrita para o modelo, parâmetros tipados com o que é obrigatório e o que não é, e um prazo próprio de execução — de 15 segundos para uma lista de serviços até 30 para uma pesquisa de disponibilidade. O prazo por ferramenta não é um detalhe: sem ele, uma integração lenta bloqueia a conversa, e a pessoa do outro lado ouve silêncio.

Marcações reais no sistema do salão ou da clínica

Seis ferramentas por cima de Altegio: a lista de serviços com os preços reais, os especialistas, a disponibilidade completa, a criação da marcação, o cancelamento e a alteração. A disponibilidade não devolve apenas «livre/ocupado»: devolve que especialistas fazem o serviço pedido e as primeiras horas livres para cada um, ordenadas pela mais cedo, precisamente para que o agente proponha uma alternativa concreta em vez de dizer «não está disponível».

O catálogo da loja, lido em tempo real

O preço e a disponibilidade são lidos da loja no momento da pergunta, não de uma cópia desatualizada. O catálogo é carregado de forma paginada, até 30 páginas de 100 produtos cada, é mantido numa memória temporária de dez minutos no site e é normalizado numa única forma, lida sem alterações por todos os consumidores — incluindo o carrossel de produtos na mensageria, que precisa de preço numérico, e o widget na página, que precisa de título.

CRMs, folhas de cálculo e canais de mensagens

amoCRM e Bitrix24 com OAuth completo, renovação de token e verificação de estado. Google Sheets através de uma conta de serviço dedicada, separada do resto das credenciais, com escrita acionada pelo agente. Telegram para notificações de lead. SMS via Infobip. Além disso, o canal de chat de uma plataforma local de anúncios, ligado com um token de renovação próprio — o género de integração que não existe em nenhum catálogo internacional e que conta muito localmente.

Automatizações que correm no tempo, com contadores

Retoma de conversas sem resposta, primeira mensagem para um novo contacto, colocar em pausa e reiniciar o agente após o horário. Cada execução incrementa contadores visíveis: quantas execuções, quantas mensagens enviadas, quantas ignoradas porque o agente estava parado, quantas porque não tinha configuração, quantos erros. Sem eles, a única forma de saber que uma automatização morreu é a reclamação de um cliente.

Limites antiabuso, porque a decisão é tomada por um modelo

Uma ferramenta chamada por um modelo linguístico precisa de margens que o modelo não pode ultrapassar. Em SMS: no modo «para a empresa», o destinatário vem da configuração, nunca do modelo; no modo «para o cliente», o número é normalizado e validado. Além disso, limite diário por agente, pausa de um minuto para o mesmo número e limite de comprimento da mensagem. São guardas escritas em código, não instruções no prompt — um prompt pode ser contornado, uma guarda não.

Filtros na saída, para os dados que não podem sair

Quando uma integração devolve mais do que o cliente deve saber, filtramos à saída, não esperamos que o agente se contenha. Um exemplo real: para um cliente de transportes, a política proíbe que o agente dite o número de telefone do motorista, mas a API devolvia esses números na resposta. Escrevemos um filtro que percorre recursivamente o resultado da ferramenta e elimina os campos de contacto do motorista, mantendo os números da central. O filtro é aplicado exatamente onde é necessário, não globalmente, para não ocultar outra coisa por engano.

Qué aspecto tiene

El recorrido, paso a paso.

O inventário: que sistemas, que gates, que direitos

Que sistemas estão em jogo, o que cada um expõe, quem tem o direito de criar credenciais e quem as roda. Em cada um, a pergunta de base: pode-se ler sem autenticação? Se sim, a integração torna-se muito mais barata e muito mais fácil de repetir para o segundo cliente.

O conector: ferramentas declaradas, chaves no servidor, prazos

Cada ação torna-se uma ferramenta com nome, descrição escrita para o modelo, parâmetros tipados e prazo próprio. As chaves ficam no ambiente do servidor. No fim, o agente não “sabe fazer” algo difuso: tem um conjunto finito de ações, cada uma com os seus limites.

O teste no caso que falha, não apenas no que funciona

Um conector testa-se no pedido correto, no pedido incompleto, no sistema que responde devagar e no sistema que não responde de todo. O que o agente diz quando a integração cai é uma decisão de projeto, não um erro que o cliente descobre: preferimos uma mensagem honesta e uma transferência para um humano, em vez de uma improvisação plausível.

A resistência à instabilidade do outro sistema

Nova tentativa com pausas crescentes, mas apenas nos erros que fazem sentido serem repetidos — uma limitação de taxa ou um erro de servidor, não um pedido errado, que continuará errado da segunda vez. E quando o problema está ao nível da rede do outro, o tratamento é diferente; o exemplo abaixo é precisamente um desses casos.

A entrega: o que muda quando o fornecedor muda

Registamos o que se estraga se o outro sistema alterar a sua API, que credenciais expiram e quando, o que tem de ser renovado manualmente. Uma integração sem esta lista é uma dívida oculta: funciona na perfeição até ao dia em que deixa de funcionar e ninguém sabe porquê.

Os sistemas externos em torno da conversa: marcações, o catálogo da loja, CRM, folhas de cálculo, SMS e canais de mensagens — cada um lido a pedido, com as chaves a ficarem no servidor.

Os dados

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

Onde ficam as credenciais: As chaves de fornecedor da plataforma ficam no ambiente do servidor, não na base de dados e nunca na página do cliente. As credenciais próprias de um cliente — quando a integração as exige — são armazenadas encriptadas. A diferença importa: uma chave de plataforma comprometida afeta toda a gente, uma credencial de cliente afeta uma conta; tratamo-las de forma diferente porque o risco é diferente.
O que é armazenado dos sistemas externos e o que não é: O catálogo de produtos não é copiado: é lido a pedido e mantido numa memória temporária de dez minutos, para que dez perguntas consecutivas sobre a mesma loja não signifiquem dez leituras completas. As marcações não são duplicadas connosco — a fonte da verdade continua a ser o sistema do salão. O que guardamos é o rasto da conversa e o resultado da ação, não uma réplica da base de dados do outro sistema.
O que chega ao modelo linguístico: O resultado de uma ferramenta entra na conversa, logo entra também no contexto do modelo. Por isso, a filtragem é feita sobre o resultado, antes de ser dado ao modelo, não nas instruções. Os campos que o cliente não tem permissão para ouvir são eliminados na origem; o que foi eliminado não pode ser ditado, independentemente de como o agente é perguntado.
Quem pode ligar uma integração: Ligar uma integração é uma operação autenticada, associada à conta da empresa, e as ferramentas resultantes são anexadas a um agente específico — não a todos. Um agente tem exatamente as ferramentas de que precisa para a sua função. É a mesma lógica que no acesso de um funcionário: não lhe dão todas as chaves só porque é mais simples.
O que falta reparar, dito abertamente: Nem todos os módulos de integração na nossa plataforma estão ao mesmo nível. Os listados aqui estão escritos e em execução. Existem também módulos iniciados, de algumas dezenas de linhas, que ainda não fazem nada útil — não os apresentamos como disponíveis e não os colocamos em nenhuma oferta. Se você precisar de um sistema que esteja connosco nesse estado, tratamo-lo como trabalho a construir, com uma verificação de compatibilidade antes, não como uma caixa de seleção.

Un caso

A integração caía de forma intermitente, e não era connosco

A situação

Um conector de CRM funcionava às vezes e outras não, sem padrão à primeira vista. Os pedidos ficavam presos até ultrapassarem o limite de execução do ambiente de servidor, por isso nos registos aparecia uma ultrapassagem de tempo — o sinal que o leva, erradamente, a procurar lentidão no seu próprio código.

Qué construimos

A causa estava na rede, do outro lado. O nome de domínio da conta de CRM resolve-se em vários endereços IP, e parte dos nós do cluster estava pouco saudável. Um pedido HTTP normal escolhe um endereço e, se esse não responder, não tenta os outros endereços devolvidos pelo DNS — não existe passagem automática para a próxima resposta. A correção foi deixar de usar o cliente HTTP predefinido para esse domínio: nós próprios resolvemos o nome, abrimos ligações encriptadas diretamente para cada endereço em paralelo, com um prazo curto para cada uma, e usamos a primeira que responder; se todas estiverem frias numa ronda, repete-se.

Qué salió

As falhas intermitentes deixaram de ser uma lotaria. Mais importante para o cliente: o diagnóstico tornou-se possível de dizer numa frase — „os nós do fornecedor estão intermitentemente indisponíveis, e nós contornamo-los” — em vez de „às vezes não funciona”.

Qué no dice el caso

É uma correção que compensa um problema de outra pessoa, e isso tem de ser dito. Acrescenta complexidade ao nosso código por causa de um defeito na infraestrutura do fornecedor; se ele corrigir o seu cluster, a complexidade fica connosco. Documentamo-la como tal, para poder ser removida quando deixar de ser necessária.

Perguntas

Lo que nos pregunta la gente antes de llamar

Que sistemas vocês ligaram efetivamente, não teoricamente?

O sistema de marcações Altegio, com seis ações chamadas pelo agente. amoCRM e Bitrix24, com OAuth completo e renovação de token. Google Sheets, com conta de serviço dedicada. Lojas em WooCommerce, através da API pública da loja. Telegram, para notificações. Infobip, para SMS. O canal de chat de uma plataforma local de anúncios. Mais os canais de mensagens Meta e Telegram para conversas. Para qualquer outro sistema — incluindo plataformas de loja que não concluímos — a resposta honesta é: a pedido, após uma verificação de compatibilidade, tratada como trabalho, não como configuração.

A minha loja tem de gerar-me chaves API?

Para WooCommerce, não. Usamos a API pública da loja, que não pede chave de consumidor — você liga-se com o endereço do site. É também mais seguro, não apenas mais simples: com esta abordagem substituímos ferramentas mais antigas que guardavam chaves de loja escritas em claro na base de dados. Para outras plataformas, depende do que expõem; verificamos antes de prometer.

O agente pode fazer uma marcação real, e não apenas dizer que a faz?

Sim, se o sistema de marcações o permitir. Cria a marcação, pode cancelá-la e alterá-la, e verifica a disponibilidade antes. Um detalhe que só se aprende no terreno: nesse sistema, o serviço e o especialista viajam juntos — se você pedir as horas livres de um especialista para um serviço que ele não faz, recebe zero resultados, não um erro. Por isso, a ferramenta de disponibilidade devolve todos os especialistas que fazem o serviço e as primeiras horas livres de cada um, para que o agente possa propor uma alternativa concreta.

As minhas chaves vão para onde?

As chaves da plataforma ficam no ambiente do servidor, nunca na base de dados e nunca na sua página. As credenciais que são suas são armazenadas encriptadas. A regra que aplicamos: se uma chave pode gastar dinheiro ou pode ler dados para todos os clientes, não tem lugar em lado nenhum onde chegue código que corre a pedido de um modelo linguístico.

O agente pode enviar SMS a quem quiser?

Não, e é uma restrição deliberada. No modo de notificação para a empresa, o destinatário vem da configuração — o modelo não o pode escolher. No modo para o cliente, o número é normalizado e validado. Além disso, existe um limite diário por agente, uma pausa de um minuto para o mesmo número e um limite de comprimento da mensagem. São guardrails no código, não instruções no prompt; um prompt pode ser contornado pela conversa, um guardrail não.

O que acontece quando o sistema do outro falha ou responde lentamente?

Cada ferramenta tem o seu próprio prazo de execução, para que um sistema lento não bloqueie a conversa. Repetimos com pausas crescentes, mas apenas nos erros que valem a pena repetir — uma limitação de taxa ou um erro de servidor, não um pedido incorreto. E o comportamento do agente em caso de falha é escrito no cenário: diz que não pode verificar agora e passa a conversa adiante, em vez de inventar uma resposta plausível.

O que acontece se o fornecedor alterar a sua API?

Algo se estraga, e é por isso que preferimos os portais oficiais em vez de ler páginas. As ferramentas que extraem a informação do HTML de um site quebram com qualquer mudança de tema — substituímo-las deliberadamente por uma única implementação sobre a API oficial, precisamente para não manter dezenas de variantes frágeis. Quando não existe alternativa, dizemos que é uma solução frágil e tratamo-la como tal.

Podem fazer automatizações sem agente, apenas regras agendadas?

Sim. A retoma de conversas sem resposta, a primeira mensagem para um novo contacto, a paragem e o arranque do agente após o horário de trabalho — são tarefas agendadas que funcionam sozinhas. Cada uma tem contadores próprios para execuções, mensagens enviadas, mensagens ignoradas e erros, para que se possa responder à pergunta „correu?” com um número, não com uma suposição.

Como garantem que o agente não diz o que não deve, vindo de uma integração?

Filtramos o resultado antes de chegar ao modelo, não depois. O caso concreto que resolvemos: a política de um cliente proibia que o agente ditasse o número de telefone do motorista, mas a API devolvia esses números. Escrevemos um filtro que percorre recursivamente a resposta da ferramenta e remove os campos de contacto do motorista, preservando os números da central, aplicado exatamente a essa ferramenta. O que não chega ao modelo não pode ser dito, independentemente de como o agente é questionado.

Em que se baseiam as afirmações acima (18 fontes)

18 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.

Como trabalhamos Todos os serviços

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar