Agents IA runtime

La SR Method peut être utilisée pour n'importe quel projet logiciel, même sans agent IA embarqué.

La SR Agent Method est une extension optionnelle pour concevoir des agents IA intégrés dans des applications métier.

Positionnement

La SR Agent Method n'est pas un framework. Elle ne remplace pas LangChain, LangGraph, PydanticAI, CrewAI, LlamaIndex ou les SDK agents.

Elle définit d'abord le contrat applicatif de l'agent, puis laisse le développeur choisir l'outil d'exécution adapté.

Depuis SR 3.2.0, la méthode est volontairement agnostique du fournisseur, du framework, du domaine métier et de l'interface. Elle peut servir pour un micro-agent de classification, un agent workflow, un agent de délégation, un mini-agent UI ou un agent backend plus complet.

Les 6 briques

1. Action produit bornée : ce que l'agent a le droit de faire, et ce qu'il ne fait pas.
2. Représentation interne stable : langage pivot, schéma métier ou objet applicatif utilisé entre l'agent et le produit.
3. Contrat runtime : entrées disponibles, données interdites, sorties attendues, refus possibles, validations et traces.
4. Prompt contract : rôle, tâche, règles dures, hors périmètre et format de sortie.
5. Message builder : code applicatif qui injecte les bonnes variables depuis l'état réel du produit.
6. Runtime contrôlé : tools, actions, routing, fallback, parseur, validation stricte et logs non sensibles.

Formes d'agents

La SR Agent Method distingue la forme de l'agent avant de choisir une technologie :

Contrat minimal d'un agent IA runtime

Le contrat indique à Codex comment concevoir l'agent :

agent_key:
label:
runtime_shape:
purpose:
bounded_product_action:
business_function_key:
stable_internal_representation:
model_provider:
model:
temperature:
execution_mode:
system_prompt:
user_prompt_template:
message_builder_inputs:
input_schema:
output_schema:
input_model:
output_model:
json_schema_source:
output_validation_mode:
invalid_output_policy:
validation_error_trace:
typed_output_tests:
authorized_tools:
authorized_actions:
sql_context_bindings:
nexus_context_bindings:
required_runtime_skills:
routing_policy:
fallback_policy:
ui_placement:
test_cases:
risk_notes:
human_validation_required:
validation_status:
is_active:

Pydantic Output Contract

Depuis SR pack 3.0.3, le JSON produit par un LLM n'est pas considéré comme une donnée applicative fiable.

Flux cible :

Modèle Pydantic ou équivalent
-> JSON schema exposé au LLM
-> réponse JSON du LLM
-> validation runtime stricte
-> objet applicatif accepté ou erreur contrôlée

Un output JSON schema guide le modèle, mais ne suffit pas. Seul le backend peut décider si la sortie est acceptable.

Règles obligatoires

• Aucun SQL libre généré puis exécuté par le LLM.
• Les requêtes SQL doivent être contrôlées côté backend.
• Les sorties consommées par l'application doivent être structurées et validées.
• Le prompt système ne suffit pas : le contrat runtime et le message builder doivent être écrits côté code.
• Les tools lisent ou transforment ; les actions qui modifient l'état doivent être séparées, autorisées et validées.
• Les champs dangereux, inconnus ou hors contrat doivent être supprimés ou rejetés par le parseur.
• Les actions critiques exigent une validation utilisateur.
• Un agent ne doit pas être activé sans validation : validation_status explicite et is_active=false avant accord.
• En Python, la validation doit s'appuyer sur Pydantic.
• Dans une autre stack, un validateur typé équivalent est obligatoire.
• Une sortie invalide ne doit jamais déclencher une action critique.
• Une sortie réparée automatiquement doit rester bloquée en validation humaine si elle peut produire un effet métier sensible.

Prompt pour cadrer les agents

Utilise docs/codex/prompts/15_define_runtime_agents.md. Ne code rien.

Lis AI_AGENT_RUNTIME_METHOD.md, les docs domaine, les schémas, routes et modèles pertinents.

Je souhaite créer un agent IA qui aura comme fonction de : [description attendue]

Pour chaque agent : agent_key, purpose, prompts, input_schema, output_schema, bindings SQL/Nexus, skills runtime, UI, tests, risques, validation humaine, validation_status et is_active=false.

Pour chaque agent candidat, précise aussi comment la sortie JSON du LLM sera validée côté backend. En Python, propose les modèles Pydantic d'entrée et de sortie. Dans une autre stack, propose le validateur typé équivalent.

Pour chaque agent, précise aussi l'action produit bornée, la représentation interne stable, le contrat runtime, le message builder, les tools, les actions, la politique de routing/fallback et les traces nécessaires.