OrbitWake Agents
Vue d’ensemble
OrbitWake Agents est actuellement une surface Preview. L’espace authentifié expose volontairement son état système au lieu d’afficher de faux agents : le runtime d’agents réel n’est pas encore disponible dans cette build.
Statut actuel : Preview
La page /app/agents est présente dans le produit, mais elle ne fournit pas encore un inventaire d’agents, un builder fonctionnel ou une exécution de workflows.
L’interface actuelle indique explicitement que le runtime d’agents n’est pas exposé. OrbitWake préfère afficher cette limite plutôt que remplir la page avec des agents de démonstration qui pourraient être confondus avec de vraies ressources utilisateur.
Ce qui est réellement visible aujourd’hui
| Surface | État actuel |
|---|---|
| Page Agents dans l’espace | Disponible avec le statut Preview. |
| Inventaire d’agents | Non exposé. Aucun inventaire factice n’est généré. |
| Runtime d’exécution | Non exposé dans cette build. |
| Création d’agents | Pas encore disponible comme workflow stable dans l’espace. |
| Sessions d’agents | Pas encore exposées comme données runtime réelles. |
| Permissions des connecteurs | Déjà réelles et gérées indépendamment du runtime Agents. |
Le modèle conceptuel Agents
La présentation publique d’OrbitWake Agents utilise quatre notions pour décrire le modèle visé : Trigger, Context, Tools et Review.
Ces notions servent à expliquer comment un agent devrait être structuré lorsqu’un runtime stable sera disponible. Elles ne constituent pas, à elles seules, une preuve qu’un builder complet ou qu’un système de déclenchement est déjà actif.
| Concept | Rôle | Statut dans la build actuelle |
|---|---|---|
| Trigger | Définit ce qui démarrerait le workflow. | Concept produit ; runtime non exposé. |
| Context | Délimite les informations nécessaires à la tâche. | Concept produit ; aucune session d’agent réelle affichée. |
| Tools | Définit les actions externes autorisées. | Le système de connecteurs existe, mais n’est pas encore présenté comme un runtime Agents actif. |
| Review | Permet de revoir le résultat et les actions sensibles. | Les mécanismes d’approbation existent côté Connectors ; le workflow Agents n’est pas encore exposé. |
Contexte et portée du workspace
Le positionnement d’Agents est celui d’un worker réutilisable qui agit à l’intérieur d’un workspace avec un contexte défini. Cette direction est déjà visible dans les surfaces marketing, mais le produit authentifié ne fournit pas encore une configuration persistante d’agent à documenter comme API stable.
La documentation ne doit donc pas promettre aujourd’hui une sélection automatique de mémoire, de fichiers, de conversations ou de projets par un agent autonome.
Lorsque le runtime sera exposé, cette section pourra préciser quelles sources de contexte sont réellement supportées et comment elles sont isolées entre workspaces.
Agents et Connectors
Le système Connectors est déjà une brique réelle d’OrbitWake. Il définit des actions de lecture, d’écriture et des actions sensibles, avec des règles de portée et d’approbation.
Le code de la page Agents actuelle rappelle que les permissions de connecteurs restent soumises à approbation. Cela signifie qu’un futur runtime Agents ne devra pas être documenté comme un moyen de contourner les permissions d’un connecteur.
Un agent ne devrait pouvoir utiliser qu’un outil réellement connecté, autorisé pour la ressource concernée et permis par les règles de l’action. La documentation détaillée de cette relation sera publiée lorsque l’exécution Agents sera effectivement branchée sur ces outils.
Approvals et actions sensibles
OrbitWake possède déjà un mécanisme d’approbation pour certaines actions de connecteurs. Une action sensible peut être suspendue jusqu’à une décision explicite de l’utilisateur.
Cette capacité est importante pour le futur modèle Agents, mais elle appartient aujourd’hui au système Connectors. Il serait incorrect d’affirmer qu’un agent actuellement exécutable déclenche déjà ces demandes d’approbation, puisque le runtime Agents n’est pas exposé.
Ce qui n’est pas encore documenté comme disponible
Tant que le runtime réel n’est pas exposé, ne présentez pas les capacités suivantes comme des fonctions utilisables :
| Capacité | État |
|---|---|
| Créer et enregistrer un agent depuis l’espace | Non disponible comme workflow stable. |
| Lancer manuellement un agent réel | Runtime non exposé. |
| Programmer un agent | Non documenté comme capacité stable. |
| Configurer des triggers | Concept visible, pas de runtime stable exposé. |
| Voir un historique réel de runs Agents | Non exposé. |
| Rejouer, interrompre ou reprendre une session Agents | Non exposé. |
| Attribuer des outils à un agent depuis un builder actif | Non exposé. |
Différence entre la page publique et le produit authentifié
La page publique OrbitWake Agents présente la direction du produit avec des représentations de builder, de permissions, de flux d’exécution et de réutilisation.
Ces éléments servent à communiquer le modèle produit. La source de vérité pour les capacités disponibles reste cependant l’espace authentifié et son runtime réel.
Aujourd’hui, l’espace authentifié affiche clairement Preview et indique que le runtime n’est pas exposé. La documentation Developers suit donc cet état plutôt que d’interpréter les démonstrations marketing comme des fonctionnalités déjà livrées.
Comment travailler avec Agents aujourd’hui
Pour le moment, utilisez la surface Agents comme un indicateur de disponibilité et non comme un workflow d’automatisation actif.
Les tâches qui nécessitent aujourd’hui des opérations externes doivent continuer à passer par les surfaces réellement disponibles, notamment AI, Code et Connectors, avec leurs permissions et leurs approbations propres.
Lorsqu’un runtime Agents réel sera activé, cette documentation sera étendue avec le cycle complet : création, configuration, outils, exécution, approbations, résultats et sessions.
Quand les prochaines pages seront publiées
Les sous-pages Créer des agents, Outils, Permissions et Sessions resteront des entrées de recherche tant que leurs capacités ne sont pas assez stables pour être décrites sans spéculation.
Une page détaillée ne doit être publiée que lorsque l’interface correspondante existe, que les données affichées sont réelles et que le comportement peut être vérifié dans le produit.
Cette règle évite que la documentation prenne de l’avance sur le runtime et protège les utilisateurs contre des instructions qui ne fonctionneraient pas encore.
Limites actuelles
Agents est en Preview et ne possède pas encore de runtime exposé dans cette build. Il n’existe donc pas encore de procédure Developers officielle pour créer, exécuter ou administrer un agent depuis l’espace.
Les représentations de workflows présentes sur la page marketing doivent être considérées comme des illustrations de direction produit, pas comme une référence d’API ou d’interface disponible.
Les permissions Connectors restent valides indépendamment d’Agents et constituent aujourd’hui le garde-fou réel pour les actions externes supportées.
Étapes suivantes
La prochaine page Agents sera ajoutée lorsqu’une capacité stable supplémentaire pourra être documentée sans invention. En attendant, la suite utile est la documentation Connectors, qui décrit les intégrations et permissions déjà réelles.