# D4 · Designing and Building Agentic Systems
Les trois runtimes d’agent, les sessions et environnements, les sandboxes hébergés versus auto-hébergés, les outils et MCP, le multi-agent et les subagents, les guardrails et approbations, le tracing, et les contraintes de l’Agents API.
import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components';
Ce domaine partage la pondération la plus élevée avec la Responses API — à peu près **11 des 60 items** (18 %) — et reflète le cours Academy *Design and Build Agentic Systems* (110 min, le plus long cours API). Il teste si vous savez choisir entre les **trois runtimes d’agent**, donner à un agent des outils et des limites, orchestrer plusieurs agents ou subagents, ajouter des guardrails et des approbations, l’observer avec le tracing, et respecter les contraintes de l’Agents API managée. La distinction la plus testée est **quel runtime pour quel problème**.
## Ce que vous devez savoir
Un agent est un modèle doté d’instructions, d’outils et d’une boucle qui lui permet d’agir, d’observer et de continuer vers un objectif. OpenAI vous donne trois façons d’en exécuter un : la **Responses API + outils** où vous possédez la boucle ; l’**Agents SDK** open-source que vous exécutez vous-même pour une orchestration code-first ; et l’**Agents API** où OpenAI exécute un **harness Codex** managé — sessions, orchestration, compaction du contexte et récupération — pendant que vous fournissez les outils et choisissez l’environnement. Les agents travaillent dans des **sessions** au sein d’un **environnement** (sandbox hébergé ou auto-hébergé), utilisent des **outils** dont des connexions **MCP**, peuvent déléguer à des **subagents**, et ont besoin de **guardrails, d’approbations et de tracing**. L’Agents API est **en résidence de données US uniquement, sans ZDR**, et un sandbox auto-hébergé n’y change rien.
## Objectifs d’apprentissage
À la fin de cette page, vous devriez être capable de :
1. **Choisir le bon runtime** — Responses + outils, Agents SDK, ou Agents API — pour un problème donné.
2. Expliquer les **sessions**, les **environnements** et les **sandboxes hébergés vs auto-hébergés**.
3. Donner à un agent des **outils**, dont des connexions **MCP**, de façon sûre.
4. Concevoir des systèmes **multi-agent** et la délégation à des **subagents**.
5. Ajouter des contrôles de **guardrails, d’approbations et de supervision humaine dans la boucle**.
6. Utiliser le **tracing et l’observabilité**, et respecter les **contraintes de l’Agents API**.
---
## 4.1 Les trois runtimes
C’est le cœur du domaine. Apprenez le tableau par cœur.
| Runtime | Ce que c’est | Le choisir quand |
| --- | --- | --- |
| **Responses API + outils** | Vous possédez la boucle, appel par appel | Assistants simples utilisant des outils, contrôle total, aucun besoin de session/sandbox |
| **Agents SDK** | Framework open-source Python/TS que vous exécutez : définitions d’agents, orchestration, guardrails, sandboxing, tracing, évaluations d’agents | Vous voulez un contrôle code-first, une orchestration personnalisée, une exécution auto-hébergée |
| **Agents API** (`/v1/agents/sessions`, header `OpenAI-Beta: agents=v1`, beta) | Harness Codex managé par OpenAI : OpenAI exécute les sessions, l’orchestration, la compaction du contexte, la récupération ; vous fournissez les outils et choisissez l’environnement | Agents cloud durables, sandboxes hébergés, travail de longue durée, artifacts |
```text
Avez-vous besoin qu'OpenAI exécute et récupère pour vous une session durable et longue ?
│
┌────┴─────────────────────────┐
│ Oui │ Non
▼ ▼
Agents API (harness managé) Voulez-vous un framework pour une
sandbox hébergé/auto-hébergé, orchestration code-first que vous exécutez ?
subagents, compaction │
┌───────┴────────┐
│ Oui │ Non
▼ ▼
Agents SDK Responses API + outils
(vous l'exécutez) (vous possédez la boucle)
```
:::tip[Signal d’évaluation]
« OpenAI exécute la session / la récupère / gère la compaction » → Agents API. « Framework open-source que nous exécutons / orchestration personnalisée dans notre code » → Agents SDK. « Assistant simple, nous contrôlons chaque appel » → Responses + outils.
:::
## 4.2 Construire un agent dans l’Agents SDK
```python
from agents import Agent, Runner, function_tool
@function_tool
def lookup_order(order_id: str) -> dict:
return orders_db.get(order_id)
support_agent = Agent(
name="Support",
instructions="Help with orders. Use tools; never invent an order.",
model="gpt-5.6-terra",
tools=[lookup_order],
)
result = Runner.run_sync(support_agent, "Where is order 8842?")
print(result.final_output)
```
```typescript
import { Agent, run, tool } from '@openai/agents';
import { z } from 'zod';
const lookupOrder = tool({
name: 'lookup_order',
parameters: z.object({ orderId: z.string() }),
execute: async ({ orderId }) => ordersDb.get(orderId),
});
const supportAgent = new Agent({
name: 'Support',
instructions: 'Help with orders. Use tools; never invent an order.',
model: 'gpt-5.6-terra',
tools: [lookupOrder],
});
const result = await run(supportAgent, 'Where is order 8842?');
console.log(result.finalOutput);
```
## 4.3 Démarrer une session Agents API
L’Agents API est une surface beta ; vous vous y inscrivez avec un header et OpenAI exécute le harness.
```json
POST /v1/agents/sessions
OpenAI-Beta: agents=v1
{
"agent": {
"model": "gpt-5.6-terra",
"instructions": "Migrate the test suite to the new framework.",
"tools": [{ "type": "shell" }],
"mcp_servers": [{ "url": "https://mcp.internal/repo" }]
},
"environment": { "type": "hosted" },
"multi_agent": { "enabled": true, "max_concurrent_subagents": 3 }
}
```
Vous suivez ensuite la progression via le streaming ou des webhooks, et vous pilotez ou poursuivez la session. OpenAI gère l’orchestration, la synthèse du contexte, la délégation aux subagents et la reprise de session.
## 4.4 Sessions et environnements
| Concept | Signification |
| --- | --- |
| **Agent** | Modèle, instructions, outils, serveurs MCP |
| **Environment** | Sandbox hébergé par OpenAI ou auto-hébergé : fichiers/artifacts, cycle de vie, sécurité |
| **Session** | Une instance durable : créer → tâche → suivre via streaming/webhooks → continuer ou piloter |
| **Events and items** | Le flux de ce que l’agent a fait (appels d’outils, messages, résultats) |
**Sandbox hébergé vs auto-hébergé :** un sandbox hébergé est exécuté par OpenAI (facturé aux tarifs conteneur) et le plus simple ; un sandbox auto-hébergé s’exécute dans votre infrastructure pour contrôler l’environnement d’exécution. Point crucial, **auto-héberger le sandbox ne change pas les contraintes de résidence/ZDR de l’Agents API** — voir 4.8.
## 4.5 Outils et MCP
Les agents agissent à travers des outils : function calling, web search, file search, code interpreter, shell, computer use, image generation, apply patch, et des connexions **MCP** qui exposent des systèmes externes comme des outils. MCP permet à un agent d’atteindre une base de données, un dépôt ou un système SaaS via un protocole standard au lieu d’une glu sur mesure.
:::caution[Moindre privilège pour les outils]
Ne donnez à un agent que les outils et les scopes MCP dont il a besoin pour sa tâche. Un agent de support qui ne fait que lire les commandes ne devrait pas détenir un accès en écriture à la facturation. Les outils surprovisionnés sont le plus grand risque de rayon d’impact agentique.
:::
## 4.6 Multi-agent et subagents
Deux patterns résolvent des problèmes différents :
| Pattern | Forme | Utiliser pour |
| --- | --- | --- |
| **Multi-agent / handoff** | Des agents spécialistes se passent le contrôle (triage → facturation → remboursements) | Compétences distinctes, routage clair |
| **Subagents** | Un agent principal délègue des sous-tâches en parallèle (`multi_agent: { enabled, max_concurrent_subagents }`) | Travail parallélisable sous un même objectif |
Les subagents dans le harness managé laissent l’agent principal déléguer du travail concurrent et rassembler les résultats ; gardez `max_concurrent_subagents` borné pour que le coût et les limites de débit restent prévisibles.
## 4.7 Guardrails, approbations et tracing
| Contrôle | Ce qu’il fait | Exemple |
| --- | --- | --- |
| **Guardrails d’entrée/sortie** | Valider ou bloquer les entrées/sorties dangereuses | Rejeter une prompt-injection, une fuite de PII |
| **Approbations (supervision humaine dans la boucle)** | Mettre en pause avant une action à fort enjeu | Confirmer avant d’émettre un remboursement ou de supprimer des données |
| **Tracing / observabilité** | Enregistrer chaque étape pour le débogage et l’audit | Inspecter quel appel d’outil a mal tourné |
Un agent qui peut prendre des actions irréversibles a besoin d’un **gate d’approbation** sur ces actions et de **tracing** pour que vous puissiez voir ce qu’il a fait et pourquoi.
## 4.8 Contraintes de l’Agents API
Connaissez-les — ce sont des items fréquents et à forte valeur.
- **Résidence de données US uniquement.** L’Agents API traite aux États-Unis ; il n’y a pas d’option de résidence hors US aujourd’hui.
- **Pas de ZDR (Zero Data Retention).** Le ZDR n’est pas disponible pour l’Agents API.
- **Auto-héberger le sandbox ne lève pas ces contraintes.** Exécuter votre propre sandbox contrôle l’environnement d’*exécution*, pas les conditions de résidence ou de rétention de l’API.
- **Beta.** Elle est livrée derrière `OpenAI-Beta: agents=v1` ; traitez-la comme beta dans la planification de production.
- **Facturation.** Tarifs API du modèle + tarifs d’outils standard + tarifs conteneur pour les sandboxes hébergés.
```text
Si l'exigence est une résidence EU-uniquement ou le ZDR :
l'Agents API n'est PAS éligible (même avec un sandbox auto-hébergé).
→ Utiliser l'Agents SDK (vous l'exécutez, votre résidence/rétention) ou
Responses + outils avec vos propres contrôles.
```
## Cadre de décision
Utilisez **RUNTIME-FIT** pour choisir et sécuriser une conception d’agent.
| Étape | Question | Si oui |
| --- | --- | --- |
| Durabilité managée | Avez-vous besoin qu’OpenAI exécute/récupère de longues sessions ? | Agents API (vérifier d’abord la résidence/le ZDR) |
| Résidence/ZDR | Avez-vous besoin d’une résidence EU ou du ZDR ? | Pas l’Agents API → SDK ou Responses |
| Orchestration personnalisée | Voulez-vous un contrôle code-first de la boucle ? | Agents SDK |
| Simplicité | Assistant à outils simple, vous possédez chaque appel ? | Responses + outils |
| Scope d’outils | Quel est le moindre privilège qui fonctionne ? | N’accorder que les outils/scopes MCP nécessaires |
| Actions à fort enjeu | Une action irréversible ? | Ajouter un gate d’approbation + tracing |
Le contrôle décisif en amont est la **résidence/le ZDR** : il peut éliminer l’Agents API avant toute autre considération.
## Erreurs fréquentes
| Erreur | Pourquoi elle survient | Que faire à la place |
| --- | --- | --- |
| Utiliser l’Agents API là où une résidence EU ou le ZDR est requis | Le harness managé est attractif | Elle est US-uniquement, sans ZDR ; utiliser le SDK ou Responses à la place |
| Supposer qu’un sandbox auto-hébergé accorde le ZDR | « Auto-hébergé = mes règles » | L’auto-hébergement contrôle l’exécution, pas la résidence/rétention de l’API |
| Se précipiter sur un runtime avant de cadrer | Les runtimes sont excitants | Choisir selon les besoins de durabilité, d’orchestration et de simplicité |
| Surprovisionner les outils de l’agent | Confort | Accorder des outils et scopes MCP au moindre privilège |
| Aucun gate d’approbation sur les actions irréversibles | L’autonomie semble être le but | Placer remboursements, suppressions, envois derrière une approbation humaine |
| Aucun tracing | Ça marche dans la démo | Tracer chaque étape pour le débogage et l’audit |
| Subagents non bornés | « Plus de parallélisme c’est mieux » | Borner `max_concurrent_subagents` pour le coût et les limites de débit |
| Construire un framework à la main | Ignorer l’existence du SDK | Utiliser l’Agents SDK pour une orchestration que vous réinventeriez sinon |
## Défi de mise en situation
**Mise en situation.** Une banque européenne veut un agent durable qui migre une grande base de code legacy sur de nombreuses heures, exécutant des commandes shell et lisant un dépôt interne via MCP, avec des dashboards de progression. Les données doivent rester dans l’UE et la politique de la banque exige une rétention nulle des données. Un architecte propose l’Agents API avec un sandbox auto-hébergé « pour que les données restent dans notre infrastructure UE et que le ZDR soit satisfait ».
**Trace de raisonnement d’expert.**
1. **Vérifier d’abord la résidence et le ZDR.** La banque exige une résidence UE et le ZDR. L’Agents API est **US-uniquement sans ZDR** — c’est une contrainte dure, vérifiée avant toute autre chose.
2. **Rejeter le raisonnement du sandbox auto-hébergé.** Un sandbox auto-hébergé contrôle où se produit l’*exécution*, mais les conditions de résidence et de rétention de l’Agents API sont des propriétés de l’API, pas du sandbox. Donc l’auto-hébergement ne rend **pas** l’Agents API résidente UE ni conforme au ZDR. La proposition de l’architecte échoue sur une contrainte factuelle.
3. **Le besoin de durabilité est réel,** mais il doit être satisfait autrement. L’**Agents SDK**, que la banque exécute dans sa propre infrastructure UE, offre une orchestration durable sous les propres contrôles de résidence et de rétention de la banque — les appels de modèle vont toujours à l’API, donc la banque doit aussi confirmer que l’endpoint du modèle satisfait ses conditions de données, mais le *harness* est le sien.
4. **Garder le moindre privilège.** Le shell et l’accès MCP au dépôt sont puissants ; scoper la connexion MCP en lecture seule où c’est possible et placer toute écriture/commit derrière une approbation.
5. **Ajouter du tracing** pour l’exécution de plusieurs heures afin que la migration soit auditable et récupérable.
6. **Considérer les subagents avec soin :** paralléliser la migration par module est attractif, mais dans le SDK la banque possède cette orchestration et ses implications de coût/limites de débit.
**Décision conforme à l’examen :** l’Agents API est inéligible à cause de la résidence UE et du ZDR (auto-héberger le sandbox n’y change rien) ; construire sur l’**Agents SDK** dans l’infrastructure de la banque avec un MCP au moindre privilège, des gates d’approbation sur les écritures, et un tracing complet. **Pas** « l’Agents API avec un sandbox auto-hébergé satisfait le ZDR ».
## Pièges d’évaluation
| Piège | Pourquoi il est tentant | Le discriminant |
| --- | --- | --- |
| « Un sandbox auto-hébergé vous donne le ZDR sur l’Agents API » | L’auto-hébergement ressemble à du contrôle | L’auto-hébergement contrôle l’exécution, pas la résidence/rétention de l’API |
| « Utiliser l’Agents API pour le projet UE » | Le harness managé est pratique | L’Agents API est US-uniquement, sans ZDR |
| « Donner à l’agent tous les outils pour la flexibilité » | Moins de bloqueurs | Le moindre privilège limite le rayon d’impact |
| « Autonomie signifie aucune approbation humaine » | L’automatisation totale semble avancée | Les actions irréversibles nécessitent un gate d’approbation |
| « Construire notre propre boucle d’agent de zéro » | Ça ressemble à du contrôle | L’Agents SDK est le framework code-first pour cela |
| « Responses + outils ne peut pas faire d’agents » | Les agents semblent nécessiter une API spéciale | Responses + outils est un runtime valide quand vous possédez la boucle |
| « Plus de subagents est toujours plus rapide » | Intuition du parallélisme | Les subagents non bornés font exploser le coût et les limites de débit ; les borner |
## Questions d’entraînement
Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler.
A. Responses API + outils.
B. L’Agents API avec son harness Codex managé.
C. Chat Completions.
D. Fine-tuning.
**Réponse : B.** L’Agents API exécute pour vous les sessions, l’orchestration, la compaction et la récupération — exactement le cas de durabilité managée. Responses + outils (A) signifie que vous possédez la boucle, Chat Completions (C) est legacy, et le fine-tuning (D) n’est pas un runtime.
A. L’Agents API.
B. L’Agents SDK open-source.
C. L’Assistants API.
D. La Batch API.
**Réponse : B.** L’Agents SDK est le framework open-source pour l’orchestration code-first que vous exécutez vous-même. L’Agents API (A) est managée par OpenAI, l’Assistants API (C) est legacy, et Batch (D) est pour les jobs bulk offline.
A. Oui, si vous activez le mode EU.
B. Non ; l’Agents API est en résidence de données US uniquement sans ZDR, et un sandbox auto-hébergé n’y change rien.
C. Oui, tant que vous utilisez un sandbox auto-hébergé.
D. Oui, le ZDR est activé par défaut.
**Réponse : B.** L’Agents API est US-uniquement sans ZDR, et auto-héberger le sandbox contrôle l’exécution, pas la résidence/rétention de l’API. Il n’y a pas de mode EU (A), le sandbox auto-hébergé ne lève pas la contrainte (C), et le ZDR n’est pas disponible (D).
A. Coller tout le dépôt dans le prompt.
B. Le connecter via un serveur MCP exposé à l’agent comme un outil.
C. Fine-tuner sur le dépôt.
D. Envoyer les fichiers par e-mail à OpenAI.
**Réponse : B.** MCP connecte les systèmes externes à un agent comme des outils via un protocole standard. Coller le dépôt (A) est impraticable et périmé, le fine-tuning (C) fige un instantané, et envoyer les fichiers par e-mail (D) n’est pas un mécanisme.
A. Un reasoning effort plus élevé.
B. Un gate d’approbation humaine sur l’action de remboursement, plus le tracing de la décision.
C. Une fenêtre de contexte plus grande.
D. Rien ; l’agent est de confiance.
**Réponse : B.** Les actions irréversibles et à fort enjeu nécessitent un gate d’approbation humaine et du tracing. L’effort (A) et le contexte (C) ne rendent pas une action irréversible sûre, et la confiance aveugle (D) retire le contrôle nécessaire.
A. OpenAI exécute les sessions, l’orchestration, la compaction du contexte et la récupération.
B. Il supporte la délégation aux subagents via `multi_agent` avec `max_concurrent_subagents`.
C. Il garantit la résidence de données UE.
D. Il offre le ZDR par défaut.
E. Il ne nécessite aucun header beta.
**Réponse : A et B.** Le harness managé exécute le cycle de vie de la session et supporte la délégation bornée aux subagents. Il est US-uniquement (contredisant C), n’a pas de ZDR (D), et nécessite `OpenAI-Beta: agents=v1` (E).
A. L’Agents API avec un sandbox hébergé.
B. La Responses API + outils, en possédant la boucle vous-même.
C. L’Agents SDK avec des subagents.
D. Fine-tuning.
**Réponse : B.** Pour un assistant simple utilisant un outil où vous contrôlez chaque appel et n’avez besoin d’aucune session/sandbox, Responses + outils est le runtime correct et le plus léger. L’Agents API (A) et les subagents SDK (C) ajoutent de la machinerie dont vous n’avez pas besoin, et le fine-tuning (D) est hors sujet.
A. Ils sont identiques.
B. Les handoffs passent le contrôle entre agents spécialistes pour le routage ; les subagents laissent un agent principal déléguer des sous-tâches en parallèle sous un même objectif.
C. Les handoffs sont moins chers parce qu’ils n’utilisent aucun modèle.
D. Les subagents n’existent que dans Chat Completions.
**Réponse : B.** Les handoffs routent entre spécialistes ; les subagents parallélisent des sous-tâches sous un agent principal. Ils ne sont pas identiques (A), les handoffs utilisent toujours des modèles (C), et les subagents sont une fonctionnalité harness/SDK, pas de Chat Completions (D).
A. C’est requis syntaxiquement, sinon l’appel échoue.
B. Pour garder le coût et la consommation de limite de débit prévisibles tout en parallélisant le travail.
C. Parce que les subagents ne peuvent pas du tout s’exécuter en parallèle.
D. Pour désactiver le tracing.
**Réponse : B.** Borner la concurrence contrôle le coût et la pression sur les limites de débit tout en conservant le parallélisme. C’est un choix de réglage, pas une exigence syntaxique (A) ; les subagents peuvent s’exécuter en parallèle (C) ; et cela n’a rien à voir avec le tracing (D).
A. Aucun ; plus d’accès est plus sûr.
B. Le moindre privilège ; n’accorder que l’outil/scope de lecture des commandes dont la tâche a besoin.
C. L’absence d’état ; ne rien stocker.
D. Le streaming ; l’activer.
**Réponse : B.** Surprovisionner les outils viole le moindre privilège et agrandit le rayon d’impact ; scoper à ce dont la tâche a besoin. Plus d’accès n’est pas plus sûr (A), et l’absence d’état (C) et le streaming (D) sont sans rapport avec le problème d’accès.
A. Il est open-source et s’exécute dans la propre infrastructure de l’équipe.
B. Il donne un contrôle code-first de l’orchestration, des guardrails et du sandboxing.
C. Il force toutes les données à travers des sessions US managées par OpenAI.
D. Il supprime le besoin d’appeler tout modèle.
E. Il désactive l’observabilité.
**Réponse : A et B.** Le SDK est auto-exécuté et code-first, donc l’équipe contrôle l’orchestration et l’exécution sous sa propre gouvernance. Il ne force pas de sessions US managées (C), il appelle toujours des modèles (D), et il inclut l’observabilité plutôt que de la désactiver (E).
A. Un modèle plus grand.
B. Le tracing/observabilité qui enregistre chaque étape, appel d’outil et résultat pour inspection.
C. Plus de subagents.
D. Un reasoning effort plus bas.
**Réponse : B.** Le tracing enregistre les étapes de l’agent pour que les échecs puissent être diagnostiqués et audités. Un modèle plus grand (A) n’explique pas les actions passées, les subagents (C) ajoutent de la complexité, et baisser l’effort (D) n’ajoute pas de visibilité.
A. Les deux sont entièrement gratuits.
B. Tarifs API du modèle plus tarifs d’outils standard plus tarifs conteneur pour le sandbox hébergé ; l’auto-hébergement déplace l’exécution vers votre infrastructure.
C. Uniquement un forfait mensuel fixe.
D. Les sandboxes auto-hébergés coûtent plus cher que les hébergés dans tous les cas.
**Réponse : B.** La facturation de l’Agents API est tarifs du modèle + tarifs d’outils + tarifs conteneur pour les sandboxes hébergés ; l’auto-hébergement déplace l’exécution (et son coût) vers vous. Aucun n’est gratuit (A), il n’y a pas de modèle à forfait fixe uniquement (C), et l’auto-hébergé n’est pas universellement plus cher (D).
A. Augmenter la fenêtre de contexte.
B. Des guardrails d’entrée/sortie qui détectent et bloquent les instructions injectées et l’usage d’outils dangereux.
C. Passer à l’Agents API.
D. Ajouter plus de subagents.
**Réponse : B.** Les guardrails valident les entrées et sorties et peuvent bloquer les instructions injectées et les actions d’outils dangereuses. La taille du contexte (A), le choix de runtime (C) et les subagents (D) n’arrêtent pas à eux seuls l’exfiltration pilotée par prompt-injection.
A. Responses + outils, en construisant à la main la récupération de session.
B. L’Agents API avec un sandbox hébergé.
C. La Batch API.
D. Fine-tuner un modèle.
**Réponse : B.** Sans contrainte de résidence/ZDR, la durabilité managée de l’Agents API et le sandbox hébergé sont le chemin le plus rapide. Construire la récupération à la main sur Responses (A) réinvente le harness, Batch (C) est pour les jobs bulk offline, et le fine-tuning (D) n’est pas un runtime.
A. Délégation parallèle par subagents.
B. Handoff multi-agent entre spécialistes.
C. Prompt caching.
D. Sorties structurées.
**Réponse : B.** Passer le contrôle entre agents spécialistes par sujet est le pattern de handoff multi-agent. Les subagents (A) parallélisent des sous-tâches sous un même objectif, et le caching (C) et les sorties structurées (D) sont des fonctionnalités sans rapport.
## Points clés à retenir
- Trois runtimes : Responses + outils (vous possédez la boucle), Agents SDK (code-first, vous l’exécutez), Agents API (harness Codex managé par OpenAI).
- Choisissez selon la durabilité managée, l’orchestration personnalisée et la simplicité — et vérifiez la résidence/le ZDR en premier.
- L’Agents API est US-uniquement sans ZDR ; un sandbox auto-hébergé contrôle l’exécution, pas ces conditions.
- Les agents agissent à travers des outils dont MCP ; accordez le moindre privilège pour limiter le rayon d’impact.
- Utilisez les handoffs multi-agent pour le routage et les subagents bornés pour les sous-tâches en parallèle.
- Placez les actions irréversibles derrière des approbations humaines et ajoutez des guardrails contre l’injection.
- Ajoutez toujours du tracing/observabilité pour que le comportement de l’agent soit auditable et débogable.