Organiser les modèles, le contexte et les outils pour conduire des projets complexes.
Notre premier benchmark interne porte sur des audits de code consacrés à la détection de bugs et de failles de sécurité. Les configurations comparées utilisent le même modèle, Gemini 4 Argon, afin de limiter l’effet du choix de modèle sur les résultats.
Sur ce périmètre, Uly Code obtient la meilleure note de qualité, 75/100, et la meilleure note sur le coût, 92/100. Ces premiers résultats indiquent un travail jugé plus approfondi selon notre grille d’évaluation, pour le coût API le plus faible parmi les configurations testées.
La note de vitesse atteint 72/100. Uly ne réalise donc pas les audits les plus rapides en temps brut dans cette comparaison ; son intérêt réside dans le rapport entre la profondeur du travail, le temps nécessaire et le coût engagé. Le système consacre des ressources à l’exploration et à la vérification, avec l’objectif d’obtenir davantage de résultats utiles par mission.
Ces observations soutiennent l’hypothèse centrale d’Uly : l’organisation du contexte et de l’exécution peut améliorer l’efficacité d’un même modèle. Elles restent propres à ces premiers tests internes. Les notes présentées sont des scores d’évaluation, et non des pourcentages d’économie ou d’accélération.
Cette évaluation porte sur la correction de bugs et de failles de sécurité. Les quatre harnais comparés utilisent le même modèle, Gemini 4 Argon.
Uly obtient une note globale de 80/100, devant les trois autres harnais évalués : 68 pour Codex, 64 pour Claude Code et 63 pour OpenCode. Dans cette comparaison, Uly arrive en tête sur chacun des six critères affichés.
Les écarts les plus marqués concernent la fiabilité et l’autocorrection (82 contre 62 pour les deux suivants) et les tâches agentiques longues (76 contre 62). La qualité du travail atteint 78 contre 69 pour le meilleur autre score ; la profondeur, 76 contre 68.
Uly reçoit 85 en vitesse et 86 en efficience de coût, contre respectivement 68 et 78 pour les meilleurs autres scores. Ce sont des notes de ce benchmark interne, pas des mesures brutes de durée ou de dépenses. Le visuel ne précise ni le protocole ni la taille de l’échantillon : les résultats décrivent donc cette évaluation, sans établir une performance universelle.
La capacité d’un système agentique dépend autant de son organisation que des modèles qu’il emploie. Comprendre une demande, retrouver les informations pertinentes, coordonner les interventions et vérifier les résultats nécessitent un environnement capable d’accompagner le travail dans la durée.
Uly organise cet environnement à travers un harnais d’exécution. Il prépare le contexte, contrôle l’accès aux outils, conserve l’historique des actions et structure la vérification. Son objectif est de consacrer davantage de ressources aux décisions utiles, tout en réduisant les explorations répétitives, les échanges superflus et les contrôles redondants.
Cette architecture se décline en deux espaces complémentaires : Uly Code, spécialisé dans le développement et la maintenance des systèmes logiciels, et Uly Work, destiné aux projets professionnels de tous domaines.
Consacrer davantage de ressources aux décisions utiles, et réduire les explorations répétitives, les échanges superflus et les contrôles redondants.
Uly Code propose deux modes d’exécution : une équipe de spécialistes coordonnée par un orchestrateur, et Build, un agent individuel qui conduit une mission dans une même session.
Des spécialistes préparés à l’initialisation, chacun avec son périmètre, ses skills, ses outils et son modèle.
Un orchestrateur comprend la demande, la transforme en tâches structurées et ajuste le plan aux découvertes de l’équipe.
Le principe :Répartir les responsabilités entre des agents spécialisés, sous la coordination d’un orchestrateur.
Un agent individuel qui explore le projet, réalise les modifications, interprète les contrôles et corrige son travail dans une même session.
Il convient aux missions qui bénéficient d’une exécution unifiée, sans délégation à une équipe.
Le principe :Une continuité d’exécution, de l’exploration à la correction.
Uly Code structure le travail autour d’une connaissance du projet, de responsabilités explicites et de critères vérifiables.
L’initialisation permet de préparer une équipe d’agents à partir d’un dépôt existant ou de la description d’un produit à créer. Dans un projet existant, Uly explore l’architecture, les conventions, les dépendances et les moyens de contrôle. Pour un projet qui démarre de zéro, il s’appuie sur les objectifs du produit, les fonctionnalités attendues et les contraintes techniques pour définir les responsabilités nécessaires.
Cette préparation produit une équipe adaptée au projet, que l’orchestrateur pourra mobiliser au fil des développements. Une application peut ainsi nécessiter des spécialistes de l’interface, des services backend, des données ou de l’infrastructure. La composition de l’équipe suit les besoins identifiés.
Chaque spécialiste possède son propre profil de travail, qui définit :
Ces profils combinent des connaissances partagées par l’équipe et des ressources propres à chaque spécialiste. Lorsqu’une tâche lui est confiée, l’agent travaille dans sa session avec le contrat de la mission et le contexte pertinent. Les outils et connecteurs disponibles sont attribués explicitement ; une description de produit ne crée pas, à elle seule, les accès à des services externes.
L’initialisation prépare également le profil de Build à partir des mêmes connaissances. Les ressources sont regroupées dans une révision candidate, validée avant activation. Pour un produit neuf, les choix de conception restent distingués des faits observés et peuvent être précisés à mesure que le projet se construit.
Le contexte demeure progressif : chaque agent reçoit les instructions essentielles et un catalogue compact des ressources accessibles, puis charge les skills et les documents utiles. L’orchestrateur dispose ainsi d’une équipe préparée pour le projet, sans imposer à chaque spécialiste l’ensemble des connaissances et des outils de tous les autres.
L’orchestrateur construit une compréhension globale avant de distribuer le travail. Il peut lire les instructions contenues dans un fichier, explorer les composants concernés et examiner leurs dépendances. Son accès au dépôt reste en lecture seule ; les modifications sont confiées aux exécutants.
Il transforme la demande en tâches structurées, chacune associée à un objectif, un périmètre, des dépendances et des critères d’acceptation. Le harnais utilise ces contrats pour organiser l’exécution et contrôler les interventions.
Une évolution touchant une API et une interface exige, par exemple, un accord sur les données échangées. L’orchestrateur précise ce contrat commun et organise les tâches autour de cette dépendance. Les interventions indépendantes peuvent avancer simultanément ; les écritures susceptibles de se recouvrir sont coordonnées ou sérialisées.
Chaque tâche confiée par l’orchestrateur précise :
Les interventions indépendantes avancent en parallèle ; les écritures susceptibles de se recouvrir sont coordonnées.
La distribution des modèles suit cette séparation des responsabilités. Un modèle puissant peut prendre en charge l’analyse transversale et les arbitrages, tandis que des modèles plus économiques réalisent des interventions ciblées. L’efficacité dépend ainsi de l’adéquation entre la difficulté de la tâche, la qualité du contexte et le modèle affecté.
Le canal de communication partagé permet de maintenir cette coordination pendant l’exécution. Les spécialistes signalent leurs découvertes, les dépendances rencontrées ou les difficultés dépassant leur mission. L’orchestrateur peut examiner les fichiers concernés, apporter une clarification ou demander une correction.
Il peut également coordonner une extension de périmètre portant sur des fichiers précis, avec une justification et un contrôle des permissions. Le plan s’adapte ainsi aux découvertes sans imposer à l’utilisateur de transmettre lui-même chaque information entre agents.
Build prend en charge les missions qui bénéficient d’une exécution unifiée. Le même agent explore le projet, réalise les modifications, interprète les contrôles et corrige son travail, sans déléguer à une équipe.
Il utilise les connaissances du projet et charge progressivement les compétences nécessaires. La conversation conserve la continuité entre plusieurs demandes, tandis que chaque exécution possède son propre suivi : objectif, modèle, plan, actions, résultats, vérifications et consommation.
Le moteur relit l’historique persisté entre les tours. Les références vers les résultats restent accessibles, avec des mécanismes de compaction pour les échanges longs. Une clé d’idempotence à l’admission évite les doubles lancements liés à une répétition technique.
Le principe :Une exécution unifiée, de l’exploration à la correction.
Build dispose également d’appels programmés aux outils. Le modèle peut écrire un programme qui regroupe des recherches, enchaîne des lectures ou agrège des résultats, sans solliciter une nouvelle décision après chaque opération mécanique.
Ce programme s’exécute dans QuickJS compilé en WebAssembly, au sein d’un processus auxiliaire. Les accès au système passent par une API contrôlée : appels directs et programmés partagent les mêmes permissions, budgets, journaux et mécanismes d’annulation.
La concurrence est bornée et les résultats volumineux sont conservés séparément, avec consultation paginée. Les erreurs sont enregistrées par le harnais, indépendamment du résumé produit par le programme. Les opérations longues signalent leur achèvement par des événements, ce qui évite de consommer des tours de modèle pour interroger régulièrement leur état.
Le principe :Moins de tours de modèle pour les opérations mécaniques.
La vérification relie les modifications aux critères de la mission. Uly combine des contrôles déterministes avec l’examen des comportements attendus. Dans le parcours d’équipe, une vérification par modèle peut compléter les contrôles techniques ; Build conserve l’interprétation et la correction dans sa propre session.
Une référence initiale sert à distinguer les défauts préexistants des régressions introduites. Les preuves sont associées à l’état du code, aux commandes et à l’environnement pertinent. Elles peuvent être réutilisées tant que ces conditions restent valides ; une modification qui les affecte impose un nouveau contrôle.
Le harnais s’appuie sur :
Des interventions correctes séparément peuvent produire une régression une fois réunies.
Les commandes s’exécutent dans des copies isolées. La réutilisation de l’infrastructure amortit les coûts de préparation, tandis que les observations brutes permettent d’éviter des réexécutions inutiles.
Le harnais distingue également les défauts du code des indisponibilités d’outillage, afin d’adapter le parcours et de rendre visibles les limites des preuves. L’intégration examine ensuite l’état combiné des modifications : des interventions correctes séparément peuvent produire une régression une fois réunies.
La connaissance du projet, la coordination et l’exécution persistée donnent à Uly Code les fondations d’une autonomie étendue. Le point de départ d’une mission peut alors devenir un événement de l’environnement informatique : échec de pipeline, anomalie applicative, alerte de sécurité ou modification d’une dépendance.
Dans une architecture connectée, une couche de supervision peut recevoir le signal, vérifier sa provenance, le rattacher au projet et le comparer aux missions ouvertes. L’orchestrateur détermine ensuite l’intervention pertinente à partir d’un mandat : systèmes à surveiller, objectifs à maintenir, actions autorisées et limites à respecter.
Il peut regrouper des alertes liées à une même cause, éviter une correction déjà en cours et transformer un problème observé en tâches exécutables.
Une hausse d’erreurs sur une route d’API pourrait ainsi déclencher une investigation : analyse des journaux, examen des changements récents et recherche d’une reproduction. L’orchestrateur confierait le diagnostic à un spécialiste, puis coordonnerait la correction et les tests. Une politique d’exploitation pourrait autoriser la livraison automatique des changements satisfaisant les conditions prévues.
Une alerte sur une dépendance pourrait conduire à identifier ses usages, préparer sa mise à jour et adapter les composants incompatibles. Un échec de pipeline pourrait être qualifié pour distinguer une régression, un test instable ou une panne d’environnement, puis orienter l’intervention vers la cause observée.
Cette autonomie peut couvrir plusieurs sessions successives. Un événement ouvre une investigation ; un résultat débloque une correction ; une observation ultérieure confirme son effet ou déclenche une reprise. La continuité repose sur l’état persisté, les relations entre missions et les preuves enregistrées.
L’orchestrateur pourrait ainsi déterminer lui-même les prochaines tâches nécessaires à l’objectif confié. L’utilisateur définit la responsabilité du système et ses règles d’intervention, sans devoir reformuler chaque étape. Certaines catégories de maintenance pourraient être conduites de bout en bout dans les limites des autorisations, des budgets et des critères de réussite établis.
Uly Work applique les principes du harnais aux activités professionnelles au sens large. Il est conçu pour travailler sur tout type de projet, dans tout domaine : recherche, analyse, préparation de documents, suivi commercial, organisation de dossiers, communication, gestion ou opérations.
Son point de départ est un objectif accompagné de ressources : fichiers, pages web, données ou brief. Le résultat peut prendre la forme d’un document, d’un tableau, d’une présentation, d’un rapport ou d’une série d’actions dans un navigateur.
Work réutilise les mécanismes de session persistée, de budgets, de permissions, d’exécution programmée et de consultation des résultats. Ses procédures portent sur les documents, les tableaux, les présentations, la recherche, la navigation et l’organisation des dossiers.
Les compétences sont chargées progressivement. Une mission documentaire mobilise les procédures de lecture et de production nécessaires ; une analyse de données utilise les outils adaptés aux fichiers et aux contrôles demandés. Le contexte se construit autour des besoins du projet.
À partir d’un brief et de plusieurs sources, Work peut ainsi rassembler les informations, identifier les points à examiner, préparer les livrables et enregistrer les contrôles effectués. L’exécution programmée regroupe les opérations répétitives, comme parcourir des fichiers ou agréger des résultats.
Des procédures dédiées à :
Les compétences sont chargées progressivement, au fil des besoins du projet.
La vérification dépend de la nature du résultat :
Les sources sont reliées aux résultats réellement consultés. Les livrables sont enregistrés avec une empreinte permettant de détecter une modification après contrôle. L’utilisateur peut retrouver les éléments utilisés, les fichiers produits et les limites des vérifications.
La provenance, la validité technique et la qualité du contenu restent des dimensions distinctes. Un document correctement généré demande une appréciation adaptée à son usage ; une recherche exige d’examiner la pertinence et la solidité de ses sources.
Rapprocher des données de prospection et préparer des supports de réunion.
Organiser des pièces, examiner des écarts et produire un rapport.
Consolider plusieurs documents et préparer une présentation des décisions attendues.
Le cadre commun consiste à comprendre l’objectif, sélectionner les ressources, effectuer les opérations nécessaires et produire des livrables accompagnés de leurs références et de leurs contrôles. La spécialisation vient des procédures et des critères du métier.
Cette architecture cherche à réduire le travail évitable : charger les informations au moment utile, regrouper les opérations mécaniques et conserver les résultats exploitables. Son efficacité se mesure sur le travail livré, en tenant compte de sa qualité, de sa profondeur, du temps, du coût et des interventions humaines nécessaires.
Un harnais commun, des procédures et des critères propres à chaque métier.
Documents publics en lien avec les concepts décrits dans cet article : orchestration d’agents, contexte, skills, outils et exécution isolée.
Retrouvez la présentation d’Uly Code et d’Uly Work sur la page d’accueil.
Découvrir UlyOur first internal benchmark covers code audits focused on finding bugs and security vulnerabilities. The compared configurations use the same model, Gemini 4 Argon, to limit the effect of model choice on the results.
Within this scope, Uly Code achieves the highest quality score, 75/100, and the highest cost score, 92/100. These early results indicate work judged more thorough under our evaluation rubric, at the lowest API cost among the tested configurations.
The speed score is 72/100. Uly therefore does not complete the audits fastest in raw time in this comparison; its value lies in the balance between depth of work, time required and cost incurred. The system spends resources on exploration and verification with the aim of producing more useful results per mission.
These observations support Uly’s central hypothesis: organising context and execution can improve the effectiveness of the same model. They are limited to these early internal tests. The reported marks are evaluation scores, not percentages of savings or acceleration.
This evaluation covers bug fixes and security vulnerability remediation. All four harnesses use the same model, Gemini 4 Argon.
Uly scores 80/100 overall, ahead of the three other harnesses evaluated: 68 for Codex, 64 for Claude Code and 63 for OpenCode. In this comparison, Uly leads on all six criteria shown.
The largest gaps are in reliability and self-correction (82 versus 62 for the next two) and long-horizon agentic tasks (76 versus 62). Work quality scores 78 versus the next best score of 69; depth scores 76 versus 68.
Uly scores 85 for speed and 86 for cost efficiency, compared with the next best scores of 68 and 78 respectively. These are scores from this internal benchmark, not raw measurements of time or expenditure. The graphic does not specify the protocol or sample size, so the results describe this evaluation rather than establishing performance across all projects.
The capabilities of an agent system depend as much on its organisation as on the models it uses. Understanding a request, finding relevant information, coordinating contributions and checking results require an environment that can support work over time.
Uly organises this environment through an execution harness. It prepares context, controls access to tools, preserves the history of actions and structures verification. Its aim is to devote more resources to useful decisions while reducing repeated exploration, unnecessary exchanges and redundant checks.
This architecture takes two complementary forms: Uly Code, dedicated to developing and maintaining software systems, and Uly Work, designed for professional projects in any field.
Devote more resources to useful decisions, and reduce repeated exploration, unnecessary exchanges and redundant checks.
Uly Code offers two execution modes: a team of specialists coordinated by an orchestrator, and Build, an individual agent that carries out a mission in a single session.
Specialists prepared at initialisation, each with their own scope, skills, tools and model.
An orchestrator understands the request, turns it into structured tasks and adapts the plan to what the team discovers.
The principle:Distribute responsibilities among specialised agents, coordinated by an orchestrator.
An individual agent that explores the project, makes changes, interprets checks and corrects its work within a single session.
It suits missions that benefit from unified execution, without delegating to a team.
The principle:Continuous execution, from exploration to correction.
Uly Code structures work around knowledge of the project, explicit responsibilities and verifiable criteria.
Initialisation prepares a team of agents from an existing repository or a description of a product to be created. For an existing project, Uly explores its architecture, conventions, dependencies and ways to check the work. For a new project, it uses the product goals, expected features and technical constraints to define the necessary responsibilities.
This preparation produces a team suited to the project, which the orchestrator can call on as development progresses. An application might need specialists in interfaces, backend services, data or infrastructure. The team’s composition follows the needs identified.
Each specialist has their own working profile, defining:
These profiles combine knowledge shared by the team with resources specific to each specialist. When given a task, an agent works in its own session with the mission contract and relevant context. Tools and connectors are granted explicitly; a product description alone does not create access to external services.
Initialisation also prepares Build’s profile from the same knowledge. Resources are grouped into a candidate revision, validated before activation. For a new product, design choices remain separate from observed facts and can be refined as the project takes shape.
Context remains progressive: each agent receives essential instructions and a compact catalogue of available resources, then loads the useful skills and documents. The orchestrator therefore has a team prepared for the project without giving every specialist all the knowledge and tools of every other one.
The orchestrator builds an overall understanding before distributing work. It can read instructions in a file, explore relevant components and examine their dependencies. Its repository access remains read-only; changes are entrusted to the executors.
It turns the request into structured tasks, each with a goal, scope, dependencies and acceptance criteria. The harness uses these contracts to organise execution and control interventions.
An evolution affecting an API and an interface, for example, requires agreement on the data exchanged. The orchestrator defines this shared contract and organises tasks around the dependency. Independent work can proceed in parallel; writes that could overlap are coordinated or serialised.
Each task assigned by the orchestrator specifies:
Independent work proceeds in parallel; writes that could overlap are coordinated.
Model assignment follows this division of responsibilities. A more capable model can handle cross-project analysis and decisions, while more economical models perform targeted work. Efficiency depends on matching task difficulty, context quality and the model assigned.
The shared communication channel maintains this coordination during execution. Specialists report discoveries, dependencies or difficulties beyond their assignment. The orchestrator can inspect the files involved, clarify the task or request a correction.
It can also coordinate a justified extension of scope to specific files, subject to permission checks. The plan thus adapts to discoveries without asking the user to relay every piece of information between agents.
Build handles missions that benefit from unified execution. The same agent explores the project, makes changes, interprets checks and corrects its work, without delegating to a team.
It uses project knowledge and progressively loads the skills it needs. The conversation retains continuity across requests, while each execution has its own record: goal, model, plan, actions, results, checks and usage.
The engine rereads the persisted history between turns. References to results remain available, with compaction mechanisms for long exchanges. An idempotency key at admission prevents duplicate launches caused by a repeated technical request.
The principle:Unified execution, from exploration to correction.
Build can also make programmatic tool calls. The model can write a program that combines searches, chains reads or aggregates results without requesting another decision after every mechanical operation.
The program runs in QuickJS compiled to WebAssembly inside a helper process. System access passes through a controlled API: direct and programmatic calls share the same permissions, budgets, logs and cancellation mechanisms.
Concurrency is bounded, and large results are stored separately for paginated access. The harness records errors independently of the summary produced by the program. Long-running operations signal completion through events, avoiding model turns spent repeatedly polling their status.
The principle:Fewer model turns spent on mechanical operations.
Verification connects changes to the mission criteria. Uly combines deterministic checks with an examination of expected behaviour. In the team workflow, a model-based review can complement technical checks; Build keeps interpretation and correction within its own session.
An initial baseline distinguishes existing defects from regressions introduced by the work. Evidence is associated with the state of the code, commands and relevant environment. It can be reused while these conditions remain valid; a change that affects them requires another check.
The harness relies on:
Interventions that are individually sound can still create a regression when merged.
Commands run in isolated copies. Reusing the infrastructure spreads the setup cost, while raw observations help avoid unnecessary reruns.
The harness also distinguishes code defects from unavailable tooling so the workflow can adapt and the limits of the evidence remain visible. Integration then examines the combined state of changes: interventions that are individually sound can still create a regression when merged.
Project knowledge, coordination and persisted execution provide the foundations for broader autonomy in Uly Code. A mission could then start with an event in the computing environment: a failed pipeline, an application anomaly, a security alert or a changed dependency.
In a connected architecture, a supervision layer could receive the signal, check its origin, associate it with the project and compare it with open missions. The orchestrator would then determine the appropriate intervention under a mandate: systems to monitor, objectives to maintain, permitted actions and limits to respect.
It could group alerts with a common cause, avoid duplicating a correction already underway and turn an observed problem into executable tasks.
A rise in errors on an API route, for example, could trigger an investigation: analysing logs, reviewing recent changes and finding a reproduction. The orchestrator would assign the diagnosis to a specialist, then coordinate the fix and tests. An operating policy could permit automatic delivery of changes that satisfy the defined conditions.
A dependency alert could lead to identifying its uses, preparing an update and adapting incompatible components. A pipeline failure could be classified as a regression, an unstable test or an environment outage, then routed to an intervention addressing the observed cause.
This autonomy can span multiple successive sessions. One event opens an investigation; a result unblocks a correction; a later observation confirms its effect or prompts another attempt. Continuity rests on persisted state, relationships between missions and recorded evidence.
The orchestrator could thus determine the next tasks needed to achieve the assigned objective. The user defines the system’s responsibility and rules of intervention without restating every step. Certain kinds of maintenance could be carried through end to end within established permissions, budgets and success criteria.
Uly Work applies the harness principles to professional activity broadly. It is designed for any kind of project, in any field: research, analysis, document preparation, sales follow-up, file organisation, communications, management or operations.
It starts with a goal and resources: files, web pages, data or a brief. The result may be a document, spreadsheet, presentation, report or series of browser actions.
Work reuses persistent sessions, budgets, permissions, programmatic execution and result browsing. Its procedures cover documents, spreadsheets, presentations, research, navigation and file organisation.
Skills are loaded progressively. A document task draws on the reading and production procedures it needs; data analysis uses tools suited to the files and checks requested. Context is built around the project’s needs.
Given a brief and several sources, Work can gather information, identify points to examine, prepare deliverables and record the checks performed. Programmatic execution groups repetitive operations, such as reading files or aggregating results.
Dedicated procedures for:
Skills are loaded progressively, as the project requires.
Verification depends on the kind of result:
Sources are linked to the results actually consulted. Deliverables are recorded with a fingerprint to detect changes after verification. The user can find the material used, files produced and limits of the checks.
Provenance, technical validity and content quality remain separate dimensions. A correctly generated document still needs assessment suited to its purpose; research requires examining the relevance and strength of its sources.
Reconcile prospecting data and prepare meeting materials.
Organise records, examine discrepancies and produce a report.
Consolidate documents and prepare a presentation of decisions to be made.
The common framework is to understand the goal, select resources, perform the necessary operations and produce deliverables with references and checks. Specialisation comes from the procedures and criteria of each profession.
This architecture seeks to reduce avoidable work: load information when useful, group mechanical operations and preserve usable results. Its effectiveness is measured by the work delivered, considering quality, depth, time, cost and the human intervention required.
One shared harness, with procedures and criteria specific to each profession.
Public documents related to the concepts described in this article: agent orchestration, context, skills, tools and sandboxed execution.