Article technique
Comment Elastra résout le contexte adaptatif pour les agents IA sans transformer chaque tâche en découverte étendue du dépôt
Un article technique sur la manière dont Elastra classe la forme des tâches, limite l'exploration et orchestre le contexte afin que les agents IA restent précis sur les tâches étroites sans perdre de profondeur sur le travail architectural large.
La plupart des stacks d'agents supposent encore que plus de contexte récupéré est automatiquement meilleur. Elastra suit une autre voie : classifier d'abord la tâche, puis ajuster contexte, exploration et usage des modèles autour de cette forme de tâche. Le résultat est un coût plus bas sur le travail localisé dans le dépôt, une profondeur préservée sur l'analyse architecturale et une orchestration multi-modèle bien meilleure.
- Public cible
- Équipes plateforme, staff engineers, équipes d'outillage IA, leaders d'ingénierie et builders avancés qui veulent des agents de coding utiles, prévisibles et efficaces en coût dans de vrais dépôts.
- Objectif
- Expliquer comment Elastra transforme la résolution de contexte sensible au prompt en comportement borné de l'agent, pourquoi cela importe pour l'efficacité des tokens et la latence, et comment le scoping adaptatif améliore à la fois l'exécution étroite et l'analyse architecturale large.
Points clés
- Elastra traite le contexte comme un problème de périmètre d'exécution, et non seulement comme un problème de retrieval.
- La forme de tâche importe parce que les tâches étroites dans le dépôt et les tâches architecturales larges ont besoin de politiques de contexte différentes.
- Le scoping adaptatif améliore aussi l'allocation de coût multi-modèle en laissant les modèles peu coûteux faire une découverte bornée et les modèles plus forts se concentrer sur la synthèse.
Pourquoi le retrieval change le comportement de l'agent
Dans les systèmes agentic, le retrieval n'est pas passif. La quantité et la forme des preuves envoyées au modèle changent ce que l'agent pense devoir faire ensuite.
Si le payload paraît large, l'agent a tendance à se comporter largement. Il commence à valider des patterns frères, à confirmer des hypothèses d'architecture et à ouvrir des chemins d'exploration qui peuvent être inutiles pour la tâche en cours.
- Les tâches étroites ne doivent pas se transformer en découverte étendue du dépôt.
- Les tâches larges doivent encore préserver une profondeur architecturale.
- Le problème de contrôle n'est pas seulement la qualité du retrieval. C'est la ramification comportementale après le retrieval.
Scoping orienté tâche au lieu d'une politique unique de retrieval
Elastra demande d'abord quel type de tâche c'est, puis ajuste l'ampleur du contexte, la profondeur d'exploration et le budget d'exécution autour de cette réponse.
C'est pourquoi le même dépôt peut supporter à la fois des corrections de bugs localisées et une analyse architecturale large sans forcer les deux cas dans le même mode opératoire coûteux.
- `localized_pr_analysis`
- `targeted_bugfix`
- `implementation_multifile`
- `architectural_analysis`
- `open_discovery`
Profils d'exécution : budget, mode d'exploration et largeur de périmètre
Une fois la forme de tâche connue, Elastra attache un profil d'exécution qui oriente jusqu'où l'agent doit aller.
Les tâches étroites favorisent une exploration bornée, des budgets plus petits, peu de sauts cross-service et une forte préférence pour les fichiers modifiés et les preuves directes. Les tâches larges préservent des budgets plus larges et une plus grande capacité de traçage.
Pourquoi l'adaptive context resolution améliore l'orchestration multi-modèle
Le scoping adaptatif ne réduit pas seulement le gaspillage de retrieval. Il aide la stack à décider où dépenser un raisonnement coûteux et où utiliser une découverte moins chère.
Un exemple pratique est un workflow centré sur Claude où Kimi est utilisé pour une découverte bornée et Sonnet pour l'implémentation ou la synthèse à plus forte valeur. Lorsque l'étape de découverte est bien cadrée, le modèle premium dépense son budget sur la partie de la tâche qui en bénéficie réellement.
- Les modèles moins coûteux gèrent une découverte bornée et un routage initial.
- Les modèles plus forts se concentrent sur l'implémentation, la synthèse et l'explication finale ancrée.
- Le coût total baisse parce que le modèle premium reçoit des preuves plus étroites et plus propres.
Du context shaping à l'execution shaping
La version long terme la plus forte de cette architecture n'est pas seulement context-aware. Elle est execution-aware.
Cela signifie que la même policy qui façonne le retrieval peut aussi façonner le branching, la délégation, la vérification et les limites pratiques de l'exploration après l'arrivée du contexte.
Pourquoi cela compte pour les équipes d'ingénierie
Une grande partie de l'infrastructure d'ingénierie IA traite encore le contexte comme une pièce jointe statique au prompt. Elastra traite le contexte comme un contrat opérationnel gouverné.
Cette distinction permet aux tâches étroites de rester étroites, aux tâches larges de rester profondes et à l'usage des modèles de rester économiquement rationnel en même temps.
L'adaptive context resolution n'est pas un truc de retrieval. C'est le mécanisme opérationnel qui transforme le contexte du dépôt en comportement borné, sensible à la tâche et économiquement rationnel pour les agents.