Concevoir pour la voix sur les marchés émergents a rapidement révélé une réalité pratique : la qualité en production dépend de bien plus que du modèle ou du prompt.

Le chemin d'appel compte. Tout comme la latence de la boucle audio, l'adéquation de la voix, le contexte disponible pour l'agent, les outils qu'il peut solliciter en pleine conversation, et les contrôles dont les équipes ont besoin pour réviser, sécuriser et déboguer le système après chaque interaction.

Chez AethexAI, nous concevons pour l'ensemble de cette surface. Nous hébergeons, entraînons et orchestrons la stack vocale en interne, afin que les équipes puissent déployer des agents vocaux rapides, conscients du contexte, adaptés localement et prêts pour la production dès le premier jour.

Aethex est le plan de contrôle des agents vocaux pour les workflows des marchés émergents. Voici la surface que nous exposons aux développeurs :

1. Kora, notre famille de modèles vocaux pour le speech-to-text et le text-to-speech en streaming.

2. L'API et le SDK Aethex, qui exposent les agents, les appels, les outils, les transcriptions, les bases de connaissances et l'utilisation sous forme de primitives programmables.

3. Le serveur MCP Aethex, qui rend cette même infrastructure accessible aux assistants IA via le Model Context Protocol.

Cet article passe en revue cette stack pour tout ce dont vous avez besoin en tant que développeur : comment la couche vocale se connecte au runtime de l'agent, comment un agent devient ancré et capable d'agir, comment les appels deviennent des conversations observables, et comment le modèle de sécurité garantit le fonctionnement sûr d'un système capable de passer des appels et d'invoquer des outils.

Modèles et capacités vocales

À la base d'Aethex se trouve Kora, notre famille de modèles vocaux. Nous détaillerons le pipeline d'entraînement des modèles dans un prochain article de blog.

• Kora Read propulse le speech-to-text (STT)

• Kora Speak propulse le text-to-speech (TTS)

Ensemble, ils fournissent la couche vocale pour nos agents, ainsi que pour les développeurs qui souhaitent utiliser la voix directement via l'API.

Les capacités vocales sont autonomes. Vous pouvez synthétiser de l'audio à partir de texte, diffuser de l'audio généré en streaming pour une lecture en temps réel, transcrire de l'audio téléchargé, prévisualiser des voix, lister le catalogue et inspecter les modèles disponibles sur votre compte. Un workflow conversationnel utilise cette même couche vocale au sein d'un agent qui gère l'intégralité de l'appel. Les mêmes primitives desservent ces trois cas d'usage.

Les voix sont exposées comme des ressources enrichies de métadonnées, de sorte qu'elles s'intègrent dans de réels flux de produits au lieu d'être codées en dur. Filtrez le catalogue par langue, style de dialecte, tag et pays, et utilisez les tags de voix pour trouver des styles d'élocution et des profils professionnels tels que chaleureux, calme, professionnel, technique, axé sur le service ou digne de confiance.

Le modèle de raisonnement est l'étape configurable du flux d'appel. Un agent peut utiliser la configuration par défaut d'Aethex, colocalisée avec Kora Read et Kora Speak, ou lier son comportement à un modèle tiers provenant d'un fournisseur tel qu'OpenAI, Anthropic ou Google. Dans les deux cas, la couche vocale, le comportement de l'agent, les outils, les connaissances et le cycle de vie de l'appel restent au sein d'une seule et même plateforme.

Les agents comme runtime déployable

L'objet principal dans Aethex est l'agent.

Un agent contient la configuration d'un workflow vocal en direct : nom, prompt système, premier message, voix, langue, style de dialecte, modèle LLM, température, limites de durée, gestion du silence, comportement en cas d'interruption, garde-fous, respect du script, paramètres d'enregistrement et de transcription, comportement de la messagerie vocale, variables dynamiques, comportement de transfert, métadonnées, documents de la base de connaissances, outils et URL de webhook.

from aethexai import AethexAI

client = AethexAI(api_key="ae_live_...")

agent = client.create_agent(

    name="Agent de recouvrement",

    system_prompt="Vérifiez l'identité de l'emprunteur avant de discuter du compte.",

    first_message="Bonjour, ceci est un appel de courtoisie de votre prêteur.",

    voice_id="Femi",

    language="english",

)

Une fois l'agent créé, il devient l'unité sur laquelle les équipes itèrent. Mettez à jour le prompt, changez de voix, modifiez le modèle LLM, associez un document, enregistrez un outil, dupliquez l'agent pour un nouveau workflow, déclenchez un appel de test, inspectez la transcription et passez la configuration en production sous la clé d'accès appropriée.

Un agent de recouvrement peut commencer avec un script strict et un outil de vérification d'identité, puis ajouter une base de connaissances pour les plans de paiement. Un agent de support peut utiliser une voix plus chaleureuse, de la documentation produit, la recherche de commandes et un chemin de transfert. Un agent d'enquête peut utiliser des réponses plus courtes, un respect plus strict du script et des métadonnées structurées. Chaque workflow bénéficie de sa propre configuration de runtime sans obliger les équipes à reconstruire la stack technique.

Des bases de connaissances pour des conversations ancrées

Les agents d'entreprise ont besoin des ressources de confiance de l'entreprise : politiques produits, règles d'éligibilité, scripts de paiement, guides d'intégration, instructions cliniques, documents d'information, playbooks de support et procédures d'escalade. Les bases de connaissances d'Aethex vous permettent d'associer directement ce contexte à un agent.

L'API de la base de connaissances prend en charge les téléchargements de fichiers et de documents textuels, les téléchargements par étapes, le traitement des documents, le listage, le retraitement, la suppression, la récupération du texte intégral extrait et les requêtes de recherche pour le débogage. Ce dernier point est crucial : avant qu'un agent ne soit mis en ligne, vous pouvez tester ce que la base de connaissances renvoie pour une question et inspecter les segments auxquels l'agent aurait accès pendant une conversation.

La voix modifie les exigences en matière de recherche d'informations. Dans une interface textuelle, une réponse lente peut être acceptable. Lors d'un appel, l'étape de recherche s'insère dans un tour de parole en direct aux côtés du raisonnement et de la génération de la parole ; l'agent doit donc trouver le contexte pertinent, produire une réponse et maintenir la conversation fluide sans laisser l'interlocuteur dans le silence. Traiter les connaissances comme partie intégrante du runtime de l'agent permet également de les améliorer en continu : mettez à jour le document source, retraitez un document, interrogez la base de connaissances, examinez les transcriptions et déterminez si l'agent a besoin d'un meilleur contexte, d'instructions plus précises ou d'un nouvel outil, sans avoir à reconstruire le prompt à partir de zéro.

Des outils pour des actions en temps réel

Les outils connectent un agent à des systèmes externes pendant une conversation. Chaque outil possède un nom, une description, un schéma de paramètres et un endpoint. La description aide l'agent à déterminer la pertinence de l'outil. Le schéma définit les informations requises pour l'appeler. L'endpoint connecte la conversation au système du client.

client.add_agent_tool(

    agent["id"],

    name="verify_account",

    description="Vérifier le compte d'un client par son identifiant avant de discuter des soldes.",

    parameters={

        "type": "object",

        "properties": {"account_id": {"type": "string"}},

        "required": ["account_id"],

    },

    endpoint_url="https://api.yourbank.com/aethex/verify",

)

Un outil peut vérifier un compte, rechercher une commande, contrôler une éligibilité, créer un ticket, mettre à jour un CRM, enregistrer une promesse de paiement, déclencher une notification ou planifier un rappel. L'agent maintient le fil de la conversation pendant que le workflow interagit avec les systèmes où réside réellement le processus métier.

La validation des outils fait partie intégrante du produit. Les noms d'outils, les schémas et les URL sont vérifiés lors de la création ou de la mise à jour de l'outil, et les endpoints doivent utiliser des protocoles HTTPS publics ; les destinations privées, en loopback, avec identifiants intégrés ou non résolues sont rejetées. Cela garantit que l'appel d'outils s'effectue sur une surface d'intégration de production plutôt que comme une simple fonctionnalité de prompt non contrôlée.

L'exécution des outils en direct tolère très peu d'erreurs, et le runtime est conçu en conséquence. Un endpoint lent se traduit par une pause audible pour l'appelant, un paramètre manquant devient une question de suivi, et une requête échouée entraîne une tentative de réessai, une explication ou un transfert. L'appel n'est pas coupé parce qu'un service externe a échoué. C'est cette couche qui transforme une interface conversationnelle en un système opérationnel.

Appels, conversations et enregistrements

Une fois l'agent configuré, vous passez des appels via l'API. Nous prenons en charge les intégrations avec votre propre trunking SIP (BYO), WebRTC, Twilio, et d'autres intégrations sont à venir.

call = client.trigger_call(

    agent_id=agent["id"],

    to_number="+234...",

    from_number="+234...",

)

L'appel rassemble l'ensemble de la stack : modèles vocaux, sélection de la voix, instructions de l'agent, paramètres LLM, recherche de connaissances, exécution d'outils, comportement de l'appel, enregistrement, transcription, métadonnées, utilisation et autorisations.

Une fois l'appel terminé, la plateforme conserve les artefacts nécessaires au fonctionnement des équipes. Inspectez le statut de l'appel, récupérez les conversations, accédez aux enregistrements, examinez les transcriptions, recherchez dans l'historique et comptabilisez l'utilisation. Une équipe QA peut créer des files d'attente d'examen. Une équipe opérationnelle peut rechercher les interruptions, les transferts, les échecs d'appels d'outils et les objections récurrentes. Un workflow de conformité conserve les enregistrements et les transcriptions pour examen ultérieur.

Pour lire les enregistrements dans une interface utilisateur orientée client, générez une URL signée temporaire limitée à une seule conversation et transmettez-la au navigateur ; elle expire rapidement, ne comporte aucune autre autorisation et maintient le contrôle du flux audio, même lorsqu'il quitte votre serveur. Un simple appel de test peut s'évaluer à l'oreille ; un déploiement en production nécessite des enregistrements structurés, et les appels deviennent des conversations que vous pouvez rechercher, auditer et connecter à vos systèmes internes.

Les workflows vocaux se poursuivent souvent après la fin de l'appel. Aethex envoie des webhooks sortants signés pour des événements tels que call.ended et recording.ready, afin que les équipes reçoivent les métadonnées de l'appel, les transcriptions finales et les URL d'enregistrement sans avoir à effectuer de requêtes répétées. Un appel de recouvrement finalisé met à jour un tableau de bord interne. Une conversation de support entre dans une file d'attente QA. Un enregistrement est transféré vers le stockage dès que recording.ready arrive. Une transcription déclenche des analyses, des notations ou un suivi.

Ces événements touchant aux workflows des clients, ils sont signés avec HMAC-SHA256 à l'aide d'un secret client que vous pouvez renouveler, permettant ainsi au système de réception de vérifier qu'un rappel provient bien d'Aethex avant d'accepter le payload.

MCP pour le développement piloté par assistant

Le serveur MCP Aethex intègre cette même plateforme dans les assistants IA via le Model Context Protocol, vous permettant de travailler avec Aethex depuis Claude Code, Claude Desktop, Cursor, Codex, Windsurf et d'autres clients compatibles MCP.

claude mcp add aethex \

  --env AETHEX_API_KEY=your-api-key \

  -- uvx aethexai-mcp

Grâce à MCP, un assistant peut lister les voix, synthétiser la parole, transcrire l'audio, concevoir des agents, passer des appels et consulter l'utilisation via l'API publique. Le serveur est livré sous forme de package aethexai-mcp, s'exécute localement, se lance avec uvx, et utilise la clé API fournie dans son environnement, éliminant ainsi tout besoin d'hébergement.

Le modèle de sécurité reste inchangé. Le serveur MCP hérite des privilèges de la clé qu'il reçoit. Donnez-lui une clé en lecture seule et il pourra inspecter. Donnez-lui une clé de test et il pourra aider au développement. Conservez les appels de production derrière une clé distincte et l'assistant restera dans cette limite. Il recherche les identifiants réels avant d'agir et confirme les actions sensibles telles que les suppressions, les annulations et les appels sortants avant de les exécuter.

Cela transforme la boucle de développement. Demandez à un assistant de créer un agent de test, d'associer un document, d'enregistrer un outil, de passer un appel, de récupérer la transcription et de résumer les changements. L'API reste la source unique de vérité. MCP devient une interface supplémentaire pour la même plateforme.

Assembler la stack

Aethex est structuré autour du cycle de vie d'un agent vocal de production. Commencez par la parole : générez de l'audio, transcrivez des enregistrements, inspectez les voix et choisissez le comportement du modèle. Configurez un agent avec la voix, la langue, les instructions, les garde-fous, les paramètres d'appel et les métadonnées appropriés. Associez une base de connaissances pour que l'agent puisse répondre à partir du contexte de l'entreprise. Ajoutez des outils pour qu'il puisse agir pendant la conversation. Passez des appels, récupérez les enregistrements et les transcriptions, recevez des webhooks signés, inspectez l'utilisation et contrôlez l'accès grâce aux clés d'accès limitées. Intégrez ce même workflow dans un assistant IA via MCP lorsque c'est le moyen le plus rapide de concevoir ou de tester.

Pour les marchés desservis par Aethex, l'intégralité de la stack est cruciale. La topologie du réseau influe sur la latence des échanges. La qualité de la voix influe sur la confiance. L'exécution des outils détermine si l'agent peut mener à bien le workflow. Les bases de connaissances garantissent la pertinence et l'exactitude des réponses. L'utilisation influe sur l'économie unitaire. La sécurité détermine si le système peut être déployé en toute sécurité au sein d'une entreprise. La surface offerte aux développeurs reflète ces exigences : modèles, voix, agents, outils, bases de connaissances, numéros de téléphone, appels via téléphone et navigateur, conversations, enregistrements, transcription, utilisation, limites de débit, clés API, webhooks, SDKs et MCP au sein d'une seule et même plateforme.

Démarrer

• Démarrage rapide : developers.aethexai.com/docs/quickstart

• SDK Python : developers.aethexai.com/docs/sdk

• Serveur MCP : developers.aethexai.com/docs/mcp

• Référence API : developers.aethexai.com/docs/api-reference

• GitHub : github.com/aethexai

Vous développez un projet nécessitant de la voix pour fonctionner dans le monde réel ? Retrouvez-nous sur Discord ou @aethexailabs sur X !