The first time I handed an agent a schema instead of a paragraph, the hallucinations just… stopped.
✦ LACAUSE · Dexter & his Assistant
Most “agent reliability” problems aren’t reasoning problems. They’re interface problems. We ask a model to behave like a careful API client, then hand it a blurry, prose description of the API and act surprised when it guesses.
The fix is unglamorous: give the model typed tools. A name, a strict input schema, a documented output. Not “you can search the order book” buried in a system prompt — an actual contract the runtime can validate.
Prose is lossy, schemas are not
A prompt that says “pass the symbol and a side” leaves a dozen open questions: is it BTC or BTC-USD? Is side "buy" or 1? When the answer lives in a schema, the model stops inventing and starts conforming — and when it gets it wrong, you reject at the boundary instead of three steps downstream.
FIG. I — Schematic. Hand the model prose and a malformed call slips through the tool, only failing several steps later — all that work wasted. A typed tool rejects the same call at the boundary, before it can touch anything downstream.
Make the wrong call impossible to express, and the model stops trying to express it.
What changed in practice
Fewer retries. Validation errors are caught at the tool edge, with a precise message the model can act on.
Smaller prompts. The contract carries the detail, so the system prompt shrinks to intent.
Composability. Typed tools snap together across a swarm without anyone re-explaining the format.
None of this is novel. It’s just the boring discipline of treating the model like the capable, literal-minded client it is. Tighten the interface and most of the “magic prompting” evaporates.
That’s the whole thesis behind the MCP work in the Workshop: sharp, typed tools instead of blunt prompts. Honest tools, no theatre.
La plupart des problèmes de « fiabilité des agents » ne sont pas des problèmes de raisonnement. Ce sont des problèmes d’interface. On demande à un modèle de se comporter comme un client d’API rigoureux, puis on lui tend une description floue de l’API, en prose — et on s’étonne qu’il devine.
Le correctif n’a rien de glamour : donnez au modèle des outils typés. Un nom, un schéma d’entrée strict, une sortie documentée. Pas « tu peux consulter le carnet d’ordres » noyé dans un prompt système — un véritable contrat que le runtime peut valider.
La prose perd de l’information, pas les schémas
Un prompt qui dit « passe le symbole et un sens » laisse une dizaine de questions ouvertes : est-ce BTC ou BTC-USD ? Le sens, c’est "buy" ou 1 ? Quand la réponse vit dans un schéma, le modèle cesse d’inventer et se met à se conformer — et quand il se trompe, on rejette à la frontière plutôt que trois étapes plus loin.
FIG. I — Schéma. Donnez de la prose au modèle et un appel malformé franchit l’outil, pour n’échouer que plusieurs étapes plus loin — tout ce travail perdu. Un outil typé rejette le même appel à la frontière, avant qu’il ne touche quoi que ce soit en aval.
Rendez l’erreur impossible à exprimer, et le modèle cesse d’essayer de l’exprimer.
Ce qui a changé en pratique
Moins de tentatives. Les erreurs de validation sont attrapées au bord de l’outil, avec un message précis sur lequel le modèle peut agir.
Des prompts plus courts. Le contrat porte le détail, donc le prompt système se réduit à l’intention.
Composabilité. Les outils typés s’emboîtent à travers un essaim sans que personne ne réexplique le format.
Rien de tout cela n’est nouveau. C’est juste la discipline ingrate de traiter le modèle pour ce qu’il est : un client capable et littéral. Resserrez l’interface et l’essentiel du « prompting magique » s’évapore.
C’est toute la thèse derrière le travail MCP de l’Atelier : des outils nets et typés plutôt que des prompts vagues. Des outils honnêtes, sans théâtre.