Conversations multi-tours avec previous_response_id

Affiner la recherche tour après tour

On imagine volontiers le multi-agent comme une machine à requêtes uniques : une question massive entre, un rapport complet sort. C’est son usage le moins efficace. Une investigation réelle avance par étapes, chaque réponse ouvrant la question suivante, et le multi-agent sait travailler ainsi : vous chaînez les requêtes en conservant le contexte, ce qui permet de commencer large puis de resserrer.

Chaîner les requêtes avec previous_response_id

Avec la Responses API, le chaînage repose sur previous_response_id : vous passez à chaque appel l’identifiant de la réponse précédente, et le modèle reprend le fil.

# Tour 1 : vue d'ensemble
response1 = client.responses.create(
    model="grok-4.20-multi-agent-0309",
    reasoning={"effort": "low"},
    input=[{"role": "user", "content": "Panorama des frameworks de RAG en 2026"}],
)

# Tour 2 : approfondissement (reference le tour précédent)
response2 = client.responses.create(
    model="grok-4.20-multi-agent-0309",
    reasoning={"effort": "medium"},
    input=[{"role": "user", "content": "Approfondis les architectures hybrides mentionnées"}],
    previous_response_id=response1.id,
)

# Tour 3 : comparaison ciblee
response3 = client.responses.create(
    model="grok-4.20-multi-agent-0309",
    reasoning={"effort": "high"},
    input=[{"role": "user", "content": "Compare Pinecone et Weaviate pour ce cas d'usage"}],
    previous_response_id=response2.id,
)

Observez la progression de l’effort de raisonnement : low pour la cartographie initiale, medium pour l’approfondissement, high pour la comparaison finale. Elle traduit une logique de fond — on ne dépense de la puissance de calcul qu’une fois qu’on sait sur quoi la dépenser. Les agents savent ce qui a déjà été dit et ne reconstruisent pas le terrain à chaque tour.

Trois manières de conduire une session

L’entonnoir, du large au précis

C’est la trajectoire la plus naturelle et la plus économe. Le premier tour, mené avec quatre agents, cartographie le sujet et fait apparaître les angles. Le deuxième, toujours à quatre agents, zoome sur celui qui vous concerne. Le troisième seulement mobilise seize agents pour analyser en profondeur le point identifié. Vous ne déployez la grande équipe qu’une fois certain de ce que vous cherchez, au lieu de payer une exploration exhaustive dont 90 % ne vous servira pas.

L’exploration latérale

Il arrive qu’une réponse révèle un angle imprévu. Vous demandez quels sont les défis du déploiement des LLM en production, le leader mentionne au passage des problèmes de latence, et c’est là que se joue votre projet. Le tour suivant part de cette mention — « tu as mentionné les problèmes de latence, quelles solutions existent ? » — puis le troisième compare les approches de caching sémantique évoquées. Chaque question reprend le vocabulaire exact du tour précédent, ce qui cible nettement mieux les recherches.

La validation croisée

Cette conduite vise la fiabilité plutôt que la découverte. Vous demandez les benchmarks de performance de Mistral Large 3, puis vous faites vérifier ces chiffres auprès de sources indépendantes, et vous terminez en cherchant les contradictions entre elles. Le troisième tour est le plus instructif : il transforme une réponse assurée en un état des connaissances où l’incertitude est explicite.

La même chose avec le xAI SDK

Le SDK natif rend le chaînage implicite : l’objet chat porte l’historique, il suffit d’y ajouter les messages successifs.

chat = client.chat.create(
    model="grok-4.20-multi-agent-0309",
    agent_count=4,
    use_encrypted_content=True,
)

# Tour 1
chat.append(user("Panorama des frameworks de RAG en 2026"))
for response, chunk in chat.stream():
    if chunk.content:
        print(chunk.content, end="", flush=True)

# Tour 2 (meme objet chat = contexte conserve)
chat.append(user("Approfondis le point sur les architectures hybrides"))
for response, chunk in chat.stream():
    if chunk.content:
        print(chunk.content, end="", flush=True)

Le use_encrypted_content=True fait ici une vraie différence : sans lui, seul le texte échangé est conservé ; avec lui, l’état interne des sub-agents survit d’un tour à l’autre et la continuité de la recherche s’en trouve améliorée.

Savoir arrêter une session

Le mécanisme a ses limites, toutes liées à l’accumulation. Le contexte grossit à chaque tour et finit par saturer la fenêtre ; le contenu chiffré y contribue, l’état des sub-agents occupant de la place ; la cohérence s’érode à mesure que le leader tient un historique plus vaste ; et les coûts suivent, chaque tour facturant tous les tokens accumulés.

En pratique, tenez-vous à trois à cinq tours par session. Au-delà, ouvrez une session neuve avec un prompt de synthèse reprenant vos conclusions : ce contexte propre et condensé se révèle souvent plus efficace que la conversation étirée que vous abandonnez.

Points clés à retenir

• previous_response_id chaîne les requêtes en conservant le contexte
• La stratégie en entonnoir (large → précis) optimise les coûts
• use_encrypted_content=True préserve l’état des sub-agents entre les tours
• Limitez-vous à 3-5 tours par session pour garder cohérence et coûts maîtrisables
• Commencez avec 4 agents et augmentez au fur et à mesure si nécessaire