Pas comme métaphore. Un projet Kortix est un dépôt git, et ce dépôt est l’entreprise : ses agents, les compétences qu’elle a développées, tout ce qu’elle a appris et la définition des machines sur lesquelles tout s’exécute. Versionné. Comparables par diff. Entièrement détenu.
skill: reconcile-invoices — gérer les remboursements partiels
skills/reconcile-invoices/SKILL.md
9f4c2b7e → main · ouverte par invoice-clerk
kortix.yaml est la couche Kortix : la machine sur laquelle les sessions démarrent, les connecteurs, les déclencheurs, les noms des secrets et ce que chaque agent est autorisé à utiliser. La configuration OpenCode est l’environnement d’exécution dans lequel les agents réfléchissent. Tout le reste est constitué des fichiers du dépôt.
# Version 2 du schéma. L’environnement d’exécution est OpenCode.kortix_version: 2runtime: opencode project: name: Northwind # L’agent qui répond lorsqu’aucun n’est indiqué.default_agent: kortix # Emplacement de la configuration d’exécution. Ensuite : les fichiers.opencode: config_dir: harnesses/opencode # Uniquement les NOMS des secrets. Les valeurs sont chiffrées sur la# plateforme et injectées au démarrage de la machine.env: required: [STRIPE_API_KEY] optional: [LINEAR_API_KEY] # La machine sur laquelle une session démarre.sandbox: default: python templates:- identifiant: python image: python:3.12-slim cpu: 2 memory: 4 # Accès au monde extérieur. La définition se trouve dans# git. Les identifiants, eux, n’y sont jamais.connectors:- identifiant: gmail-read provider: pipedream app: gmail authorization_strategy: user # Gouvernance : ce que chaque agent peut utiliser — jamais ce# qu’il dit. Une autorisation omise équivaut à aucune autorisation.agents: kortix: connectors: all secrets: all skills: all kortix_permissions: all invoice-clerk: sandbox: python connectors: [gmail-read] secrets: [STRIPE_API_KEY] skills: [reconcile-invoices] kortix_permissions: [project.cr.open]La couche Kortix — un fichier à la racine du dépôt.
{ // Documentation : https://opencode.ai/docs/ "$schema": "https://opencode.ai/config.json", "theme": "system", "default_agent": "kortix", // La session s’exécute déjà sur une machine isolée // branche temporaire, pour que l’agent démarre sans restriction. // Renforcez ici la règle par outil lorsque vous voulez une politique plus stricte // policy. "permission": "allow"}L’environnement d’exécution — modèles, outils, autorisations.
---description: Rapproche les factures et les paiements.mode: primarypermission: bash: ask--- Vous êtes le gestionnaire des factures de Northwind. Associez chaque paiement à une facture par son numéro, jamaispar son montant. Si vous ne pouvez pas le faire, ouvrez une demande de modificationet indiquez exactement ce que vous n’avez pas pu rapprocher.L’agent — un fichier d’agent OpenCode standard. Son contenu se trouve ici.
Quelle machine, quels connecteurs, quels secrets, quelles compétences, quels verbes CLI. Gouvernance uniquement. Omettez une autorisation et elle devient nulle — un agent obtient ce que vous lui avez donné, et rien de plus.
Des invites, des modèles, des outils, des plugins et des permissions. Un agent est un agent OpenCode standard — du markdown à la base, puis les outils, plugins et la configuration du modèle présents à ses côtés dans le même dépôt. Lisez le répertoire et vous saurez exactement ce que fera cet agent.
Le manifeste nomme les secrets et les accorde à chaque agent. Les valeurs sont chiffrées sur la plateforme, injectées dans la machine à l’exécution et ne sont jamais écrites dans le dépôt ni dans les journaux.
Les agents, les compétences et la mémoire ne sont pas des lignes dans une base de données invisible. Ce sont des fichiers markdown à côté de votre code, clonés dans chaque session, lisibles par une personne et modifiables par un agent.
Il n’y a aucune couche cachée à interroger. Chaque conviction, chaque permission et chaque instruction tient sur une ligne d’un fichier, et les outils que vous utilisez déjà répondent à la question.
# que pense l’entreprise de la tarification ?$ grep -ri "annual" memoryMEMORY.md: ne jamais proposer l’annuel avant la revue de sécurité # qui est autorisé à utiliser la clé Stripe ?$ grep -n "STRIPE_API_KEY" kortix.yaml18: requis: [STRIPE_API_KEY]48: secrets: [STRIPE_API_KEY] # qui a modifié le gestionnaire des factures, et quand ?$ git log --oneline agents/8f2a1c4 invoice-clerk: ne plus deviner les remboursements1d90b73 invoice-clerk: première version de la personaChaque invite d’agent, chaque compétence, chaque fait mémorisé et chaque autorisation est du texte dans un seul dépôt. Pas de console à parcourir, pas d’export à demander.
Chaque modification apportée à un agent, une compétence ou un fichier mémoire est un commit avec un auteur, un horodatage et un diff. Rien ne disparaît et rien ne se passe dans l’ombre.
Une mauvaise instruction a été ajoutée mardi ? Lisez le diff, annulez le commit, ouvrez une demande de modification. L’entreprise revient à son état précédent.
Lorsqu’un agent trouve une meilleure façon d’effectuer une tâche, il ne la mémorise pas discrètement. Il modifie la compétence, la valide sur sa propre branche et ouvre une demande de modification. Une personne lit le diff et décide.
## Associer un paiement à une facture 1. Récupérez la facture par son numéro, jamais par son montant.2. Si les montants diffèrent, signalez-le à une personne.2. Si l’écart correspond à un remboursement déjà enregistré, clôturez-le comme remboursement partiel et notez l’identifiant du remboursement sur la facture.3. S’ils diffèrent pour toute autre raison, signalez-le à une personne et indiquez ce que vous avez vérifié. Ne procédez jamais vous-même à un remboursement.Lorsqu’un agent réécrit ses propres instructions, cela arrive comme une migration de base de données : une branche, un commit, un diff, une personne qui vérifie. L’entreprise n’a qu’un seul processus de revue, pas deux.
La machine peut proposer. Une personne décide. Le travail n’atteint main que par une demande de modification approuvée, afin que l’entreprise ne dérive pas quand vous ne la surveillez pas.
Un agent peut lire sa propre configuration, la modifier et proposer le changement. Programmez cela et le dépôt deviendra meilleur pour représenter votre entreprise pendant que tout le monde dort.
agents: memory-reflector: # il peut ouvrir une demande de modification. Rien d’autre. kortix_permissions: [project.cr.open] triggers:- identifiant: memory-reflectornom: Réflecteur de mémoire type: cron agent: memory-reflector enabled: falsecron: "0 0 3 * * *" timezone: UTC prompt: | Réfléchis aux dernières 24 heures d’activité du projet. Examine l’historique git, les demandes de modification fusionnées et les résumés de session. Mets à jour memory/ et ouvre une demande de modification intitulée `memory: ...`. Termine sans en ouvrir si aucune connaissance durable n’a été acquise.Issu du modèle de démarrage. Chaque nouveau projet l’intègre, désactivé.
Passez enabled à true : il s’exécutera à 03:00 UTC, sans personne pour le surveiller. Les déclencheurs sont des planifications cron et des webhooks signés, déclarés dans le même fichier que tout le reste.
Il reçoit son propre ordinateur cloud et sa propre branche, avec exactement l’autorisation que le manifeste lui a accordée : ouvrir une demande de modification.
Il lit l’historique git et les sessions de la journée écoulée, puis écrit ce qu’il a appris dans memory/ sous forme de markdown.
Une demande de modification vous attend le matin. Fusionnez-la et l’entreprise apprend quelque chose de nouveau. Fermez-la et rien ne s’est passé.
Pas de procédure d’export, pas de ticket au support, pas de format propriétaire à décoder. L’entreprise est déjà du texte sur une branche : elle se clone, se duplique, s’annule et part avec vous.
# transformer n’importe quel répertoire en Kortix$ kortix init # vérifier la compilation, demander les secrets manquants,# le mettre en ligne et rendre l’ensemble opérationnel$ kortix ship # à partir d’ici, ce n’est qu’un dépôt$ git clone git@github.com:northwind/northwind.git$ git revert 8f2a1c4$ kortix crCommencez par une tâche et développez à partir de là.