Interactive AI agents for the Data Vault: the direct API approach

L'article précédent montrait comment l'orchestration simple automatise les tâches répétitives. Mais que se passe-t-il quand vous avez besoin d'un dialogue itératif ? C'est là que les architectures agents excellent.

What Makes a System 'Agent-Based'

Un système agentique va au-delà de l'exécution de workflows prédéfinis — il prend des décisions basées sur le contexte et ajuste son approche dynamiquement. Trois capacités définissent cela :

• Usage d'outils : l'agent sélectionne parmi plusieurs APIs disponibles selon la situation
• Prise de décision : après chaque action, il évalue le résultat et décide de la suite
• Résolution itérative : il raffine son approche jusqu'à atteindre l'objectif

La différence clé : l'orchestration simple suit un chemin prédéterminé. Les systèmes agents tracent leur propre route vers un objectif.

Use case: Information Mart creation agent

Le défi. Les utilisateurs métier connaissent les insights dont ils ont besoin mais manquent de compétences SQL. Les ingénieurs passent des heures sur du SQL répétitif suivant des patterns prévisibles. Les deux scénarios bénéficient d'une assistance IA qui comprend le contexte.

L'architecture. Un agent avec un seul outil d'accès aux métadonnées du modèle Data Vault, et un system prompt contenant des templates SQL avec placeholders.

System prompt utilisé :

You are a SQL expert helping business users create dimensions in a Data Vault
architecture. You will utilize the specific SQL template provided for creating a
dimension based on a hub with a snapshot.
 
Template:
 
DROP VIEW IF EXISTS im.dim_[hub_name] CASCADE;
 
CREATE VIEW im.dim_[hub_name] AS
SELECT 
    pit.bk_bk AS [hub_name]_id
    ,info.[satellite_column] AS [hub_name]_[satellite_column]
    ,pit.snapshot_date 
FROM bv.h_pit_[hub_name]_[snapshot_name] pit 
INNER JOIN dv.sh_[hub_name]_[satellite_name] info 
    ON info.hk = pit.[hub_name]_[satellite_name]_hk 
    AND info.load_dts = pit.[hub_name]_[satellite_name]_load_dts;

Comment ça marche en pratique :

Requête utilisateur : "J'ai besoin d'une dimension client avec le snapshot journalier. Inclure nom de l'entreprise, secteur d'activité et nombre d'employés."

L'agent : interroge les métadonnées → identifie les tables correspondantes → remplace les placeholders → génère le SQL complet → présente pour validation.

Raffinement : "Ajoute un champ tier : 'Enterprise' pour >1000 employés..." → l'agent ajoute un CASE statement et régénère.

Ce qui prenait une heure manuellement est fait en deux minutes.

What it delivers

Pour les utilisateurs techniques : développement accéléré, rôle qui passe d'exécutant à reviewer, meilleure précision grâce à l'encodage cohérent des métadonnées.

Pour l'organisation : time-to-implementation de quelques heures à quelques minutes, capacité d'ingénierie libérée pour du travail stratégique, qualité maintenue car l'agent applique les best practices de façon cohérente.

The limits of this approach

Prolifération des outils. Les agents fonctionnent mieux avec peu d'outils clairs. Trop d'APIs disponibles → erreurs d'orchestration, usage de tokens accru, comportement moins prévisible.

Burden de configuration. Chaque endpoint API doit être mappé à un outil. Et avec de nouveaux frameworks agent qui arrivent constamment, changer de plateforme signifie reconstruire toute la configuration.

Ces limitations pointent vers une approche plus sophistiquée : les serveurs MCP.