Pas de function calling custom : comprendre la limitation

Une limitation structurelle

Si vous avez pris l’habitude de déclarer vos propres fonctions et de laisser le modèle décider quand les appeler, préparez-vous à changer de méthode : le multi-agent de Grok ne supporte pas le function calling custom. Ce n’est pas un détail de configuration, mais une contrainte d’architecture qui se répercute sur le découpage de votre application. Mieux vaut la découvrir maintenant qu’après trois cents lignes de schémas de fonctions.

La frontière exacte

Ce qui fonctionne, ce sont les cinq outils intégrés vus à la leçon précédente : web_search pour la recherche web en temps réel, x_search pour la plateforme X, code_execution pour exécuter du Python, collections_search pour vos collections indexées, et Remote MCP pour des outils externes via le protocole MCP. En dehors de cette liste, rien ne passe. Les fonctions définies dans votre code, les schémas personnalisés, les appels à vos propres API par le mécanisme de function calling sont tous refusés.

Concrètement, la déclaration ci-dessous, parfaitement valide avec un modèle standard, n’a aucun effet en multi-agent.

# NE FONCTIONNE PAS avec le multi-agent
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Obtenir la meteo",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}
        }
    }
]

D’où vient cette contrainte

La raison tient à la coordination. Avec un seul modèle, la boucle de function calling est limpide : le modèle demande un appel, votre code l’exécute, vous renvoyez le résultat, le modèle poursuit. Introduisez maintenant quatre ou seize agents qui travaillent en parallèle, et les questions se bousculent. Lequel décide d’appeler la fonction ? Que faire de deux agents qui appellent simultanément la même fonction avec des arguments différents ? Comment le leader synthétise-t-il des résultats obtenus par des sub-agents dont il n’a pas suivi le raisonnement ?

Les outils intégrés ont été conçus pour ce contexte et savent se comporter correctement quand plusieurs agents les sollicitent en même temps. Vos fonctions, elles, ont été écrites en supposant un appelant unique. La limitation reflète cette différence de conception plutôt qu’un manque temporaire.

Exposer vos API par un serveur MCP

Le contournement le plus propre consiste à ne pas contourner du tout, mais à passer par la porte prévue. Si votre besoin est d’appeler vos propres services, exposez-les via un serveur MCP : les agents les manipulent alors comme des outils natifs, avec la gestion de concurrence qui va avec. C’est un peu plus de travail au départ qu’une déclaration de fonction, et cela reste la seule voie qui fasse entrer votre système d’information dans la boucle de recherche.

Séparer la recherche de l’action

Deuxième stratégie, souvent la bonne quand vos fonctions déclenchent des effets de bord : couper le traitement en deux. Le multi-agent fait ce qu’il sait faire, chercher et analyser ; un modèle standard prend le relais pour la partie qui appelle vos API.

# Etape 1 : recherche multi-agent
chat = client.chat.create(
    model="grok-4.20-multi-agent-0309",
    agent_count=4,
    tools=[web_search()],
)
chat.append(user("Trouve les meilleurs restaurants italiens a Paris"))
research_result = ""
for response, chunk in chat.stream():
    if chunk.content:
        research_result += chunk.content

# Étape 2 : action avec un modèle standard + function calling
# Utiliser grok-4.5 ou un autre modèle qui supporte le function calling

Cette séparation a un avantage que l’on sous-estime : elle vous laisse inspecter et valider le résultat de la recherche avant qu’une action irréversible soit déclenchée. Un agent qui réserve une table sur la foi d’une recherche non relue est rarement une bonne idée.

Enrichir avant, traiter après

Troisième approche, la plus légère : appelez vos API en dehors de la conversation, en amont pour enrichir le prompt, en aval pour exploiter la réponse. Beaucoup de besoins que l’on croit relever du function calling se réduisent en réalité à injecter les bonnes données au bon moment.

# Pre-traitement : enrichir le contexte
user_data = my_api.get_user_profile(user_id)
context = f"Profil utilisateur : {user_data}"

# Multi-agent avec le contexte enrichi
chat.append(user(f"{context}\n\nAnalyse les options qui correspondent a ce profil"))

Le profil client, l’historique de commandes ou les contraintes budgétaires n’ont pas besoin d’être récupérés par le modèle : vous les connaissez déjà, il suffit de les lui donner. Gardez enfin à l’esprit que l’API est en beta et que cette limitation pourrait évoluer — raison de plus pour isoler la partie multi-agent de votre code derrière une interface que vous pourrez faire évoluer sans tout réécrire.

Points clés à retenir

• Le function calling custom n’est pas supporté avec le multi-agent
• Seuls les outils intégrés (web_search, x_search, code_execution, collections_search, Remote MCP) fonctionnent
• Utilisez Remote MCP pour exposer vos propres API aux agents
• Adoptez une architecture en deux étapes si vous avez besoin de function calling
• Cette limitation pourrait évoluer dans les futures versions (API beta)