Aller au contenu principal
Version: 1.0.0

Strategy

Une strategy est le point d’orchestration exécutable par le runtime. C’est l’entrée d’un programme Touba : elle déclare dans uses les agent (ou strategy, skill, tool, function) qu’elle peut invoquer, puis orchestre l’exécution dans un bloc do.

Forme​

source.tb
strategy StrategyName
    uses AgentName
    do
        AgentName

Cas simple​

strategy_simple.tb
module examples.strategy_simple

type DatasetRequest
    query is Text

type DatasetBrief
    summary is Text

tool SearchDatasets
    takes request as DatasetRequest
    gives DatasetBrief
    requires network

skill BuildDatasetBrief
    takes request as DatasetRequest
    gives DatasetBrief
    uses SearchDatasets
    do
        SearchDatasets
            with request as request
            into result
        give result

agent Researcher
    responsibility "Fulfill the declared Researcher responsibility using only authorized capabilities."
    uses BuildDatasetBrief
    callable_by strategy RunDatasetResearch

strategy RunDatasetResearch
    uses Researcher
    do
        Researcher

RunDatasetResearch est le seul caller autorisé pour Researcher, déclaré explicitement par callable_by.

Cas avancé​

strategy_advanced.tb
module examples.strategy_advanced

type ChangeRequest
    summary is Text

type ReviewedChange
    summary is Text

tool ApplyChange
    takes request as ChangeRequest
    gives ReviewedChange

skill MakeChange
    takes request as ChangeRequest
    gives ReviewedChange
    uses ApplyChange
    do
        ApplyChange
            with request as request
            into result
        give result

skill ReviewChange
    takes request as ChangeRequest
    gives ChangeRequest
    do
        give request

agent Reviewer
    responsibility "Fulfill the declared Reviewer responsibility using only authorized capabilities."
    uses ReviewChange
    callable_by strategy RunChangeReview

agent Engineer
    responsibility "Fulfill the declared Engineer responsibility using only authorized capabilities."
    uses MakeChange
    callable_by strategy RunChangeReview

strategy RunChangeReview
    takes request as ChangeRequest
    uses Reviewer
    uses Engineer
    do
        Reviewer
        Engineer

Une strategy peut déclarer takes (l’entrée du run) et orchestrer plusieurs agent distincts. Chacun reste borné par son propre uses et n’est invocable ici que parce qu’il déclare callable_by strategy RunChangeReview.

Strategy vs agent​

  • Un agent porte la responsabilité d’un choix parmi les capacités qu’il déclare lui-même dans uses.
  • Une strategy porte l’orchestration de la séquence globale : quels agents sont sollicités, dans quel ordre, avec quelle entrée.

Un agent peut autoriser une strategy ou un autre agent dans callable_by, y compris par nom qualifié. Une stratégie n'a pas de callable_by : elle peut être une entrée CLI/trigger ou une capacité typée appelée avec with / into. Ses arguments et résultats restent distincts des valeurs de son appelant.

Composition et parallélisme​

Les appels ordinaires se suivent. Pour traiter plusieurs entrées indépendantes, une stratégie ou une skill peut déclarer un groupe parallel sur une cible typée, locale ou importée. Voici une composition sans handler ni modèle :

batch_labels.tb
module examples.batch_labels

strategy LabelTicket
    takes ticket as Text
    gives Text
    do
        give "Ticket: " ++ ticket

strategy LabelBatch
    takes tickets as List of Text
    gives List of Text
    uses LabelTicket
    do
        parallel LabelTicket
            each ticket in tickets
            with ticket as ticket
            max_concurrency 4
            max_items 32
            into labels
        give labels

LabelBatch retourne une liste dans l'ordre de tickets, même si les appels se terminent dans un autre ordre. Une liste vide rend une liste vide ; plus de 32 éléments refuse le groupe avant son premier appel. La jointure attend tous les résultats : un échec ne devient pas une liste partielle réussie.

La même forme accepte un agent, une skill, une function ou un tool déclaré avec une sortie typée. Les budgets restent communs et chaque invocation garde ses valeurs propres. Pour la configuration provider, les pauses humaines et la reprise, suivre le tutoriel multi-agent.

Contrat runtime​

  • L'ordre est séquentiel hors d'un groupe parallel explicite.
  • max_concurrency et max_items bornent le groupe ; les plafonds hôte et les budgets de run restent applicables.
  • Une strategy ne contourne pas uses/callable_by des agents qu’elle invoque : le runtime vérifie ces contrats à chaque appel.
  • Voir Autonomie bornée pour le détail du contrôle runtime sur chaque invocation d’agent.

Parcours dédiés​