Automatise les ops avec des agents IA qui surveillent chaque systèmeet t'alertent avant que ça casse.

Non, pas par défaut. Posts Slack, updates Jira, writes Linear et email sortant sont HITL-gated pour cette équipe d'agents IA. L'agent prépare l'action et attend l'approbation en un clic. Tu peux lever le gate par template une fois que tu fais confiance au run.

Trois manières. Static context attache ton runbook, la matrice SLA et la rota on-call à des personas spécifiques à chaque run. Le outilrag_retrieve laisse ReportingAnalyst et ComplianceOperations tirer depuis dictionnaires de données et docs de policy à la demande. La mémoire cross-run porte les incidents ouverts d'hier dans le stand-up d'aujourd'hui donc rien ne se réinitialise à minuit.

C'est plus proche d'une alternative Zapier pour les étapes de raisonnement, et d'une alternative n8n pour la plomberie de schedule et webhook. Là où Zapier et Make.com chaînent des actions fixes, Melaya fait tourner des agents de raisonnement entre les étapes pour qu'un incident soit triagé, pas juste routé.

Chaque rapport cite la query SQL, le row count, le timestamp de freshness et le flag de qualité de données. ReportingAnalyst est obligé d'attacher la query source et le check de staleness avant qu'un output ne parte. Le COO lit des chiffres et de la provenance, pas des adjectifs.

N'importe lesquels. Claude sur OperationsSynth où le raisonnement multi-source justifie le coût, GPT sur le drafting ExecutiveAssistant, un Ollama local sur TradingOperations quand la donnée de balance ne doit pas quitter ton réseau. Chaque persona choisit son propre modèle.

Avec Slack, Jira et un DSN de database connectés, le pipeline de health-check du matin est un canvas à 4 nœuds : trigger sur cron, vérifie la matrice API, build la table de statut, post sur Slack. La plupart des équipes le livrent dans une session de travail et ont le premier brief en channel le lendemain matin.

IncidentManager classe chaque anomalie en SEV1, SEV2 ou SEV3 en utilisant les règles dans ton Static context. SEV1 route vers Telegram et Slack avec l'owner on-call tagué. SEV3 reste dans le digest quotidien. L'audit log capture la classification, l'escalade et les timestamps de résolution.

Chaque run log chaque appel d'outil, chaque invocation de modèle, chaque décision d'approbation et chaque retry. Rejoue n'importe quel run à tout moment. L'audit trail couvre la source de données, la query, le check de freshness et l'approver humain, donc compliance ops peut reconstruire n'importe quel brief du matin.

Oui. Les outils sont scoped par agent dans le canvas. Tu peux donner à DataOperations http_request et sql_query en read-only, alors que seul IncidentManager porte jira_create_issue et linear_create_issue. Les scopes sont appliqués avant même que le modèle ne voie le tool.

Connecteurs natifs pour Slack, Telegram, Discord, Gmail, Google Calendar, Jira, Linear, Postgres, SQLite, Excel, Word et PowerPoint. Le bundle melaya_exec lit les positions et balances live depuis les mêmes clés exchange que ton trading desk utilise déjà.

Écris un script cron si tu as une seule vérification et un seul responsable. Le crew Operations de Melaya planifie entre les étapes : Data Operations surveille la fraîcheur des feeds par rapport aux SLAs nommés, Incident Manager crée le ticket SEV, et Operations Synthesis rapporte le résultat. Les scripts échouent silencieusement. Melaya retourne des motifs d'échec typés, enregistre des traces de run complètes, et met en pause chaque écriture pour approbation humaine.

Oui. Sauvegarde n'importe quelle run comme template et redéploie-la avec de nouveaux identifiants. Le bundle database passe des DSNs scopés par agent, donc Reporting Analyst n'accède qu'aux schémas que tu listes pour chaque desk. Le routage de modèles par étape parmi 23 fournisseurs est conservé, et chaque clone garde ses propres traces de run et gates d'approbation.

Melaya fait tourner une évaluation deterministic-first : les vérifications basées sur des règles sur les comptages de lignes et la fraîcheur s'exécutent avant toute revue par modèle. Reporting Analyst valide le tirage du warehouse, Operations Synthesis compile le brief en quatre sections, et slack_post_text reste soumis à une gate HITL (validation humaine), donc un humain approuve le compte-rendu avant qu'il ne soit posté. Chaque étape atterrit dans la trace de run avec les inputs et outputs.

Non. Melaya tourne dans le cloud ou sur ton runner local, donc les étapes de base de données sensibles s'exécutent à l'intérieur de ton réseau. Le bundle database passe des DSNs scopés par agent, Reporting Analyst et Data Operations n'interrogent que les schémas que tu listes, et le routage de modèles par étape permet à ces étapes d'utiliser un modèle local pendant que d'autres étapes tournent dans le cloud.

Oui. Le Device Control de Melaya opère un vrai téléphone Android : l'agent ouvre l'appli autorisée, lit l'écran, et rapporte le statut dans la même timeline d'incident qu'Incident Manager gère. Pour les fournisseurs avec des pages de statut, le bundle core fait des polls via http_request à la place. Toute action sur l'appareil qui publie marque une pause pour approbation sur le téléphone lui-même.