Griptape : un cadre Python modulaire pour agents et workflows, assemblé par drivers

Le problème visé : changer de fournisseur sans réécrire la logique métier

Le README énonce l'objectif sans détour : les Drivers permettent de remplacer une fonctionnalité et un fournisseur avec un minimum de changements dans la logique métier. C'est le point central du projet. Une application LLM typique mélange trois choses : l'appel au modèle, la récupération de contexte, et le stockage de fichiers ou de vecteurs. Quand ces trois couches sont soudées, changer de modèle ou passer d'un magasin vectoriel à un autre devient une refonte. Griptape sépare ces couches en classes de Drivers nommées par usage : Prompt Drivers pour le texte et les images, Embedding Drivers pour les vecteurs, Vector Store Drivers pour le stockage, File Manager Drivers pour les fichiers locaux ou distants, SQL Drivers pour les bases relationnelles. Le public visé est donc l'équipe Python qui construit une application d'agent et veut pouvoir arbitrer ses dépendances fournisseur plus tard, sans réécrire ses Tasks. Ce n'est pas un outil pour quelqu'un qui veut un résultat en une soirée sans lire de documentation.

Trois Structures, deux modes d'exécution

Griptape distingue trois Structures. Un Agent contient une seule Task, configurée pour un comportement propre aux agents. Un Pipeline organise une séquence de Tasks où la sortie de l'une peut alimenter la suivante. Un Workflow configure des Tasks pour qu'elles s'exécutent en parallèle. Cette séparation est plus qu'une commodité de nommage : elle fixe le mode d'exécution dès la construction de l'objet. Le README ne décrit pas de mécanisme de bascule d'un mode à l'autre en cours d'exécution, ni de gestion d'état persistante entre les deux. Si votre besoin est un graphe avec reprise après incident, cette architecture ne le promet pas. Le deuxième exemple du README montre d'ailleurs un Workflow construit avec une liste de listes de Tasks, où chaque sous-liste représente un groupe exécuté en parallèle : quatre projets sont traités simultanément, chacun avec sa propre PromptTask identifiée par un id du type project-griptape. La parallélisation est donc déclarée à la construction, pas décidée dynamiquement.

Tasks, mémoire et artefacts : ce qui circule entre les étapes

Les Tasks sont décrites comme les briques de base à l'intérieur des Structures, et c'est par elles que passent les interactions avec les Engines, les Tools et le reste. Trois formes de mémoire sont proposées et elles ne jouent pas le même rôle. La Conversation Memory permet au LLM de retenir et de retrouver de l'information entre les échanges. La Task Memory garde les sorties de Task volumineuses ou sensibles hors du prompt envoyé au LLM, ce qui répond à un problème concret : une sortie de plusieurs milliers de tokens n'a pas à être recollée dans le contexte si seule une partie est utile. La Meta Memory ajoute des métadonnées au contexte. Le README ne précise pas comment la Task Memory décide de ce qui reste hors du prompt ni comment le modèle y accède ensuite. C'est une zone où la documentation en ligne devra être consultée avant de bâtir une architecture dessus. Les Artifacts, eux, servent à faire circuler des données de types différents entre composants, ce qui évite de tout ramener à des chaînes de caractères.

Mise en route : le strict nécessaire

L'installation n'est pas détaillée dans le README, qui renvoie à la documentation pour l'installation et l'usage. Le paquet s'appelle griptape sur PyPI, ce que confirme le badge de version en tête de fichier. L'exemple minimal tient en quelques lignes : on importe OpenAiChatPromptDriver depuis griptape.drivers.prompt.openai, Rule depuis griptape.rules, et PromptTask depuis griptape.tasks. On instancie PromptTask avec prompt_driver et une liste de rules, ici une seule Rule qui limite la réponse à quelques phrases, puis on appelle task.run avec la question et on lit result.value. Le second exemple importe DuckDuckGoWebSearchDriver depuis griptape.drivers.web_search.duck_duck_go, ainsi que Rule et Ruleset, Workflow, PromptTask et TextSummaryTask, et les Tools WebScraperTool et WebSearchTool. On y voit aussi StructureVisualizer depuis griptape.utils, et un modèle de sortie défini avec pydantic.BaseModel comportant une liste de Feature. Attention à un détail qui saute aux yeux : les deux exemples utilisent des chemins d'import différents pour le même driver OpenAI, l'un passant par griptape.drivers.prompt.openai et l'autre par griptape.drivers.prompt.openai_chat_prompt_driver. Le README ne dit pas lequel est la forme canonique. Vérifiez ce point sur la version que vous installez avant de copier un exemple.

Engines et Tools : ce que le cadre fournit déjà

Quatre Engines encapsulent des cas d'usage précis au-dessus des Drivers. Le RAG Engine est présenté comme une abstraction pour construire des pipelines de Retrieval Augmented Generation modulaires. L'Extraction Engine extrait des données JSON ou CSV à partir de texte non structuré. Le Summary Engine produit des résumés. L'Eval Engine évalue et note la qualité d'un texte généré. Ces Engines évitent de recâbler soi-même l'enchaînement découpage, embedding, recherche, génération. Les composants annexes complètent l'ensemble : Rulesets pour orienter le comportement du modèle avec peu d'ingénierie de prompt, Loaders pour charger des données depuis diverses sources, Chunkers pour segmenter les textes selon leur type, Tokenizers pour compter les tokens et ne pas dépasser la limite du modèle. Ce dernier point mérite l'attention : le comptage de tokens est un composant de premier plan, pas un détail, ce qui indique que le cadre est pensé pour des entrées longues. Les Tools, intégrés ou personnalisés, donnent au LLM de quoi agir sur des données et des services.

Limites visibles et cas où l'outil ne convient pas

Le README est un inventaire de composants, pas un guide d'exploitation. Il ne dit rien sur la gestion des erreurs d'un Driver, sur les tentatives de reprise, sur les coûts d'appel, ni sur le comportement d'un Workflow quand une branche parallèle échoue. Ces silences ne prouvent pas que ces mécanismes n'existent pas, mais ils signifient qu'on ne peut pas les tenir pour acquis à la lecture de la page principale. Autre limite de périmètre : le projet renvoie explicitement vers Griptape Nodes, une application desktop visuelle, pour une expérience sans code. Si votre besoin est de laisser une personne non développeuse composer des workflows, Griptape seul n'est pas la réponse, et le README le dit lui-même. Enfin, la modularité a un prix : chaque capacité passe par un Driver à choisir, configurer et maintenir. Une application qui n'appellera jamais qu'un seul fournisseur de modèles et n'utilisera qu'un seul magasin de vecteurs paiera cette abstraction sans jamais en tirer bénéfice, et se retrouvera avec davantage de classes à comprendre pour le même résultat.

Face à LangChain : deux façons de découper le problème

LangChain apparaît dans le second exemple du README, cité comme l'un des projets que le workflow de recherche est censé étudier, aux côtés de crew-ai et pydantic-ai. Ce n'est donc pas un concurrent caché, c'est un voisin assumé. La différence d'approche tient à la granularité de l'abstraction. Griptape nomme chaque Driver par usage et par fournisseur, avec des chemins d'import explicites comme griptape.drivers.vector_store ou griptape.drivers.prompt.openai, et répartit le travail entre Structures, Tasks, Engines, Tools, Loaders, Chunkers et Tokenizers. LangChain, de son côté, s'est construit autour d'un vocabulaire de chaînes et d'intégrations, avec un catalogue d'adaptateurs très large. Le choix se joue sur ce que vous voulez posséder : si vous préférez composer des chaînes existantes et piocher dans un vaste écosystème d'intégrations, l'approche LangChain est plus directe. Si vous voulez une séparation nette entre la logique métier et le fournisseur, avec un vocabulaire stable côté application, la structure de Griptape est plus lisible. Aucun des deux n'est gratuit en apprentissage.

Maintenance, versionnement et licence

Le rythme de publication est régulier et rapproché : v1.13.0 le 26 août 2026, v1.12.0 le 10 août 2026, v1.11.0 le 14 juillet 2026, avec un dernier push sur main au 8 septembre 2026. Le projet n'est pas archivé. Cette cadence a une conséquence pratique : les numéros mineurs s'enchaînent toutes les deux à quatre semaines environ, donc une application épinglée sur une version ancienne accumule de l'écart. Le README ne décrit pas de politique de compatibilité entre versions mineures, et il ne faut pas la supposer. Le projet est sous licence Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec des obligations de conservation des mentions de copyright et de licence, et une clause de brevets. Ce paragraphe décrit la licence telle qu'elle est déclarée dans le dépôt ; il ne constitue pas un avis juridique, et une équipe qui redistribue le paquet ou le modifie doit faire lire le texte de la licence par qui de droit. Côté coût de maintenance, le travail se concentre là où vous ajoutez des Drivers et des Tools personnalisés : c'est votre code, pas celui du cadre, et c'est lui qu'il faudra suivre lors des montées de version.

Conclusion éditoriale

Griptape convient aux équipes Python qui veulent garder la main sur le choix des fournisseurs LLM et sur la structure d'exécution, sans écrire leur propre couche d'abstraction. Il convient mal à qui cherche un orchestrateur déclaratif avec gestion d'état persistante, ou un produit no-code : la documentation renvoie alors vers Griptape Nodes, une application desktop distincte. Avant d'adopter, vérifiez deux choses concrètes : quels Drivers existent pour vos fournisseurs, et si votre cas relève d'un Workflow parallèle ou d'un Pipeline séquentiel, car le README décrit ces deux Structures comme des modes d'exécution différents et non interchangeables.

Sources officielles

1. griptape-ai/griptape on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases