Panel, l'espace de travail pour la recherche assistée par agent
En bref
- Panel est une application locale qui crée un espace de travail unifié pour les chercheurs : chat avec un agent, fichiers, PDFs, notebooks Jupyter et visualiseurs personnalisés dans des panneaux dockables.
- L'agent peut créer ses propres panneaux (viewers SQLite, structures protéiques) à la demande et générer des modules avec suivi de progression.
- Le projet fonctionne actuellement avec Claude Code uniquement ; Python 3.12+, Node 22.18+ et uv sont requis pour l'installation locale.
- Un système précoce de "Modules" permet de composer des tâches longues avec entrées/sorties typées et observabilité intermédiaire.
Ce que dit la source
L'auteur a identifié un friction majeure en recherche : jongler constamment entre un chat agent, les papers, les notebooks et les fichiers de données. Panel propose une interface unifiée basée sur des panneaux dockables (Vue + dockview en frontend, FastAPI + Python en sidecar) où l'agent fonctionne comme collaborateur dans le même workspace, peut créer des visualiseurs sur demande et orchestrer des modules de recherche (literature review et hypothesis generation) avec traçabilité des étapes intermédiaires.
- L'interface repose sur des Panes dockables (fichiers, PDFs, markdown, Jupyter notebooks) où le chat et l'agent cohabitent ; les notebooks tournent contre un vrai kernel et peuvent être édités conjointement.
- Les Modules généralisent le concept : ils ont des entrées/sorties typées et des étapes intermédiaires observables, permettant des workflows en chaîne et du suivi de progression pour les tâches longues.
- L'agent peut créer des panneaux personnalisés (viewer de structures protéiques, navigateur SQLite) quand la UI par défaut ne suffit pas.
- Stockage local dans ~/Panel/panel.db (conversations et actions d'agent) et ~/Panel/workspaces (dossiers de travail isolés avec chats et layouts sauvegardés).
- Limitation critique : seul Claude Code est entièrement supporté actuellement ; OpenAI API ne peut faire que le chat et les outils, pas la literature review ni la hypothesis generation qui demandent une recherche web.
Dans les commentaires
Débat plutôt enthousiaste et comparatif : plusieurs commentateurs signalent avoir exploré des idées similaires (agents modifiant l'UI en temps réel, panneaux dynamiques générés), mais le fil reste maigre en critique constructive ou tests en profondeur. Peu de questions sur la robustesse en workflows réels.
- Plusieurs commentateurs mentionnent des projets parallèles (IDE auto-modifiables avec agents, éditeurs Emacs avec LLM), ce qui suggère que l'espace est exploré mais pas dominé : le différenciateur de Panel n'est pas évident.
- Un commentateur demande explicitement si Panel supporte les MCP servers pour intégrer avec d'autres agents et workflows, absence de réponse de l'auteur observable, indiquant une lacune d'intégration standard.
- Absence de checkpoints mentionnée comme critique pour un workflow agentic : pas de réponse de l'auteur sur ce point.
- Le projet est décrit comme "très brut" et limité à Claude Code ; plusieurs frictions pratiques (erreurs de connection, ports occupés) suggèrent une immaturité.
Alternatives citées : Emacs + gptel (mentionné pour la capacité de self-modification LISP) ; slices-ide (IDE auto-modifiable avec agents et timeline globale d'undo/redo) ; architecture Airtable-like basée sur data models et hooks (hobby project d'un commentateur)
Notre lecture
Panel adresse un vrai pain point pour les chercheurs : regrouper chat, code, données et visualisations dans une seule interface collaborative avec agent. L'approche est locale et transparente (tout reste sur la machine), ce qui est rassurant. Cependant, l'écosystème reste restreint : une seule plateforme d'agent supportée (Claude Code), pas de MCP servers, pas de checkpoints pour reprendre après erreur, les éléments qui rendraient cela productif en usage réel. À surveiller pour les équipes de recherche utilisant Claude Code, mais trop immature pour une déploiement au-delà du prototypage. Les idées sous-jacentes (modules typés, intermediates observables) sont intéressantes mais insuffisamment validées en workflow complexe.