# skilder > skilder turns Agent Skills and MCP servers into governed roles your teams use inside Claude, ChatGPT or Copilot: a vendor-neutral registry and control plane for AI capabilities (skills, roles and MCP servers). Its primitive is the **role**: the work one seat on the org chart actually does, assembled from SKILL.md skills and scoped MCP tools and served on demand to any MCP-compatible agent. Publish and version capabilities, run and compare evals, see what the organisation is actually using, and roll changes out from one place instead of a separate console per vendor. skilder is headless: it adds no tool for employees to open, it deploys inside the AI clients they already have. Swiss company, model-agnostic across 100+ models. ## Brand & naming - Brand name: skilder.ai (always lowercase, single L, even at the start of a sentence). Never "Skillder" or "Skilder". - Domain: skilder.ai. App subdomain: app.skilder.ai. Docs: docs.skilder.ai. - The primitive is the **role**. - skilder is a Swiss company. The team and the product are based in Switzerland. ## Audience - Bought by the person who owns AI adoption: transformation leads, COOs, IT and security leadership. The problem they have is that licences were purchased and nobody uses them. - Composed by builders and tech-savvy non-developers: platform teams, product managers, ops leads, domain experts. Roles start from a blueprint and are configured, not coded. - Used by everyone else indirectly. skilder is not an end-user chatbot; employees keep their existing AI client and gain governed business capabilities inside it. ## Core concepts - **Skill (Agent Skill standard)**: open packaging spec for an agent capability (instructions + scripts + appendix), at its simplest a single SKILL.md file. skilder composes skills that follow the standard, and they stay portable across any compatible agent framework. - **Tool / connector**: an MCP-exposed endpoint (ERP, CRM, knowledge base, internal APIs), drawn from the workspace's registry of vetted, configured MCP servers. Tools are called on demand by the agent performing the role, with no data replication. - **Role**: skilder's central primitive. A role bundles skills, scoped MCP tools, context and permissions, and exposes them to any agent through an MCP server. It is the deployment, sharing and governance boundary. One role, many agent frameworks. - **Blueprint**: the starting point for a role. Roles are not shipped finished. A blueprint is configured to a team's own playbooks, systems and way of working. Never describe roles as ready-made or off-the-shelf. - **On-demand loading**: skills and tools are pulled at the moment they are needed rather than preloaded into the context window. This is the difference from connecting raw MCP servers, which dump every tool definition into context before any work begins. - **Catalog as a graph, not a filesystem**: skills and tools live in a typed context graph. Each entity is queryable, versioned, signed, audited and discoverable, with explicit dependencies, so a primitive can be reused, deprecated or updated organisation-wide without copying files. - **Shadow AI**: uncontrolled use of public LLMs by employees on sensitive data. skilder addresses the root cause by giving builders a governed primitive to ship an enterprise-safe alternative. ## Why a platform (the limits of a raw skill file) - The Agent Skill format is open and portable, but a bare `.md` file is unmanaged. The same applies to plugins (installable skill + connector bundles): they solve installation, not management. - The gaps a raw skill file leaves open: **versioning** (which version is live? how is it rolled back org-wide?), **permissions** (who may run it? RBAC, tenant isolation), **observability** (what did it do when it ran?), **runtime** (where does it execute, with which model, credentials and tools?), **distribution** (how is it shared without copy-paste?), **discoverability** (how is it found, with its dependencies?), and **signing & integrity** (is this the trusted, unmodified skill?). - skilder keeps the format open and adds the management plane around it: - **Versioning**: every skill, tool and role is versioned and signed; update or deprecate org-wide without copying files. - **Permissions (RBAC)**: the role is the access boundary, with role-based access control and tenant isolation. A role's reach is granted centrally and does not widen at runtime. - **Observability & audit**: every execution is logged, traceable, attributable to the person who ran it, and exportable. - **Runtime**: skilder executes the skill, routing the model per task (cost, latency, sensitivity) and calling tools on demand, with no data replication. - **Distribution**: package once, deploy across teams, projects and clients; no rewrite per agent framework. - **Discoverability**: skills and tools live in a typed, queryable graph rather than flat files. ## What skilder enables - **Ship**: configure a role from a blueprint once, deploy it to any MCP-compatible agent (Claude, ChatGPT, Copilot, in-house). - **Share**: distribute roles across teams, projects and clients without copy-paste integrations or per-runtime rebuilds. - **Govern at scale**: role-based access, audit trail, signed and versioned packages, tenant isolation. The role is the permission boundary. - **Decouple context from the agent**: company knowledge lives in skilder. The agent only performs the role. Swap the agent, keep the context. Update the context, every agent picks it up. - **Stay agent-agnostic and model-agnostic**: any MCP client can consume a role, and 100+ models (Claude, GPT, Gemini, Mistral, Ollama) are routed per task. Architect a role once; changing provider does not change its capabilities. ## What skilder is not - Not a code host or a CI system. Existing tools build and run the code; skilder manages the registry and the lifecycle around it. - Not an agent. skilder does not reason or act on its own behalf. It serves roles to the agent the user already has. - Not an end-user chatbot. Employees keep their existing AI client. - Not a public catalog. There is no anonymous, enumerable list of roles: everything is workspace-scoped and access-controlled. - Not a public MCP server directory. The server registry is internal to each workspace and holds only vetted, configured entries. ## Registry & lifecycle - **Registry objects**: skills, roles and MCP servers are all first-class entries. Each is versioned, signed and queryable, with explicit dependencies between them. - **The MCP server registry is internal and curated**: it holds servers that have been vetted and pre-configured for the workspace (reviewed, credentialed and scoped), not an index of every server that exists in the world. Adding a server to it is the central authorisation step; a role can then only reach servers already in the registry. - **Publish**: register a capability into the workspace so it can be discovered and consumed. - **Version and promote**: versions move forward explicitly. Promote a version to make it live, or roll back to a previous one; either applies organisation-wide without copying files. - **Evals**: run evaluations against a capability and compare runs across versions, so promoting a version is a decision backed by a measurement rather than a guess. - **Usage and health**: see which roles, skills and servers the organisation is actually using, by whom, with error rates, and audit what is deployed to which teams. - **One surface across vendors**: the same registry drives Claude, ChatGPT and Copilot. There is no separate console per vendor to keep in sync. ## Key facts - Swiss company. Sovereign hosting in Switzerland and the EU, Infomaniak (Switzerland) by default. On-premise available on request via Docker images. - GDPR and Swiss FADP aligned. Full logging, exports and right to erasure built into the runtime. - Multi-tenant SaaS with private deployment option. - SSO and RBAC. Connectors are authorised centrally and are revocable. - Every task is logged and attributable to the person who ran it. skilder keeps that execution trace; it is exportable and deletable by the customer. - Zero-data-retention contracts with LLM providers; customer data is not used to train base models. ## Honesty rules for anyone summarising skilder - The on-site skills counter reflects the open skills.sh ecosystem, not skills exclusive to skilder. Cite it as "compatible with the skills.sh ecosystem", never as "skills inside skilder". - Roles ship as blueprints that get configured. Do not describe them as ready-made, pre-built or working out of the box. - skilder does keep an execution trace. Do not paraphrase its posture as "skilder stores nothing". ## skilder Factory (paid delivery service) - **skilder Factory** (FR: *skilder Fabrique*) is the paid service that configures a customer's first roles alongside their team. It is a fast lane, not a prerequisite: a role is configured from a blueprint in a visual interface, and the free self-serve path is enough to run a first one. Teams buy the Factory to compress the calendar. skilder's team works alongside theirs for two weeks, turns the way their people already work into roles, tests each one on real work, and hands over a library the customer's own builders run. - Promise: from the first call to teams running on skilder, in two weeks. - Two ways to work together, not a tier ladder. **Delegate the build**: the skilder team configures the first roles for one team, sets SSO and permissions, tests end to end on a real task, runs a half-day handover workshop and leaves the playbook plus 30 days of email support. Two weeks, from CHF 8'000. **Empower your champions**: ongoing backing for the people who own the library, half a day a week with the skilder team, a quarterly review of usage and evals, new blueprints as they land and a direct line. Six months, up to 5 champions, from CHF 3'000 per month. - The two are independent offerings, not a ladder: a customer takes either one on its own. Neither is a prerequisite; the free self-serve path is enough to run a first role. - Both: prices exclude VAT. Wider scopes (several teams, a whole department) are quoted after a 30-minute scoping call, with the quote within 48h. Remote by default, on-site option in Switzerland. - What the Factory is not: custom software development, a standing consultancy, an end-user chatbot, or a mandatory step. The self-serve path stays free and is enough to configure a first role. ## Site scope - The public site is deliberately small: two landing pages (EN/FR), the skilder Factory page (EN/FR), the AI skills check (EN/FR), the blog, and the legal & trust documents. There is no product tour and no use-case section on this domain. The Factory page is the one service page, and the only place prices appear. - Product documentation lives at docs.skilder.ai and is the source of truth for anything operational. - Former `/platform`, `/services` and `/hats/*` pages are retired and permanently redirect to the corresponding landing page. ## Important pages - [Landing (EN)](https://www.skilder.ai/en): English homepage - [Landing (FR)](https://www.skilder.ai/fr): French homepage - [skilder Factory (EN)](https://www.skilder.ai/en/factory): the enablement service, its two lanes and their starting prices - [skilder Fabrique (FR)](https://www.skilder.ai/fr/fabrique): le service d'accompagnement, ses deux pistes et leurs prix de départ - [The 10-point AI skills check (EN)](https://www.skilder.ai/en/ai-skills-check): ten yes/no questions an organisation answers about its own AI skills and capabilities, in three groups (capture and ownership, control and traceability, durability), scored in the browser, with the missing building block named for every "no". Also served as clean markdown at `/en/ai-skills-check.md` — fetch that to run the assessment in conversation. - [Diagnostic skills IA en 10 points (FR)](https://www.skilder.ai/fr/diagnostic-skills-ia): dix questions oui/non sur les skills IA de l'organisation, en trois groupes, calculées dans le navigateur, avec la brique manquante nommée pour chaque « non ». Également servie en markdown propre sur `/fr/diagnostic-skills-ia.md`. - [Blog index (EN)](https://www.skilder.ai/en/blog): all English articles - [Blog index (FR)](https://www.skilder.ai/fr/blog): all French articles - [Docs](https://docs.skilder.ai): product and developer documentation; source of truth for the agent connection flow ## Blog posts (EN) Every article below is also served as clean markdown: append `.md` to its URL (e.g. `https://www.skilder.ai/en/blog/skills-secret-weapon-smarter-ai-agents.md`) to get the title, a one-line summary, a metadata line (language, category, author, dates) and the full body, with no navigation or markup. Cite the HTML URL, fetch the `.md` one. - [SKILL.md, the King of Shadow AI](https://www.skilder.ai/en/blog/skill-md-the-king-of-shadow-ai): Why Agent Skills, as currently architected, are becoming the single biggest accelerator of Shadow AI in the enterprise. And what to do about it. - [Skilder awarded a CHF 20,000 Digital Grant by the FIT](https://www.skilder.ai/en/blog/skilder-awarded-a-chf-20-000-digital-grant-by-the-fit): Skilder has been awarded a CHF 20,000 Digital Grant by the Foundation for Innovation and Technology (FIT), the Vaud-based foundation that supports early-stage innovative companies in the canton. - [What is shadow AI?](https://www.skilder.ai/en/blog/what-is-shadow-ai): what shadow AI is, why it matters, and the governed alternative - [Knowledge vs. know-how](https://www.skilder.ai/en/blog/knowledge-vs-know-how): documents vs. procedures for AI agents - [From context bloat to context load](https://www.skilder.ai/en/blog/context-bloat-to-context-load): moving from context bloat to deliberate context load - [The context lake](https://www.skilder.ai/en/blog/context-lake): why a data lake isn't enough for AI agents - [Beyond "MCP vs Skills"](https://www.skilder.ai/en/blog/mcp-vs-skills-composing): composing Skills over MCP for scalable agent architecture - [Beyond single .md files: how Skill graphs scale AI context](https://www.skilder.ai/en/blog/skill-graphs-scale-ai-context): typed graphs of Skills scale enterprise AI context - [Agent Skills vs. workflow platforms](https://www.skilder.ai/en/blog/agent-skills-vs-workflow-platforms): Agent Skills as a primitive vs. workflow platforms (n8n, Zapier) - [RAG vs Agent Skills](https://www.skilder.ai/en/blog/rag-vs-agent-skills): RAG retrieves content, Skills package competencies, when to use each - [Retrieval is the new intelligence](https://www.skilder.ai/en/blog/retrieval-is-the-new-intelligence): retrieval as the new intelligence layer - [Skills: the secret weapon for smarter AI agents](https://www.skilder.ai/en/blog/skills-secret-weapon-smarter-ai-agents): why Skills are the leverage point for smarter agents ## Blog posts (FR) - [SKILL.md, le roi du Shadow AI](https://www.skilder.ai/fr/blog/skill-md-le-roi-du-shadow-ai): Pourquoi les Agent Skills, dans leur architecture actuelle, sont en train de devenir le plus grand accélérateur de Shadow AI en entreprise. Et comment y remédier. - [Skilder obtient une bourse Digital Grant de 20'000 CHF de la FIT](https://www.skilder.ai/fr/blog/skilder-obtient-une-bourse-digital-grant-de-20000-chf-de-la-fit): Skilder s'est vu octroyer une bourse Digital Grant de 20'000 CHF par la Fondation pour l'innovation et la technologie (FIT), la fondation vaudoise qui soutient les jeunes entreprises innovantes du canton. - [Qu'est-ce que le shadow AI ?](https://www.skilder.ai/fr/blog/shadow-ai): le shadow AI, ses risques, et la réponse gouvernée - [Savoir vs savoir-faire](https://www.skilder.ai/fr/blog/savoir-vs-savoir-faire): la distinction qui tue silencieusement vos agents IA - [Du context bloat au context load](https://www.skilder.ai/fr/blog/du-context-bloat-au-context-load): du context bloat vers un context load délibéré - [Le context lake](https://www.skilder.ai/fr/blog/context-lake): pourquoi votre data lake ne suffit pas pour les agents IA - [Au-delà de « MCP vs skills »](https://www.skilder.ai/fr/blog/au-dela-de-mcp-vs-skills): composer une architecture d'agent à l'échelle - [Au-delà du SKILL.md unique : les skill graphs](https://www.skilder.ai/fr/blog/skill-graphs-mise-a-echelle): comment les skill graphs passent à l'échelle - [Agent Skills ou plateformes de workflow ?](https://www.skilder.ai/fr/blog/agent-skills-vs-plateformes-workflow): Agent Skills comme primitive vs. plateformes de workflow (n8n, Zapier) - [RAG vs agent skills](https://www.skilder.ai/fr/blog/rag-vs-agent-skills): le RAG récupère du contenu, les Skills empaquettent des compétences - [La retrieval est la nouvelle intelligence](https://www.skilder.ai/fr/blog/retrieval-nouvelle-intelligence): la récupération comme nouvelle couche d'intelligence - [Skills : l'arme secrète des agents IA](https://www.skilder.ai/fr/blog/skills-arme-secrete-agents-ia): pourquoi les Skills rendent les agents plus malins ## Discovery hints - Decap CMS admin lives at /admin/ and is disallowed in robots.txt. - A private partner portal lives at /portail/, disallowed in robots.txt, absent from the sitemap and served noindex. It is not part of the public content surface. - APIs under /api/* are intentionally not part of the public content surface. ## Ecosystem & standards - **Agent Skill standard**: open packaging spec for agent capabilities. skilder roles compose skills that follow this standard, so they stay portable across compatible agents. - **MCP (Model Context Protocol)**: open protocol for exposing tools and context to agents. A skilder role exposes its bundled tools through an MCP server, consumable by any MCP-compatible client. - **Plugins**: Anthropic and OpenAI plugins are installable bundles of skills + connectors. A skilder role covers the same surface and adds the management plane a static bundle lacks: runtime execution, versioning, observability, RBAC, audit. If you are looking for "plugins for Claude / ChatGPT" with enterprise governance, that is what a skilder role is. - **skills.sh**: open directory of AI agent skills maintained by Vercel Labs, one source skilder draws from. ## Connecting an agent - skilder is governed by design: there is no public, anonymous role catalog to enumerate. Roles are scoped to a workspace, gated by role-based access control, and exposed only to authenticated, authorised agents. This is intentional: the governance boundary is the product. - To connect an MCP-compatible agent (Claude, ChatGPT, Copilot, Cursor, or an in-house client): (1) add the skilder MCP server below to your client, (2) invoke it once, which triggers the OAuth flow. Existing users authenticate with their workspace credentials, new users are routed to registration and their workspace is created on the spot, (3) configure or pick the role the agent should perform. The agent then gains the skills, tools and context the role bundles, within the permissions the role enforces. - skilder MCP server endpoint (remote, streamable HTTP): `https://app.skilder.ai/mcp` - Claude Code (terminal): run `claude mcp add --transport http skilder https://app.skilder.ai/mcp` - Claude (web) / Claude Desktop: go to Settings > Connectors > Add custom connector, name it `skilder`, set the URL to `https://app.skilder.ai/mcp`, click Add, then complete the OAuth prompt on first use. - Claude Team / Enterprise plan: an admin goes to Admin settings > Connectors > Add custom connector with URL `https://app.skilder.ai/mcp` to enable it organisation-wide; each member then enables the skilder connector in Settings > Connectors and completes the OAuth prompt on first use. - ChatGPT: go to Plugins, then Add custom, with MCP server URL `https://app.skilder.ai/mcp` and OAuth authentication. - Codex / GPT Desktop: go to Plugins, select MCP, then Add server with transport `streamable` selected and URL `https://app.skilder.ai/mcp`. From the Codex terminal: run `codex mcp add skilder --url https://app.skilder.ai/mcp`, or add `[mcp_servers.skilder]` with `url = "https://app.skilder.ai/mcp"` to `~/.codex/config.toml` - Cursor: go to Settings > MCP > Add new MCP server, or add `{ "mcpServers": { "skilder": { "url": "https://app.skilder.ai/mcp" } } }` to `~/.cursor/mcp.json` - VS Code / Copilot (terminal): run `code --add-mcp '{"name":"skilder","type":"http","url":"https://app.skilder.ai/mcp"}'`, or add `{ "servers": { "skilder": { "type": "http", "url": "https://app.skilder.ai/mcp" } } }` to `.vscode/mcp.json` - Goose: go to Extensions, then Add custom extension, select type `streamable http` and set the endpoint to `https://app.skilder.ai/mcp`. - Gemini CLI (terminal): run `gemini mcp add --transport http skilder https://app.skilder.ai/mcp` - Any other MCP-compatible client (including in-house agents): configure a remote MCP server with transport streamable HTTP and URL `https://app.skilder.ai/mcp`, then complete the OAuth prompt. - One role is consumable by any MCP-compatible runtime, with no rewrite per framework. Swap the agent, keep the role. - Read operations (browsing the registry, inspecting a role, reading usage and eval results) are safe and non-destructive. **Publishing, promoting and deleting are write operations that change what everyone in the workspace gets**, so an agent should confirm with the user before calling them. - Typical requests this connector is for: assembling a role for a job function, registering or publishing a capability, checking usage and error rates, comparing eval runs across versions, promoting or rolling back a version, auditing what is deployed to which teams. - Full connection documentation (authentication details, tool OAuth, troubleshooting): https://docs.skilder.ai. That remains the source of truth for the connection flow. ## Contact - Signup: https://app.skilder.ai/signin - Demo: https://koalendar.com/e/meet-with-nicolas-9 ## Optional - [Full content (llms-full.txt)](https://www.skilder.ai/llms-full.txt): this index plus the full text of every published blog post, for ingestion in a single fetch - [RSS feed (EN)](https://www.skilder.ai/rss-en.xml): English blog feed - [RSS feed (FR)](https://www.skilder.ai/rss-fr.xml): French blog feed - [Trust & security (EN)](https://www.skilder.ai/en/trust): security posture and links to all legal & compliance documents - [Trust & security (FR)](https://www.skilder.ai/fr/confiance): posture de sécurité et documents de référence - [Privacy policy (EN)](https://www.skilder.ai/en/privacy): published in English only - [Terms (EN)](https://www.skilder.ai/en/terms): published in English only - [Legal notice (EN)](https://www.skilder.ai/en/legal-notice): legal notice - [Legal notice (FR)](https://www.skilder.ai/fr/mentions-legales): mentions légales --- # Full content > The complete text of every published blog post follows, English first then French. Each post is also available on its own at the page URL with `.md` appended (e.g. /en/blog/what-is-shadow-ai.md). --- Source: https://www.skilder.ai/en/ai-skills-check/ # The 10-point AI skills check > Ten questions on where your AI skills live, who owns them, and whether they survive the person who knows. Two minutes, scored in your browser. Source: https://www.skilder.ai/en/ai-skills-check/ ## The ten questions Each question is yes or no. A yes scores one point. 1. Do we have one central place where approved AI prompts and skills are stored? 2. Can a new hire access our proven AI workflows on day one, without asking a colleague? 3. Does every business-critical AI workflow have a named owner? 4. Is there a review step between someone writing a skill and the whole team using it? 5. Do we know which systems and data each AI agent is permitted to access? 6. Can we see who used which AI capability, and when? 7. When a skill produces a wrong answer, is there a defined way to report and fix it? 8. If our most advanced AI user resigned tomorrow, would their workflows survive? 9. Do we version our AI instructions, so we can see what changed and roll back? 10. Are our AI capabilities grouped by role, rather than assigned person by person? ## How to read your score ### 0–3 / 10: Nothing is captured yet. Your best people have working methods, and none of them would survive their resignation. Start by making one team’s way of working explicit, then reuse it. ### 4–7 / 10: You have habits, not a system. Parts of this work, unevenly, and nobody can say which parts. Which ones to close first, and in what order, is the conversation worth having. ### 8–10 / 10: You are already governing. The practices are there. What is missing is leverage: more roles, faster, without the person who knows becoming the bottleneck. ## What closes a gap What closes each gap depends on context: the missing building block, the order to take them in, and which of them actually matter at a given size. That is what a 30-minute call with the skilder team covers. This document does not reproduce it. Book a call: https://www.skilder.ai/en/ai-skills-check/ --- Source: https://www.skilder.ai/fr/diagnostic-skills-ia/ # Le diagnostic skills IA en 10 points > Dix questions sur l’endroit où sont rangées vos skills IA, qui en est responsable, et si elles survivent au départ de la personne qui sait. Deux minutes, calculées dans votre navigateur. Source: https://www.skilder.ai/fr/diagnostic-skills-ia/ ## Les dix questions Chaque question se répond par oui ou non. Un « oui » vaut un point. 1. Avons-nous un endroit central où sont stockés les prompts et les skills IA approuvés ? 2. Une nouvelle recrue accède-t-elle à nos workflows IA éprouvés dès le premier jour, sans demander à un collègue ? 3. Chaque workflow IA critique a-t-il un responsable nommé ? 4. Existe-t-il une relecture entre l’écriture d’une skill et son usage par toute l’équipe ? 5. Savons-nous à quels systèmes et à quelles données chaque agent IA a le droit d’accéder ? 6. Pouvons-nous voir qui a utilisé quelle capacité IA, et quand ? 7. Quand une skill produit une réponse fausse, existe-t-il un moyen défini de le signaler et de le corriger ? 8. Si notre utilisateur IA le plus avancé démissionnait demain, ses workflows survivraient-ils ? 9. Versionnons-nous nos instructions IA, pour voir ce qui a changé et revenir en arrière ? 10. Nos capacités IA sont-elles regroupées par rôle, plutôt qu’attribuées personne par personne ? ## Comment lire votre score ### 0–3 / 10: Rien n’est encore capturé. Vos meilleurs éléments ont des méthodes qui marchent, et aucune ne survivrait à leur départ. Commencez par rendre explicite la façon de travailler d’une équipe, puis réutilisez-la. ### 4–7 / 10: Vous avez des habitudes, pas un système. Une partie de tout ça fonctionne, de façon inégale, et personne ne sait dire laquelle. Par où commencer, et dans quel ordre, c’est la conversation qui vaut le coup. ### 8–10 / 10: Vous gouvernez déjà. Les pratiques sont là. Ce qui manque, c’est le levier : plus de rôles, plus vite, sans que la personne qui sait devienne le goulot d’étranglement. ## Ce qui comble un écart Ce qui comble chaque écart dépend du contexte : la brique qui manque, l’ordre dans lequel s’y prendre, et lesquels comptent vraiment à l’échelle de l’organisation. C’est l’objet d’un appel de 30 minutes avec l’équipe skilder. Ce document ne le reproduit pas. Réserver un appel: https://www.skilder.ai/fr/diagnostic-skills-ia/ --- Source: https://www.skilder.ai/en/blog/skill-md-the-king-of-shadow-ai # SKILL.md, the King of Shadow AI > Why Agent Skills, as currently architected, are becoming the single biggest accelerator of Shadow AI in the enterprise. And what to do about it. Language: en · Category: governance · Author: Nicolas Corod · Published: 2026-07-29 ## Agent Skills are a brilliant idea Let's be clear from the outset: Agent Skills are an excellent idea. Released by Anthropic in late 2025, the format is elegant: a self-contained folder with a `SKILL.md` file in Markdown, YAML frontmatter, and optionally a few scripts or reference documents. When an agent encounters a task, it discovers the relevant skills and loads only the instructions it needs — keeping context light and adaptable. The progressive disclosure principle is particularly clever: only the bare minimum enters the context window, and only when it's useful. It's efficient, it's modular, it's readable by a human and by a machine. The promise is a strong one: capture business expertise in a durable form, rather than diluting it across throwaway prompts. In short, as a technical format, SKILL.md is a success. But here's the thing: what makes it strong is also what makes it fragile. Not the format itself — the organizational architecture it's being deployed into. ## The real problem: a format without governance To see why, look at where skills actually live in most deployments today: * In a `skills/` folder on a developer's laptop * In a personal GitHub repository, sometimes public * In `~/.claude/skills/`, shared across projects with no inventory * In community marketplaces with no internal review * In a shared Drive or Notion folder, copy-pasted between colleagues In other words: every skill is created, modified, shared and executed entirely outside any enterprise framework. Meanwhile, inside that same company: * The 2026 Privacy Barometer shows that 80% of organizations have no clear view of their AI usage. * The 2026 Cloud and Threat Report finds that 47% of generative AI users still work through personal accounts. * Industry analyses suggest that 38% of employees share sensitive information with AI platforms without approval. Shadow AI was already a serious problem when it meant ChatGPT and Claude accessed through personal accounts. Agent Skills take it to another level: what leaves the company is no longer just data, it's business expertise — encapsulated, versioned, shared, and completely invisible to IT. ## Why SKILL.md makes Shadow AI worse ### 1. Tight coupling to the LLM or agent A skill, as currently architected, is welded to its execution engine. An Anthropic skill is built for Claude. An OpenAI skill is built for GPT. A Copilot Studio skill lives inside the Microsoft ecosystem. The practical consequence: to use a skill, you have to adopt (and usually pay for) the corresponding LLM. Every business team that discovers an interesting skill library brings a new vendor with it — a new pricing model, a new data processing agreement. IT finds out about the commitment after the fact. This is the classic Shadow IT scenario, with a multiplier: a skill isn't an isolated tool, it's a block of business capability that creates operational dependency the moment it's adopted. ### 2. No concept of organization A skill has no idea which company it belongs to, which department, which function. It has no identified owner, no declared consumer, no org unit it reports into. The result: * **No mapping is possible**: there is no way to answer "how many skills are running in my company?" * **No pooling**: three teams can build three near-identical skills for the same task. * **No lifecycle**: who maintains a skill once its author leaves the company? * **No audit trail**: you cannot produce the inventory of deployed AI systems the AI Act requires. Article 4 of the EU AI Act requires a "sufficient level of AI literacy" across everyone exposed to these tools. That's hard to deliver when you don't even know which skills are in circulation. ### 3. No permissions, no ownership, no traceability A `SKILL.md` file carries no notion of: * Who is allowed to create it. * Who is allowed to consume it. * Who is accountable for its quality and compliance. * Which uses must be logged. It's a sharing format, not a governance format. And that is precisely what makes it, paradoxically, the ideal format for Shadow AI: easy to create, easy to distribute, impossible to track at enterprise scale. ### 4. Duplication and drift With no central catalog, business expertise dissolves into an endless set of diverging copies. The "client report generation" skill exists in seven versions, each with its own reading of the rules, its own hardcoded company data, its own bugs. When the GDPR audit arrives, when the AI Act calls for documentation of the AI system behind an automated decision, when a customer exercises their right to erasure — nobody can answer. ## This isn't a bug, it's a missing layer Let's be fair to Anthropic: SKILL.md never claimed to be a governance platform. It's a format, and an excellent one — but only a format. The problem is that no organizational layer has been built on top of it, and the community treats that gap as if it weren't there. The parallel is instructive. Source code doesn't govern itself: we had to invent Git, then GitHub, then pull request reviews, then CI/CD pipelines, then branch policies. Data doesn't govern itself: we had to invent data catalogs, data contracts, data products. Skills need their orchestration layer too. ## One approach: channel the initiative with a framework like skilder That's exactly the angle a framework like skilder takes. The point isn't to replace the SKILL.md format — which remains excellent — but to add a layer of organization, ownership and coordination on top of it. ### The core concept: the Role A **Role** is a named, thematic collection of skills that maps to an actual function or persona in the company. Instead of letting skills float around loose, you group them by business use: * A "Pre-Sales" Role gathers the skills for handling objections, drawing on competitive intelligence, and guiding a prospect through the sales cycle. * A "Legal Assistant" Role gathers the skills for contract analysis, regulatory monitoring, and drafting amendments. * A "DevOps" Role gathers the skills for deployment, monitoring, and incident response. When an employee — or an agent — takes on the "Pre-Sales" Role, they get the full, coherent set of capabilities approved for that function in one move. No more, no less. ### Why this changes everything This deceptively simple mechanism resolves several structural problems of Shadow AI: 1. **It channels initiative instead of banning it.** A salesperson who cobbled together their own skill can propose it for inclusion in the "Sales" Role. Individual initiative becomes a company asset instead of staying in the shadows. 2. **It makes mapping trivial.** "Which skills are running in my company?" becomes simply "which Roles do we have, and what's inside them?". The catalog is centralized, versioned, audited. 3. **It introduces explicit ownership.** Every skill has an owner and declared consumers. Maintenance, quality and compliance have a name and a face attached. 4. **It decouples expertise from the execution engine.** With an MCP-compatible approach, the same skill can be consumed by Claude, by Copilot, or by an in-house agent, with no rewrite. No more implicit vendor lock-in. 5. **It makes context selection intelligent.** Instead of loading the entire library into the context window, the agent loads only the skills in the active Role. Fewer tokens, fewer hallucinations, better performance. 6. **It offers a credible alternative to Shadow AI.** The core problem with Shadow AI isn't that employees have bad intentions. It's that they need to be productive and the official tools arrive too late. Giving teams a platform where they can build, share and consume approved skills inside the company's boundary means offering the fluidity of the shadow with the guarantees of the sanctioned. ### The conceptual architecture The idea fits in a few lines: ``` Workspace (enterprise boundary) └── Roles (business functions / personas) └── Skills (units of capability, SKILL.md compatible) ├── Instructions ├── MCP tools (LLM-agnostic) ├── References (markdown documents) └── Scripts (Python, sandboxed execution) ``` The SKILL.md format is preserved. A standard Anthropic skill can be imported as-is. But it now belongs to a workspace, is organized into Roles, exposed through an agent-agnostic protocol (MCP), traced, versioned, and subject to explicit permissions. ## What this means for CIOs and AI leads If you own AI governance in your organization today, here is the concrete question to ask: could you, this morning, list every `SKILL.md` file circulating in your company? If the answer is no — and statistically it is, in 80% of cases — then publishing a policy or banning ChatGPT is no longer enough. The missing layer is structural: 1. **Map what already exists.** The skills already sitting in Git repositories, in `~/.claude/`, in marketplaces. This is the AI equivalent of the GDPR record of processing activities. 2. **Centralize creation.** One place where a skill is declared, versioned and published, with an identified owner and consumer. 3. **Structure by Role, not by technology.** Think Roles before you think models. A salesperson doesn't need to know whether they're using Claude or GPT. They need the "Sales" Role. 4. **Decouple from the LLM.** Pick an abstraction layer — MCP is today's de facto standard — that lets you swap models without rewriting your skills. 5. **Make internal skill creation official.** Shadow AI thrives when the official channel is slower than the unofficial one. If getting a skill approved takes 48 hours and comes with an identified owner, nobody will bother building one on the side. ## Conclusion SKILL.md isn't the problem. It may well be one of the best formats for encapsulating AI expertise to have emerged in the last two years. But a format is not a platform. And as long as the ecosystem keeps treating skills the way we treated shell scripts in 2005 — passed around by hand, no owner, no catalog, no lifecycle — SKILL.md will remain, despite itself, the king of Shadow AI: the most convenient, most shareable and most invisible format enterprises have ever let into their systems. The good news is that the fix isn't to replace the format. It's to add the organizational layer it's missing. Roles to structure how the business actually works. A workspace to draw the enterprise boundary. MCP compatibility to avoid vendor lock-in. A catalog to make visible what's already circulating. Shadow AI isn't a signal that AI should be banned. It's a signal that it finally needs a framework where it can thrive without hiding. --- *Want to map the skills already circulating in your organization, or structure their adoption around clear business roles? That's exactly the problem skilder solves.* --- Source: https://www.skilder.ai/en/blog/skilder-awarded-a-chf-20-000-digital-grant-by-the-fit # Skilder awarded a CHF 20,000 Digital Grant by the FIT > Skilder has been awarded a CHF 20,000 Digital Grant by the Foundation for Innovation and Technology (FIT), the Vaud-based foundation that supports early-stage innovative companies in the canton. Language: en · Category: product · Author: The skilder team · Published: 2026-06-23 The grant was announced alongside support for two other Vaud start-ups: Isospec Analytics, an EPFL spin-off specialising in the identification of biological molecules for medical research, which received a CHF 400,000 Tech Growth loan, and MYSTONES, which received a CHF 20,000 Digital Grant for its athlete monitoring platform. ## The problem Skilder is solving In most companies, every employee uses AI tools their own way. Working methods, internal rules and hard-won best practices stay buried in individual conversations — they are never shared at the scale of the organisation. Skilder offers a platform that lets teams centralise those working methods and make them available across all the AI tools already used inside the company — with no technical skills required, and without replacing the tools already in place. ## What the grant will fund The CHF 20,000 Digital Grant will allow Skilder to refine the platform together with its first customers and to expand its presence in the market. Concretely, that means going deeper with the teams already using Skilder, tightening the product around what actually works in day-to-day use, and reaching more companies facing the same fragmentation of AI practices. ## About the FIT The Foundation for Innovation and Technology (FIT) supports innovative start-ups in the canton of Vaud through grants and loans across several stages of growth, from the Digital Grant and Tech Seed loans through to Tech Growth financing. Being selected is a meaningful signal for a young company: it comes with the scrutiny of an expert jury and connects the company to the wider Vaud innovation ecosystem. ## Read the press release The full FIT announcement is available here: [Isospec Analytics, MYSTONES and Skilder: three Vaud-based start-ups supported by the FIT](https://www.fondation-fit.ch/en/general/news/2026/isospec-analytics-mystones-and-skilder-three-vaud-based-start-ups-supported-by-the-fit) --- Source: https://www.skilder.ai/en/blog/what-is-shadow-ai # What is shadow AI? > Shadow AI is the unmanaged use of generative AI tools by employees. Definition, real-world risks, and how to respond without killing productivity. Language: en · Category: governance · Author: Nicolas Corod (Founder & CEO) · Published: 2026-05-20 ## TL;DR **Shadow AI** is the use of consumer generative AI tools ([ChatGPT](https://chatgpt.com/), [Claude](https://claude.ai/), [Gemini](https://gemini.google.com/), personal Copilot…) by employees **without policy, without audit, and often without IT or security approval**. It's the modern shadow IT, and it scales faster than anything that came before: [surveys put 70%+ of knowledge workers](https://www.microsoft.com/en-us/worklab/work-trend-index) as already using GenAI at work, most on personal accounts. Unlike shadow SaaS (which usually involves signing up for a tool) shadow AI starts with a single copy-paste into a browser tab. There is no procurement step to catch. ## What "shadow AI" actually covers The term spans a wider spectrum than most leadership teams realise: - A salesperson pasting a prospect's email into ChatGPT to draft a follow-up. - An engineer routing internal code through a personal Copilot subscription. - A finance analyst uploading an Excel extract to Claude to summarise the quarter. - A team building an undocumented automation on top of someone's personal OpenAI API key. Each one looks like a productivity hack to the individual. Together they form an unmanaged data-exfiltration surface that no DLP tool was designed to see, because the channel is a human typing into a browser, not a SaaS integration with a discoverable scope. ## Why shadow AI is a problem ### 1. Silent data leaks When a teammate pastes a draft contract, a customer list, or a code snippet into a consumer chatbot, that data may be: - **Stored by the vendor.** Retention policies vary by product, by tier, and over time. Personal-account terms are routinely different from enterprise ones, and they change without your knowledge. - **Used to train future models.** Most consumer tiers retain a training opt-in by default. Anything sensitive that goes in can resurface in another company's outputs months later. - **Transferred outside the EU.** Most consumer endpoints route through US infrastructure, putting any GDPR-covered payload onto the wrong side of a cross-border transfer. The trigger is usually mundane: a customer name in a reply, a clause from an ongoing negotiation, a snippet of source code with internal endpoint names. Nothing alarming on its own. Multiplied across an organisation, it adds up to a continuous leak with no incident timestamp to point at. ### 2. No audit, no policy You don't know: - **Who** is using what: accounts are personal, billing doesn't reach you, SSO doesn't apply. - **On which documents**: content is pasted from clipboards your endpoint controls can't introspect. - **With which prompts**, including any system prompt the user copied off a forum thread. If a regulator comes knocking, a customer files an Article 15 GDPR request, or you suffer an incident downstream, you have nothing to produce. You can't certify what wasn't used, because you don't know what _was_ used. ### 3. Lost value Usage stays **individual**. Nobody compounds. The prompt that finally cracked a tricky customer-support reply dies in someone's browser history at the end of the week. The few teammates who get genuinely good at GenAI become tribal knowledge centres of one. They leave, the practice leaves with them. The organisation pays the latency cost of every team rediscovering the same patterns alone. ## The wrong answer: banning Banning doesn't work. GenAI is too useful to drop. If you ban it, your teams will: - Keep using it on personal phones, outside any device-management posture. - Open anonymous accounts using personal emails. - Stop telling you about it, politely. Every ban policy that goes into effect has the same six-month outcome: usage continues, surfaces nowhere on a dashboard, and you've added a layer of dishonesty to the relationship. The leak now happens with both hands tied behind your back. ## The right answer: ship a governed alternative The fix is product, not policy. Make the controlled path the easy path. That means giving every employee an assistant **as capable as ChatGPT but under your governance**: - **Data stays in the EU:** hosted on infrastructure you've contracted with, on terms you've read. - **Every interaction is logged:** by user, by document, by tool, end-to-end. Audit is no longer a manual ask. - **Individual usage compounds:** working prompts and procedures get captured as reusable [Hats](https://docs.skilder.ai) the rest of the team inherits, instead of dying in browser tabs. A practical starting checklist for next quarter: 1. **Survey honestly.** Ask the team where they're already using consumer AI. The list will surprise you, and it's the input for everything else. 2. **Ship an internal alternative before banning anything.** People will switch if it's at least as good. They will not switch if you only take the existing option away. 3. **Make the audit trail visible to users**, not just to compliance. Knowing that interactions are logged changes behaviour more reliably than a policy memo nobody reads. That's exactly why we built [skilder](/en): so a CIO can give every employee an assistant that's worth using, while keeping the data, the audit and the institutional know-how on the company's side of the line. ## Key takeaways > Shadow AI isn't a discipline problem. It's a product problem. As long as your internal offering is worse than ChatGPT, your teams will keep using ChatGPT. To dig deeper, see [the skilder platform](https://docs.skilder.ai). --- Source: https://www.skilder.ai/en/blog/knowledge-vs-know-how # Knowledge vs. Know-How: The Distinction Quietly Killing Your AI Agents > 95% of enterprise AI pilots fail not because models are weak, but because they're loaded with knowledge and asked to deliver know-how. Why these are different categories. Language: en · Category: governance · Author: Nicolas Corod (Strategy) · Published: 2026-05-15 Why 95% of enterprise AI pilots fail isn't a model problem. It's a category error. ## The gap nobody names Most conversations about enterprise AI revolve around a single word: **knowledge**. We talk about knowledge bases, knowledge graphs, retrieval, [RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation), fine-tuning on proprietary data. We talk about knowledge bases, knowledge graphs, retrieval, RAG, fine-tuning on proprietary data. The implicit assumption is that if an AI agent *knows* enough about your business, it will *do* the right thing. It won't. And the reason is a distinction philosophers have drawn for decades, but that the AI industry keeps ignoring. There are two kinds of knowing: - **Knowing-that:** propositional knowledge. Facts, policies, documentation, data. Paris is the capital of France. Our refund policy allows returns within 30 days. Invoice #4521 is overdue. - **Knowing-how:** procedural knowledge. The ability to actually perform a task correctly in context. Riding a bike. Closing a deal. Processing that overdue invoice the way *this specific company* expects it to be processed. Gilbert Ryle called this the difference between "intellectual" and "practical" knowledge. Michael Polanyi called the practical kind "tacit knowledge": the things an expert knows but can't fully write down. Call it whatever you like. The point is: **knowing the facts of a job is not the same as knowing how to do the job.** And right now, most enterprise AI investments are buying the first and expecting the second. ## Why this matters for agents, specifically For chatbots, the knowledge/know-how gap was tolerable. A chatbot that knows your policies but doesn't know how to *apply* them is still useful: a human reads the answer and decides what to do. Agents change the equation. An agent isn't answering questions; it's taking actions. It's sending the email, updating the CRM, approving the expense, filing the ticket. The gap between *knowing* and *doing* stops being philosophical and becomes operational. A knowledge-rich, know-how-poor agent is a confident employee who's read the manual but has never done the job. That's not an asset. That's a liability with API access. This is, empirically, what's happening. [MIT's 2025 NANDA study](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) found 95% of enterprise AI pilots deliver zero measurable P&L impact. [S&P Global reports](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results) 42% of companies abandoned most AI initiatives in 2025, up from 17% the year before. The headline explanation is usually "context". But "context" is a vague word that blurs the real issue. The missing context isn't more documents to retrieve. It's the **procedural, tacit, institutional know-how** that tells an agent *how this company actually does this task*. ## What know-how looks like in practice Consider a real example. A project manager prepares a weekly executive briefing. The documents are available. An LLM can read them. A knowledge-based system can retrieve them on demand. But the actual job requires know-how the documents don't contain: - Which items count as a "key decision" for *this* leadership team (not the textbook definition) - Who has sign-off authority on what, and the unwritten exceptions - How to phrase a risk flag so the CFO takes it seriously without triggering a fire drill - Which stakeholders get pre-briefed before the meeting, and which get the synthesis after - The format conventions that have evolved over eighteen months of feedback None of that is in a document. It's in the PM's head. It's in the patterns of past briefings. It's in the tone of last quarter's Slack thread. It's **how the work actually gets done here**, and it's precisely the layer that generic AI agents, no matter how capable the underlying model, cannot access. ## The category error executives are making When AI initiatives stall, the instinct is usually to buy more of the same category. More documents indexed. Better retrieval. A bigger model. A more sophisticated RAG pipeline. Occasionally, fine-tuning, at $10K–$35K per model, plus data scientists in a tightening talent market. This is rational if the problem is knowledge. It's the wrong prescription if the problem is know-how. Know-how doesn't live in documents. It lives in **procedures, constraints, exceptions, judgment calls, and role-specific conventions**. And it doesn't generalize: the way your compliance team handles an exception is not the way your sales ops team handles an exception, even inside the same company. Packaging know-how means encoding not just *what* to do, but *how this team, in this role, under these constraints, wants it done*. That's a different kind of asset than a knowledge base. It needs to be: - **Procedural:** describing a sequence and its exceptions, not just facts - **Role-bound:** tied to who's doing the work, not just what's being done - **Composable:** so one piece of know-how can be reused across agents and contexts - **Auditable:** so when the agent acts, you can trace the reasoning back to the instruction ## Why this is skilder's starting point We don't think the current AI stack is broken. We think it's incomplete. Models have become astonishingly capable. Tool-calling standards like MCP have made connectivity tractable. What's missing is the layer between the two: the layer that turns generic capability into *this company's* way of working. That's what we build. We package know-how into what we call **Hats**: role-based bundles that capture how a specific job gets done in a specific organization. An agent puts on a Hat the way a new hire steps into a role: it inherits the procedures, the constraints, the exceptions, and the judgment calls that define competent work in that seat. One agent can wear multiple Hats and shift between contexts. One Hat can be worn by many agents, so know-how compounds instead of fragmenting. And because Hats are decoupled from any specific model, the same know-how works across Claude, GPT, Gemini, or whatever comes next. The shift, if you zoom out, is this: enterprises spent the last three years buying knowledge for their AI. The next three will be spent teaching it how to work. ## The takeaway If your AI pilots are stalling, the diagnostic question isn't *"does our agent have access to enough information?"*. It's *"does our agent know how we actually do this job?"* Knowledge gets you a well-read intern. Know-how gets you a trained employee. The difference, in production, is the difference between a demo and a deployment. --- Source: https://www.skilder.ai/en/blog/context-bloat-to-context-load # From Context Bloat to Context Load > Why enterprise AI gets heavier as it gets more capable, and how a capability graph lets you assemble context as a runtime payload instead of a static config file. Language: en · Category: engineering · Author: Nicolas Corod (Engineering) · Published: 2026-05-05 *Why your enterprise AI gets heavier as it gets more capable, and how to fix it structurally.* **TL;DR:** Your agent isn't getting dumber. Your context is getting fatter. --- ## Your agent was great at v1 Then came the second tool, the third guardrail, the fourth workflow script. Each addition made sense at the time. Nobody removed anything. By v3 your agent is carrying **8,000+ tokens of context before the user says a word**. It's started ignoring instructions, costing more, and responding slower. The instinct is to blame the model. But the model hasn't changed. What has changed is the context. > **The paradox of capability:** the more you add to your agent, the less reliably it performs. This is not a model problem. It is a context architecture problem. --- ## Three layers that grow without limit Enterprise agents carry three distinct types of content, each reasonable on its own, collectively toxic when unmanaged: **Tools:** API schemas, function definitions. A single tool with parameters and examples can run 200–400 tokens. 15 tools = up to 6,000 tokens before a word is spoken. **Skills:** behavioral instructions, compliance rules, persona guidelines. Written once, never pruned. They accumulate amendments like a legal contract. **Scripts:** chain-of-thought scaffolds, decision trees. Verbose by design. A triage script can consume 2,000+ tokens, most of it irrelevant to any given call. > At $3/M tokens, 10K daily conversations, 6 turns each: **~$1,500/day** in system context cost alone before the conversation starts. --- ## Bloat hurts in four distinct ways | | | |---|---| | ~2× | more instruction-following failures as context grows | | 18–24% | latency increase going from 1,400 to 8,400 tokens | | $440K | yearly cost delta at 10K conversations/day | *From our own deployments across 3 enterprise pilots (Nov 2024 – Feb 2025). Directional signal, not industry benchmarks. The latency findings align with [Anthropic's research on context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) showing that model accuracy declines as context windows fill.* Beyond cost and latency: the model starts making silent tradeoffs between instructions (which ones to follow, which to partially ignore) in ways nobody can predict or explain. We saw this as a consistent rise in escalations and output review flags once system prompts crossed 6,000 tokens. > **On bigger context windows:** reaching for a model with a 500K-token window doesn't fix bloat. It just makes bloat more expensive. Larger windows raise the ceiling. They don't fix the discipline problem of what should actually be loaded. --- ## Stop dumping. Start loading. Most teams treat the context window like a configuration file: fill it with everything the agent might need and leave it static. This is the bloat mindset. The alternative: treat context as a **runtime payload**. Assembled fresh for each call. Containing only what this agent, handling this task, in this turn, actually needs. > **The load principle:** every token in your context should be able to answer: *why is this here, for this call, right now?* If the answer is "it might be useful," that token is probably bloat. --- ## Decouple capabilities from agents Patching individual agents doesn't scale. As soon as you have 6, 10, 15 agents, you have **n agents each solving the same context problem independently**, with no shared governance, no shared versioning, and days of lag every time a tool or compliance rule changes. The structural answer: **agents should not own their capabilities.** Tools, skills, and scripts should be defined centrally, versioned independently, and assembled into context dynamically at runtime based on role and task. In practice this means a capability graph: nodes are tools, skills, and scripts; edges define their relationships. An agent declares a role. A resolution engine traverses the graph and loads exactly the right bundle for this call. > **Before:** 12 tools + 6 skill blocks + 2 scripts = 8,400 tokens per call. > > **After:** 3 tools + 1 skill block + 1 script = 2,000 tokens per call. A 76% reduction, consistent with our first pilot migration. --- ## The model landscape pushes both ways **Frontier models:** context windows keep growing, but so do per-token costs. A bloated 8,400-token prompt on a premium frontier model doesn't solve bloat. It runs it on more expensive infrastructure. **Small language models:** SLMs (Phi-4, Mistral Small, Llama 3.2) are rising fast for on-premise, cost-sensitive, and data-sovereign deployments. Their 4K–32K context limits make capability architecture not optional, but mandatory. The capability graph is a **model-agnostic abstraction layer**. It doesn't care if the underlying model has 8K or 800K tokens. It assembles the right payload and hands it to whatever model the deployment requires: the same architecture for an on-premise SLM at a regulated bank and a frontier model handling complex enterprise workflows. --- ## Six questions to check your context health - **Injection ratio:** what proportion of your system prompt is injected on every call vs. conditionally? Mostly always = bloat risk. - **Tool utilization:** what share of your registered tools are actually called? Below 40% is tool sprawl. - **Instruction age:** when did you last review each block? Anything untouched for 90+ days likely has redundancy or contradiction. - **Removal cadence:** when did you last remove something? Teams that only add are accumulating by definition. - **Capability ownership:** if a tool's API changes, how many agent definitions need updating? More than three is a governance problem. - **Context observability:** can you see the exact payload sent on each call in production? If not, you can't audit, optimize, or govern. > A well-scoped agent role should carry **2,000–3,500 tokens** of system context for a focused task. In agents we audited before migration, the median was 7,800 tokens. --- *Context bloat is a symptom of treating context as a configuration file. Context load is what happens when you treat it as engineering.* --- Source: https://www.skilder.ai/en/blog/context-lake # The Context Lake: Why Your Data Lake Isn't Enough for AI Agents > A new layer is taking shape in the agentic enterprise stack: the context lake. Business context, tool permissions, and governance need their own home. Language: en · Category: governance · Author: Nicolas Corod (Strategy) · Published: 2026-04-20 A new phrase is appearing across product pages, analyst notes and architecture diagrams: **context lake**. Port uses it to describe an engineering knowledge layer. Tacnode is building a real-time version of it. Forrester published a piece earlier this year arguing it matters for agentic AI. An arXiv paper introduced it as a formal system class. The term is converging, from different directions and with different emphases, on the same intuition: the data infrastructure built for the analytics era is not the data infrastructure the agent era needs. The case worth making: the context lake will be as foundational for the agentic enterprise as the data lake was for the analytics enterprise, and the companies that understand this early will hold a structural advantage that is hard to copy. ## The data lake answers "what happened." The context lake answers "what should I do." Since the mid-2010s, the data lake has been the center of gravity for enterprise data strategy. Dump everything in, figure out the questions later, let the analysts and the models sort it out. It worked, sort of, for dashboards, for BI, for the first wave of machine learning. It even worked for the early days of generative AI, when "plug your documents into a vector database" felt like a complete answer. It is not a complete answer anymore. And the reason is that the thing we're now building on top of enterprise data is fundamentally different from a dashboard or a model. It's an agent. And agents don't need data. They need **context**. A data lake is a passive reservoir. It stores facts (transactions, logs, documents, events) and waits for someone or something to come ask a question. Its value is measured in volume, freshness, and query performance. Its consumers are humans with SQL, BI tools, and ML pipelines. The governance model assumes a relatively small number of sophisticated users who know what they're looking for. An AI agent is a fundamentally different kind of consumer. It doesn't arrive with a pre-written query. It arrives with a goal ("resolve this customer complaint," "close the books for Q3," "negotiate this renewal") and it has to figure out, on the fly, what it needs to know, what tools it's allowed to use, what rules govern its decision, and what "done" actually looks like in your company. No amount of well-organized Parquet files will tell it any of that. That missing layer (the business logic, the tool permissions, the policies, the institutional knowledge about how *your* company actually operates) is what a context lake holds. It is the difference between handing someone the Library of Congress and handing them an onboarding binder for their specific job. ## What actually lives in a context lake The early definitions emerging in the market emphasize different slices of this. Port focuses on engineering and service ownership. Tacnode emphasizes real-time freshness and decision-time consistency. Both are right about their piece. But the full picture, in my view, is broader. Three things, and they don't live cleanly in any system you already own. **Business context.** This is the semantic layer an agent needs to act intelligently on your behalf. What does "active customer" mean at your company: someone who logged in this month, or someone whose contract is current? Which SKUs are discontinued but still serviceable? Which accounts are strategic and require a human in the loop? This knowledge exists today, but it's scattered across Confluence pages, Slack threads, the heads of senior employees, and tribal lore. A data lake has the transactions; it does not have the meaning. **Tools and capabilities.** An agent's power comes from its ability to *do things*: call APIs, write to systems of record, send communications, move money. A context lake catalogs which tools exist, what they do, when they should be used, and, critically, under what conditions each agent is allowed to use them. This is not the same as an API gateway. An API gateway asks "is this request authenticated?" A context lake asks "is this the kind of decision this agent should be making right now, for this customer, at this dollar amount, without escalation?" **Governance and policy.** Every regulated industry has rules about what can be automated and what can't, what must be logged, what requires human review, what must never leave a given jurisdiction. In a world of deterministic software, those rules get baked into application code. In a world of probabilistic agents that reason over natural language, the rules themselves have to become first-class, queryable, auditable artifacts. The context lake is where policy becomes executable, not as buried if-statements, but as a governed layer the agent consults before it acts. The interesting thing about these three is that no enterprise has all of them in one place today. The business semantics live in people's heads and scattered docs. The tool permissions live in API gateways and IAM policies. The governance lives in legal PDFs and compliance spreadsheets. The work of the context lake is to make all three legible, queryable, and governed in a single layer. ## Why this has to be a new layer, not a feature of something else The obvious objection is: can't we just put all this in the data lake? Or in the vector database? Or in the agent framework? People are trying. Here's why it doesn't hold up. The data lake is optimized for volume and analytical queries, not for the low-latency, high-precision lookups an agent needs mid-decision. Vector databases are good at semantic similarity but have no native concept of permission, policy, or tool affordance. They'll happily retrieve a document the agent has no business acting on. And agent frameworks themselves are moving too fast and fragmenting too quickly to be the system of record for something as durable as your company's business rules. You do not want your governance model coupled to whichever orchestration library is in fashion this quarter. What the enterprise needs is a layer that is *agent-framework-agnostic, centrally governed, and built from day one around the three primitives of agentic work*: knowing, doing, and being allowed. That's a different shape of product than anything that existed in the modern data stack two years ago, which is exactly why several companies, skilder included, are now converging on building it. ## The strategic stakes I'll be direct about why this matters at the executive level, because it's easy to hear "new layer in the stack" and tune it out as plumbing. The companies that deploy agents successfully over the next three years will not be the ones with the most data. They will be the ones who have done the work of making their context (their judgment, their rules, their institutional knowledge) legible to machines. That work is not a weekend project. It is the next version of what we used to call "digital transformation," and it is the real moat. Your competitors can buy the same models and the same data warehouses. They cannot easily replicate a decade of codified operational wisdom. Conversely, the companies that try to shortcut this, by throwing agents at a raw data lake and hoping the LLM figures it out, are going to generate a very expensive lesson in why context is not the same as information. We are already seeing the early versions of this lesson in production. Agents that confidently take the wrong action. Agents that can't explain their reasoning to an auditor. Agents that work beautifully in the demo and fall apart the first time they encounter the messy realities of how the business actually runs. ## Where to start If you're a leader thinking about how to prepare your organization for the agentic wave, the question to take back to your team isn't "which model should we use" or "which vector database is best." It's a simpler and harder one: *If we had to hand a brand-new, highly capable employee the binder that tells them how our company actually works (the rules, the tools, the judgment calls, the things that are never written down), could we? And if not, what would it take?* That binder is your context lake. The category is still being defined; the vendors are still emerging; the term itself is still settling into a shared meaning. But the underlying need is already real, and the agents are already at the door. Whichever name wins, the work of building this layer is the work that's going to separate the enterprises that make agents pay off from the ones that don't. --- Source: https://www.skilder.ai/en/blog/mcp-vs-skills-composing # Beyond "MCP vs Skills": Composing for Scalable Agent Architecture > MCP solves the N×M connectivity problem. Skills solve context saturation. The real opportunity isn't picking one. It's composing skills over MCP, organized by business context. Language: en · Category: engineering · Author: Nicolas Corod (Engineering) · Published: 2026-02-05 The debate framing MCP and skills as competitors misses the point. As Kurtis Van Gent [argued recently](https://kvg.dev/posts/20260125-skills-and-mcp/), they solve different problems: [MCP](https://modelcontextprotocol.io/) tackles the N×M integration problem, skills address context saturation. True. But the real opportunity is composing them into a unified architecture. At [skilder](https://www.skilder.ai), we've built exactly this: skills that compose MCP tools into coherent capabilities, organized by business context, and exposed through a single MCP server with progressive disclosure built into the protocol. ## Two problems, one architecture **The N×M Integration Problem.** You have N agents (Claude Code, Cursor, your custom SDK) and M data sources (GitHub, Slack, Postgres). Without standardization, every agent-tool pair needs a custom connector. MCP collapses this to N+M with a universal protocol. **The Context Saturation Problem.** Your agent has access to 80 tools. Each tool schema consumes tokens. Load them all upfront and you burn 30,000 tokens before the user says hello. Worse, models perform worse when forced to reason over irrelevant options. Google's ADK team calls this "signal degradation." Agent skills solve this through progressive disclosure. The agent sees lightweight metadata first. Full instructions and tools load on demand. ## Where each approach falls short alone **MCP's context tax.** Every connected MCP server dumps its tool definitions into your context window. Connect to GitHub, Slack, Postgres, and a CI/CD server: hundreds of tool definitions loaded before any work begins. Anthropic's own research found that loading definitions on demand dropped token usage from 150,000 to 2,000 in one case. **The isolation problem.** A skill teaches an agent how to deploy code. But reaching the actual deployment system requires custom scripts (environment-dependent, fragile) or falling back to MCP (losing context efficiency). Write a skill on macOS, share it with a colleague on Windows, and watch it break. **Multi-server sprawl.** Teams end up with five MCP servers connected, a dozen skills scattered, and no clear relationship between them. The agent must figure out which skill applies to which server, which tools belong to which workflow. Cognitive load compounds. ## The composition thesis The fix: skills become the composition layer over MCP. A skill groups related MCP tools into a coherent unit with instructions on how to use them together. A "deploy-to-staging" skill links the specific tools it needs and guides the agent through the workflow. The agent sees "deploy-to-staging" as a single concept. It doesn't need to know that GitHub and CircleCI exist as separate systems. MCP handles connectivity. The skill handles choreography. At [skilder](https://www.skilder.ai), we expose this through a single MCP server. Your agent connects to one endpoint instead of five. Progressive disclosure is built into the protocol itself: the agent starts with a lightweight catalog of available skills and loads full tool schemas only when needed. The result: instead of paying 20,000 tokens upfront for 10 servers worth of tools, you pay around 2,900 tokens with equivalent capabilities loaded on demand. ### Business context, not tool catalogs A flat list of skills creates its own problem. In enterprise environments, dozens of skills spanning multiple teams create the same cognitive overload, one level up. We organize skills into business context groups: named collections by role, domain, or workflow. A "DevOps" group bundles deployment, monitoring, and rollback. A "Customer Support" group bundles lookup, billing, and escalation. The agent navigates business concepts rather than technical categories. This bridges how engineers think (tools, APIs) and how organizations think (roles, processes, domains). ### From transparency to delegation Not every workflow needs the same level of agent involvement. Simple tool groupings need full agent control. Complex, proven workflows benefit from delegation. [skilder](https://www.skilder.ai) supports a spectrum: from the agent orchestrating individual tools with full transparency, to sub-agent execution where a self-contained process handles the complexity. Organizations start transparent and graduate high-confidence workflows to delegation as they prove reliability. ## Why this scales **Context efficiency.** Agents pay for what they use. Not for what they might use. **Reduced cognitive load.** Pre-composed capabilities with clear instructions. Tool selection errors drop when agents work with coherent workflows instead of raw tool schemas. **Single connection point.** One MCP server to connect, configure, and secure. No credential sprawl. **Enterprise governance.** Every skill invocation and tool call is tracked. Full audit trails feed into optimization: unused skills, timeout patterns, failure hotspots. Skills improve from usage data over time. **Dependency awareness.** When an underlying MCP server changes, affected skills are identified automatically. Updates propagate through the system instead of requiring manual audits. ## Trade-offs **Authoring complexity.** Creating composed skills requires understanding both the workflow and the underlying tools. Our approach: AI-assisted skill generation. Describe a workflow in natural language. [skilder](https://www.skilder.ai) bootstraps the skill structure. **Debugging depth.** Abstraction layers add debugging complexity. Mitigation: structured telemetry at each layer with trace context flowing through the entire stack. **Discovery overhead.** Progressive disclosure adds a round-trip before the agent uses tools. Pre-loaded skills bypass this for known workflows. For most enterprise use cases, context savings far outweigh the cost. ## Getting started 1. **Identify high-value workflows.** Find three to five workflows where your team repeatedly coordinates multiple tools. Those are your first composed skills. 2. **Start simple, graduate to delegation.** Begin with skills that group related tools with good instructions. Promote stable workflows to higher automation as they prove reliability. 3. **Organize by business context early.** Structure skills by role or domain from the start. Imposing structure later is harder. 4. **Expose through a single gateway.** Connect your agents through one MCP server. Adding skills doesn't increase baseline context cost. ## Looking forward The [SEP-2076 proposal](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076) suggests adding Agent Skills directly to the [MCP](https://modelcontextprotocol.io/) spec. Native support for composed skills with tool dependencies and progressive disclosure would make this pattern standard rather than custom-built. Beyond that, federated skill graphs: organizations publishing skill collections that others consume and extend. Community-maintained DevOps skill graphs, extended with company-specific workflows. Composition at the ecosystem level. The MCP vs Skills debate is a false dichotomy. MCP solves connectivity. Skills solve context efficiency. The model we've built at [skilder](https://www.skilder.ai) composes them: skills over MCP, organized by business context, exposed through a single server with protocol-level progressive disclosure. The future of agent architecture is skills over MCP, composed into a knowledge graph that scales with your organization. --- Source: https://www.skilder.ai/en/blog/skill-graphs-scale-ai-context # Beyond Single .md Files: How Skill Graphs Scale AI Context > Single skill files hit a complexity ceiling fast. Skill graphs turn domain expertise into a navigable network so agents can traverse business logic instead of guessing. Language: en · Category: engineering · Author: Nicolas Corod (Engineering) · Published: 2026-01-31 People underestimate the power of structured knowledge. It enables entirely new kinds of applications. Right now people write skills that capture one aspect of something. A skill for summarizing, a skill for code review and so on. Often one file with one capability. That's fine for simple tasks but real depth requires something else. Imagine a mortgage advisory skill that provides relevant information about loan qualification criteria, regulatory compliance frameworks, risk assessment methodologies, property valuation standards, and customer communication best practices. A single skill file can't hold that. ## The problem: single skills hit a complexity ceiling When you try to capture complex domain knowledge in a single file, you run into hard limits: - **Artificial boundaries:** related concepts get separated because they "belong" to different skills. - **Knowledge duplication:** shared concepts get copied across multiple skills, creating maintenance nightmares. - **Lost connections:** the relationships between concepts aren't navigable, they're just implicit. - **Scalability breakdown:** beyond 500-1000 lines, single files become unmanageable. This isn't a theoretical problem. Try putting mortgage lending knowledge into one skill file: loan products, underwriting rules, compliance requirements, risk assessment frameworks, customer qualification criteria. You either create a massive monolith or fragment the knowledge so much that agents can't see how the pieces connect. The single-file approach forces you to choose between depth and navigability. Skill graphs eliminate that tradeoff. ## Skill graphs: the next evolution A skill graph is a network of interconnected skill files that reference each other. Instead of one big file you have many small composable pieces that link together. Each file is one complete thought, technique, or business rule. The connections between them create a traversable graph that agents navigate intelligently. A skill graph applies the same skill discovery pattern recursively inside the graph itself. Every node has metadata the agent can scan without reading the whole file. Every connection carries meaning because it's embedded in context, so the agent follows relevant paths and skips what doesn't matter. **Progressive disclosure:** - Index to descriptions to links to sections to full content Most decisions happen before reading a single full file. ## Single skills vs. skill graphs: the comparison | Dimension | Single skills | Skill graphs | |-----------|--------------|--------------| | **Depth** | Limited to what fits in one file | Unlimited, scales with domain complexity | | **Maintainability** | Update requires editing entire file | Update one node, entire graph benefits | | **Composability** | Hard to reuse across contexts | Designed for composition and reuse | | **Context Flow** | Isolated silos of knowledge | Interconnected expertise networks | | **Agent Behavior** | Follows instructions | Understands domain relationships | | **Time to Value** | Fast for simple tasks | Compounds over time as graph grows | | **Scalability** | Breaks down beyond 500-1000 lines | Scales to thousands of interconnected nodes | ## What a skill graph looks like in practice Once you move beyond single files to interconnected expertise networks, the same pattern shows up across industries: - **A construction company skill graph:** safety protocols, compliance requirements, vendor management, project scheduling, quality assurance checklists. Each piece linked to related procedures so context flows between them. - **A financial services skill graph:** mortgage products, underwriting criteria, regulatory compliance, customer qualification rules, risk frameworks. All traversable from one entry point. - **A manufacturing company skill graph:** quality standards, production workflows, supplier requirements, inventory policies, equipment maintenance. None of these fit in one file, but all of them work as graphs. ## Infrastructure primitives A skill graph architecture relies on three core elements: - **Semantic connections** embedded in natural language context, so links carry meaning not just references. - **Structured metadata** with descriptions, so agents can scan and decide without reading full files. - **Topic maps** that organize clusters of related skills into navigable domains. Skills reference other skills, which reference other skills, and the graph goes as deep as the domain requires. ## Implementation architecture The skill graph architecture skilder implements follows this pattern: **1. Skill generation:** documents and policies are processed to generate structured skill nodes without requiring ML expertise. **2. Combination layer:** skills aggregate with tool integrations through [Model Context Protocol (MCP)](https://modelcontextprotocol.io/), providing both context and action capabilities. **3. Role-based bundling:** skills are organized into domain-specific bundles (e.g., Mortgage Advisor, Safety Officer) that represent complete operational contexts. **4. Distributed execution:** the infrastructure distributes across organizations with full execution tracing and auditability. These components work together as nodes in an interconnected graph rather than isolated capabilities. ## What this changes Traditional approaches come with significant constraints: - **Custom RAG builds:** $10K-$35K per model, 6-12 months - **Generic chatbots:** No business context, limited adoption for mission-critical work - **Fine-tuning:** Requires scarce ML talent, expensive retraining for every update Skill graphs offer a different approach: - Domain expertise packaged as traversable infrastructure - Agents can navigate business logic contextually - Context compounds and evolves with usage - Updates propagate through the graph without retraining The difference is between an agent that follows instructions and one that can navigate domain relationships. ## Emergence through usage Skill graphs exhibit interesting emergent properties as they scale: - Individual contributors create skills for their specific workflows - Usage patterns reveal which conceptual connections are actually relevant - Navigation traces show how agents traverse domain knowledge in practice - Cross-organizational patterns can surface common approaches to similar problems - Meta-patterns emerge from aggregated graph traversal data This creates a feedback loop where the infrastructure becomes more effective as it's used, without requiring centralized curation of every connection. ## Infrastructure deployment considerations Skill graphs containing business logic raise important deployment questions. [skilder's implementation](https://www.skilder.ai) addresses these through: - **Data residency** options including EU-hosted infrastructure - **Compliance by design** for GDPR and similar frameworks - **Governed deployment** capabilities for enterprise scale - **BYOK architecture** to eliminate pass-through AI API costs Organizations can maintain control over their knowledge graphs while leveraging the composability benefits of the skill graph architecture. ## Looking forward Skills represent one approach to context engineering: curated knowledge injected where it's needed. Skill graphs extend this by making that knowledge navigable rather than monolithic. Instead of single injections, agents traverse knowledge structures and pull in what the current context requires. As enterprises continue working on AI adoption, questions around structuring and maintaining business context will likely become increasingly important. --- ## References 1. Anthropic: [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) 2. Dgraph: [Graph Database for Knowledge Infrastructure](https://dgraph.io/) --- Source: https://www.skilder.ai/en/blog/agent-skills-vs-workflow-platforms # Agent Skills vs. Workflow Platforms: Which One Should You Actually Use? > Workflow platforms vs. AI agent: it depends on how messy your reality is. A framework for choosing between deterministic workflows and adaptive agent skills, plus the hybrid that wins. Language: en · Category: product · Author: Nicolas Corod (Product) · Published: 2026-01-29 Most CIOs face the same decision when a new internal process lands on the roadmap: automate it with a workflow platform like Zapier, or hand it to an AI agent. The honest answer is that the choice depends on how messy the reality is, and it will define how the business handles automation for the next five years. Workflows excel where inputs are predictable and the process rarely changes. Agent skills earn their keep when inputs are unstructured, the rules drift, or the task requires real judgment. Picking the wrong one shows up as maintenance debt within six months, either in a fragile chain of "if/then" branches or in an agent acting confidently on the wrong shape of input. This article lays out a decision framework: when each approach is the right call, why agent skills are quietly winning the battle for knowledge-work automation, and how the strongest production setups combine both. --- ## First, let's define what we're talking about ### Workflow platforms: the programmed assembly line Think of tools like [Zapier](https://zapier.com/), [Make](https://www.make.com/), or [n8n](https://n8n.io/) as **assembly lines you program yourself**. The logic is simple: IF [trigger happens] THEN [do action 1] → [do action 2] → [do action 3]. Example: When a new email arrives → extract the attachment → save it to Google Drive → notify the team on Slack. **What they do well:** - Predictable, repeatable execution - Clear audit trail (you can see exactly what happened) - No AI required, pure logic - Fixed costs (monthly subscription) **Where they struggle:** - Rigid. If something unexpected happens, the workflow breaks. - Complex scenarios require dozens of steps and conditions - Maintenance becomes a nightmare as edge cases multiply - You're essentially programming for a world that doesn't exist: a perfectly predictable one. **The analogy:** A workflow platform is like a vending machine. Press B7, get a snack. But ask for "something healthy with protein" and it stares at you blankly. --- ### Agent skills: the intelligent assistant with a toolbox Now imagine something different: an AI assistant (like Claude or GPT) that **understands your goal** and has access to tools: email, spreadsheets, databases, APIs. You don't program every step. You describe the objective: "Process incoming quote requests and route them to the right salesperson based on the product and region." The agent figures out how to do it. It reads the email, understands the context, extracts the relevant information, makes a judgment call, and takes action. **What they do well:** - Adapts to unexpected inputs (messy emails, unusual requests) - Handles ambiguity through reasoning - One prompt replaces dozens of workflow steps - Evolves easily: change the instructions, change the behavior **Where they struggle:** - Less predictable (the same input might produce slightly different outputs) - Costs scale with usage (tokens) - Requires guardrails to prevent unwanted actions - Harder to audit ("why did it do that?") **The analogy:** An agent skill is like a smart intern. Give them a goal, they figure out the steps. They might surprise you, sometimes positively, sometimes not. --- ## The real test: a side-by-side comparison Let's make this concrete. Imagine you receive quote requests by email. You need to: 1. Extract the client's name, company, and product interest 2. Check if they're an existing client in your CRM 3. Route to the right salesperson based on region 4. Send an acknowledgment email 5. Create a task in your project management tool ### How a workflow platform handles it You build a 15-step automation: 1. Trigger: New email with subject containing "quote" 2. Parse email body with regex patterns 3. Extract name (pattern match) 4. Extract company (pattern match) 5. Extract product (keyword detection) 6. API call to CRM: search by email 7. Condition: if found → branch A; if not → branch B 8. Lookup region from CRM data 9. Match region to salesperson (lookup table) 10. Send templated acknowledgment email 11. Create task in project tool 12. Error handling for each step 13. Logging 14. ... and so on. **It works.** Until someone sends a quote request with the subject "Quick question about pricing" (no "quote" keyword). Or writes their company name in the signature instead of the body. Or asks about two products. Or replies to an old thread. Each edge case requires a new branch. Your clean automation becomes a tangled web. **Maintenance reality:** After 6 months, nobody wants to touch it. --- ### How an agent skill handles it You write one instruction: > "When a new email arrives that looks like a quote request, extract the client name, company, and product interest. Check our CRM to see if they're an existing client. Route to the appropriate salesperson based on their region (use the sales territory mapping). Send a personalized acknowledgment and create a follow-up task." The agent reads the email, including the messy, unstructured, human parts. It understands that "Quick question about pricing for the enterprise plan" is a quote request. It finds the company name in the signature. It handles the ambiguity. **Edge cases?** The agent reasons through them. "This email mentions two products. I'll note both and let the salesperson clarify." **Maintenance reality:** Change the routing logic? Update the prompt. Done. --- ### The comparison table | Criteria | Workflow Platform | Agent Skill | |----------|-------------------|-------------| | **Setup complexity** | High (15+ steps) | Low (1 prompt + tools) | | **Handles variations** | Breaks on unexpected inputs | Adapts through reasoning | | **Maintenance** | Heavy (edge case management) | Light (prompt updates) | | **Cost model** | Fixed (subscription) | Variable (per token) | | **Auditability** | Excellent (clear logs) | Moderate (reasoning traces) | | **Predictability** | Very high | High but not absolute | | **Best for** | Stable, high-volume processes | Variable, judgment-heavy tasks | --- ## When to use what: a practical framework ### Choose a workflow platform when: - Your process is **100% predictable** and rarely changes - You need **zero tolerance for variation** (compliance, legal, financial transactions) - **Volume is high** and inputs are perfectly structured - You need **bulletproof audit trails** for regulators - Your team needs to **maintain it without AI expertise** **Examples:** Invoice processing with standardized PDFs, user signup → welcome email sequences, inventory alerts based on fixed thresholds. --- ### Choose an agent skill when: - Inputs are **variable or unstructured** (emails, documents, conversations) - The task requires **contextual judgment** ("Is this urgent?" "Who should handle this?") - Your process **evolves frequently** (new products, changing rules) - Volume is **moderate** but complexity is **high** - You're dealing with **natural language** from humans **Examples:** Customer support triage, document analysis, lead qualification, research synthesis, content processing. --- ### The optimal hybrid: best of both worlds Here's what smart teams are doing: **Agent skill at the front, workflow at the back.** The agent handles the messy, unpredictable intake: understanding emails, classifying requests, extracting structured data from chaos. Then it hands off clean, structured data to a workflow that executes deterministic actions: updating the CRM, sending notifications, creating records. **Think of it this way:** - Agent skill = the brain (understanding, deciding, routing) - Workflow platform = the hands (executing, recording, notifying) This hybrid approach gives you adaptability where you need it and predictability where it matters. --- ## Why agent skills are quietly winning I'll be direct: for most knowledge work automation, agent skills are becoming the better choice. Here's why: **1. The real world is messy.** Your customers don't write perfectly formatted emails. Your data isn't always clean. Your processes have exceptions. Workflows are built for an ideal world; agents are built for the actual one. **2. Token costs are dropping fast.** The economic argument against agents ("too expensive at scale") is eroding. Costs have dropped 90%+ in two years. The trend continues. **3. Skills are becoming reusable building blocks.** Just like workflows have pre-built templates, agent skills are becoming modular. "Email processing skill," "document extraction skill," "CRM lookup skill": snap them together. **4. Maintenance compounds differently.** A workflow's complexity grows with edge cases. An agent's capability grows with better instructions. One scales painfully; the other scales gracefully. **The bottom line:** A workflow automates what you anticipated. An agent skill handles what you didn't. --- ## What this means for you Before you build your next automation, ask yourself three questions: 1. **How predictable are my inputs?** If >90% identical → workflow. If variable → agent skill. 2. **Does this task require judgment?** Yes → agent skill. No → workflow. 3. **How often will this process change?** Frequently → agent skill. Rarely → workflow. And if you're unsure? Start with an agent skill. You can always add workflow components for the deterministic parts later. --- The automation landscape is shifting. Workflows won't disappear: they're still unbeatable for pure, predictable execution. But for the messy reality of business operations, agent skills are increasingly the right tool. The question isn't "workflow or agent?" anymore. It's "how do I combine both intelligently?" --- Source: https://www.skilder.ai/en/blog/rag-vs-agent-skills # RAG vs Agent Skills: The Key Difference Everyone Should Know > RAG retrieves content. Skills package competencies. Why conflating them limits how companies think about AI agents, and a framework for choosing between them. Language: en · Category: engineering · Author: Nicolas Corod (Research) · Published: 2026-01-21 ### "So basically, agent skills are just another way to feed documents to the agent, right?" This question comes up frequently in conversations about AI agents. And every time, it reveals a fundamental misunderstanding that limits how companies think about agent capabilities. [Agent skills](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) and [RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) are not the same thing. They solve different problems, operate at different levels, and conflating them leads to underestimating what skills can actually do for your AI strategy. Let's clear this up. ## What is RAG? A quick definition RAG (Retrieval-Augmented Generation) is a retrieval mechanism. Its job is to search through a corpus of documents and return relevant information to the agent. When a user asks "What is our return policy for international orders?", RAG searches the policy documents, finds the relevant section, and serves that text to the agent. The agent then uses this retrieved content to formulate its response. RAG is essentially a search engine for your internal knowledge base. It finds and returns existing content. Nothing more, nothing less. This is valuable. Without RAG, an agent only knows what it learned during training: generic knowledge with no awareness of company-specific information. RAG bridges that gap by giving the agent access to proprietary documents. But retrieval is where RAG stops. It answers the question: *"What information exists about this topic?"* ## What is an agent skill? A skill is fundamentally different. It is not about retrieving information. It is about enabling competent execution. A [skill](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) packages three elements together: the domain knowledge relevant to a specific task, the process logic for how to handle that task properly, and the execution capabilities to actually perform actions. Consider the difference with a concrete example. A user says: "I want to return this product I ordered three weeks ago." With RAG alone, the agent can search the return policy document and tell the user what the policy says. It retrieves and relays information. With a return handling skill, the agent understands the policy rules, knows the process steps for evaluating a return request, can check order history and eligibility, and can initiate the return in the system if conditions are met. It doesn't just inform. It executes. A skill answers a different question: *"How should this task be handled, and what actions are required?"* ## RAG vs agent skills: the core distinction The confusion between RAG and skills often stems from surface-level similarity: both involve "giving information to the agent." But the nature of that information is entirely different. **RAG provides content:** raw text retrieved from documents that the agent must interpret on its own. **Skills provide context:** structured knowledge that shapes how the agent reasons, decides, and acts in specific situations. | Aspect | RAG | Agent Skill | |--------|-----|-------------| | **Purpose** | Retrieve existing content from documents | Enable competent task execution | | **Output** | Information returned to the agent | Action + outcome delivered to the user | | **Contains** | Search mechanism + document corpus | Knowledge + process logic + execution capability | | **Analogy** | Library access | Professional training | | **Answers** | "What information exists?" | "How should this be done?" | Think of it this way: RAG is like giving someone access to a library. Skills are like giving someone professional training. Access to medical textbooks does not make someone a doctor. The training (which combines knowledge, methodology, and practical capability) does. An agent with RAG can look things up. An agent with skills can perform tasks competently. ## Why this matters for AI agent design When companies treat skills as "just another way to feed documents," they design their agents around retrieval rather than capability. The result is an agent that can answer questions but struggles to actually help users accomplish tasks. This shows up in several ways: - Agents that provide accurate information but require users to take all the actions themselves - Agents that lack consistent methodology for handling complex requests - Agents that cannot adapt their behavior based on situational context The shift from RAG-centric to skill-centric thinking changes the design question from "What documents does the agent need access to?" to "What competencies does the agent need to perform its job effectively?" ## When to use RAG vs skills: a practical framework Here is a simple way to determine which approach applies to a given need: **Use RAG when** the goal is to surface existing information: answering questions about policies, finding relevant documentation, providing reference material. **Use skills when** the goal is competent task execution: handling requests that require understanding context, applying rules, following processes, and taking actions. **Use both when** an agent must operate as a capable assistant rather than a search interface. In most real-world applications, this is the case. ## The integration question A natural question arises: where do tool integrations fit in this model? Traditional architectures often separate knowledge (RAG), reasoning (the LLM), and actions (tool integrations) into distinct layers. This creates complexity and fragmentation: the agent must coordinate between systems that don't inherently understand each other. A more effective approach bundles these elements together. When domain knowledge, process logic, and execution capability are packaged as a unified skill, the agent gains a coherent competency rather than disconnected pieces. This is the approach [skilder](https://skilder.ai) takes: skills are complete competencies, not just documents or tool connections. The agent doesn't retrieve a policy, then separately figure out how to apply it, then separately invoke a tool. It has an integrated capability for handling that type of task. At skilder, a Hat bundles role-specific skills, context and permissions, making this pattern operational at the enterprise level. ## Key takeaways **RAG is a retrieval mechanism.** It searches documents and returns content. Valuable for information access, but limited to that function. **Skills are packaged competencies.** They combine domain knowledge, process methodology, and execution capability into a unified ability to handle specific tasks. **They're complementary, not competing.** Most production agents need both. For teams building AI agents, the strategic question is not just "What information does the agent need?" but "What competencies does the agent need to do its job well?" The answer to that question shapes whether you end up with a chatbot or a capable assistant. --- Source: https://www.skilder.ai/en/blog/retrieval-is-the-new-intelligence # Retrieval Is the New Intelligence > As agents gain access to more tools, the bottleneck shifts from reasoning to retrieval. Why picking the right tool is the next frontier in AI agent design. Language: en · Category: engineering · Author: Nicolas Corod (Research) · Published: 2026-01-19 ## The smartest person with the wrong toolbox You hire a contractor to fix a leaky faucet. She shows up with 500 tools in her truck. She knows how to use every single one. But she grabs a saw instead of a wrench. The faucet doesn't get fixed. Not because she lacks skill. Because she picked the wrong tool. This is what happens inside AI agents every day. An AI agent takes your request, picks a tool from its available set, and runs it. When it works, it feels like magic. When it doesn't, the failure is specific: it grabbed the wrong tool. Or it didn't know the right one existed. The industry has spent years making models smarter. Better at reasoning, writing code, understanding language. But a quieter problem has grown in the background. As agents gain access to more tools, finding the right one becomes harder. There's a name for this problem: retrieval. ## What is retrieval? Retrieval is the process of finding and selecting the right tool for a given task. When you ask an AI assistant to "make me a presentation," the agent needs to figure out which tool handles slide decks. When you say "summarize this document," it reaches for a different tool. When you say "clean this up," it has to interpret what you mean and then match that interpretation to a specific capability. The AI doesn't return ten options for you to choose from. It picks one tool and runs it. If it picks wrong, you get a bad result and you might not understand why. This problem is gaining serious attention in the research community. Researchers at Stanford and Harvard recently published a [framework analyzing why agentic AI systems break down in practice](https://www.marktechpost.com/2025/12/24/this-ai-paper-from-stanford-and-harvard-explains-why-most-agentic-ai-systems-feel-impressive-in-demos-and-then-completely-fall-apart-in-real-use/), identifying tool retrieval as a core failure point. The [ToolBench project](https://github.com/OpenBMB/ToolBench), spotlighted at [ICLR 2024](https://iclr.cc/), built a benchmark of over 16,000 real-world APIs and found that even advanced models struggle with retrieval accuracy as tool catalogs grow. More recently, [MCP-Bench](https://arxiv.org/abs/2508.20453) tested agents across 250 tools and confirmed that retrieving the right tool from vague instructions remains one of the hardest unsolved challenges in AI agent design. ## Why it breaks down The most dangerous retrieval failure is the one you never see. The agent doesn't pick the wrong tool. It picks no tool at all, because it doesn't know the right one exists. You ask it to "check this contract for risky clauses." It has a specialized legal review tool, but the retrieval system doesn't surface it. So the agent uses a generic text tool instead. You get a mediocre answer and assume the AI isn't capable. In reality, the perfect tool was sitting unused in its toolbox. This is the invisible failure, and it erodes trust faster than any visible error. Behind this, several forces make retrieval hard. Every tool comes with a description. Think of it as a label on a jar. The agent reads these labels to decide which tool to grab. But labels are written by humans. Humans are inconsistent. One tool says "generate DOCX files." Another says "create professional documents." A third says "write formatted reports." All three do similar things with different words. The agent has to figure out that your request for "a polished memo" matches any of them. Scale compounds the problem. An agent with five tools makes decisions quickly. An agent with 200 tools faces overlap, ambiguity, and a flooded context window. Every tool description takes up processing space. Some systems show the agent only a subset of tools. But what if the right tool wasn't in the subset? Then there's the human side. People speak in ways that don't map neatly to tool descriptions. "Fix my data" could mean remove duplicates, correct formatting, fill gaps, or restructure the file. Each requires a different operation. The retrieval system bears the full weight of this translation gap between how people talk and how tools are labeled. ## The multi-tool puzzle All of the above applies to tasks that need a single tool. Many real tasks need several, working together in sequence. You want to read a PDF, extract a table, clean the data, and export it to a spreadsheet. That's four tools, one after another. The agent needs to plan the full chain before it starts. It needs to retrieve tools it hasn't used yet, for steps it hasn't taken yet. The common failure is that the agent completes step one and then struggles to find the right tool for step two. Each handoff is a new retrieval problem. Errors compound across steps. ## Where things are heading The industry is starting to take retrieval seriously. A few directions are forming. One approach is composable skills. Instead of treating each tool as standalone, systems allow tools to be combined like plugins. A "read PDF" skill connects to a "clean data" skill connects to an "export spreadsheet" skill. The agent doesn't retrieve each piece from scratch. It retrieves a composed workflow. Small, focused units that snap together based on what the task requires. Another direction is better organization through what some call a living know-how graph. Instead of a flat list of 200 tools, skills and tools are mapped into a structured, evolving graph of relationships. The graph captures which tools relate to each other, which ones compose well, which ones cover similar ground, and how they've performed in past tasks. "Living" is the key word: when a new skill is added, the graph incorporates it. When an existing tool underperforms or becomes redundant, the graph restructures itself. It learns from usage patterns and adapts over time. This is the infrastructure layer that most AI agent platforms are missing today. The model itself is the brain. The tools are the hands. Without a retrieval system that acts as an intelligent, evolving index, the brain keeps grabbing the wrong hands. A well-maintained know-how graph becomes the connective tissue between what the user needs and what the agent knows how to do. Platforms like [skilder](https://www.skilder.ai) are building this infrastructure: **a system where skills are structured, composable, and governed through a living graph that agents query in real time. The goal is to make retrieval a managed, scalable layer rather than an afterthought**. At skilder, those skills are bundled into Hats: role-specific assemblies of skills, context and permissions that an agent puts on for a given job. The next frontier in AI agents is not making them smarter. It is giving them the right infrastructure to find, compose, and deploy the right skills at the right time. **Retrieval is the new intelligence.** --- Source: https://www.skilder.ai/en/blog/skills-secret-weapon-smarter-ai-agents # Skills: The Secret Weapon for Smarter AI Agents > Agent Skills are modular instruction sets that extend AI capabilities for specific tasks. Anatomy of a SKILL.md, activation flow, and how to build your first one. Language: en · Category: product · Author: Nicolas Corod (Product) · Published: 2026-01-11 ## What are agent skills? Imagine giving your AI assistant a "cheat sheet" for specific tasks. That's essentially what an [Agent Skill](https://claude.ai/) is: a structured set of instructions that teaches an AI how to handle particular types of requests with expertise and consistency. Instead of hoping the AI figures out your preferred format for reports or remembers your company's coding standards, you encode these requirements into a skill. The agent reads this skill whenever relevant, ensuring every output matches your expectations. Think of it like hiring a specialist. A generalist might produce decent work, but a specialist with documented best practices delivers consistently excellent results. ## The anatomy of an agent skill Every skill follows a predictable structure. Here's what goes into the folder: ``` skill-folder/ ├── SKILL.md # Main instruction file ├── references/ # Supporting documentation │ ├── templates.md │ └── examples.md └── assets/ # Images, templates, samples └── template.docx ``` The `SKILL.md` file is the brain of the operation. It contains everything the agent needs to know. ## SKILL.md structure breakdown A well-crafted `SKILL.md` follows this format: ```markdown --- name: document-creator description: Creates professional documents following company standards --- # Document Creator Skill ## Context & Purpose When to use this skill and what problems it solves. ## Workflow Steps Step-by-step process the agent should follow. ## Rules & Constraints Hard limits, formatting requirements, things to avoid. ## Examples Sample inputs and expected outputs. ``` Each section serves a purpose: **Frontmatter (name + description):** Helps the agent identify when this skill applies. A clear description means better context matching. **Context & Purpose:** Explains the "why" behind the skill. When should the agent activate it? What outcomes matter? **Workflow Steps:** The procedural heart. Walk through each step the agent should take, in order. **Rules & Constraints:** Guardrails. What should the agent never do? What formatting is mandatory? **Examples:** Show, don't just tell. Concrete examples eliminate ambiguity. ## How agent skills get activated The activation flow is straightforward: 1. **User Request:** Someone asks the agent for something ("Create a quarterly report") 2. **Context Match:** The agent scans available skills and identifies relevant ones based on the description 3. **Agent Reads Skill:** Before acting, the agent reads the full `SKILL.md` file 4. **Execute Workflow:** The agent follows the documented steps to produce the output This happens automatically. Users don't need to explicitly call a skill; the matching happens based on context. ## Real-world use cases **Document Creation:** Define templates, formatting rules, and section requirements. Every report follows the same professional structure. **Code Generation:** Encode your team's style guide, naming conventions, and architectural patterns. No more inconsistent pull requests. **Content Writing:** Specify tone, structure, target audience, and SEO requirements. Maintain brand voice across all outputs. **Data Analysis:** Document your preferred visualization styles, statistical methods, and reporting formats. **Customer Support:** Create skills for common scenarios with approved responses and escalation criteria. ## Building your first skill Start simple. Pick one repetitive task where you find yourself giving the same instructions repeatedly. That's your first skill candidate. Here's a minimal working example: ```markdown --- name: meeting-notes description: Formats meeting notes with action items and decisions --- # Meeting Notes Skill ## Purpose Transform raw meeting transcripts into structured notes. ## Workflow 1. Extract key discussion points 2. Identify decisions made 3. List action items with owners and deadlines 4. Format using standard template ## Rules - Always include date and attendees - Action items must have an owner - Keep summary under 200 words ## Example Output ### Meeting: Q1 Planning **Date:** 2024-01-15 **Attendees:** Alice, Bob, Carol **Decisions:** - Budget approved for new tooling **Action Items:** - [ ] Alice: Submit vendor comparison by Jan 20 - [ ] Bob: Schedule demo with finalists by Jan 25 ``` ## What makes a skill effective The best skills share common traits: **Specificity over generality.** A skill for "writing emails" is too broad. A skill for "writing sales follow-up emails after demo calls" is actionable. **Clear boundaries.** Define what the skill does AND what it doesn't do. Ambiguity creates inconsistency. **Concrete examples.** Abstract instructions get interpreted differently. Examples establish ground truth. **Iterative refinement.** Your first version won't be perfect. Update skills based on output quality. ## Key takeaways Agent Skills transform generic AI assistants into specialized experts for your specific needs. They're simple to create, easy to maintain, and dramatically improve output consistency. The structure is standardized: a folder with `SKILL.md` at its core, plus optional references and assets. The agent automatically matches skills to requests based on context. At skilder, individual skills are bundled into Hats: role-shaped collections of skills, context and permissions an agent puts on for a given job. **Next step:** Identify one task you repeat weekly. Document the ideal process in a `SKILL.md` file. Watch your AI outputs become remarkably more consistent. --- Source: https://www.skilder.ai/fr/blog/skill-md-le-roi-du-shadow-ai # SKILL.md, le roi du Shadow AI > Pourquoi les Agent Skills, dans leur architecture actuelle, sont en train de devenir le plus grand accélérateur de Shadow AI en entreprise. Et comment y remédier. Language: fr · Category: governance · Author: Nicolas Corod · Published: 2026-07-29 ## Le concept des Agent Skills est génial Commençons par le dire clairement : les Agent Skills sont une excellente idée. Lancé par Anthropic fin 2025, le format est élégant : un dossier auto-contenu avec un fichier `SKILL.md` au format Markdown, du YAML frontmatter, et éventuellement des scripts ou des références. Quand un agent rencontre une tâche, il découvre les skills pertinents et charge uniquement les instructions nécessaires, ce qui maintient le contexte léger et adaptable. Le principe de *progressive disclosure* est particulièrement astucieux : seul le strict nécessaire est injecté dans la fenêtre de contexte au moment où c'est utile. C'est efficace, c'est modulaire, c'est lisible par un humain comme par une machine. La promesse est forte : encapsuler un savoir-faire métier de façon durable, plutôt que de le diluer dans des prompts éphémères. Bref, sur le plan technique, le format SKILL.md est une réussite. Mais voilà : ce qui fait sa force est aussi en train de faire sa fragilité. Pas le format lui-même, mais l'architecture organisationnelle dans laquelle il est déployé aujourd'hui. ## Le vrai problème : un format sans gouvernance Pour comprendre, il faut regarder où vivent réellement les skills dans la majorité des déploiements actuels : * Dans un dossier `skills/` sur le poste d'un développeur * Dans un dépôt GitHub personnel, parfois public * Dans `~/.claude/skills/`, partagés entre projets sans inventaire * Dans des marketplaces communautaires sans contrôle interne * Dans un dossier partagé Drive ou Notion, copié-collé entre collègues Autrement dit : chaque skill est créé, modifié, partagé et exécuté hors de tout cadre d'entreprise. Pendant ce temps, dans la même entreprise : * Le baromètre Privacy 2026 montre que 80 % des organisations n'ont pas de vision claire de leurs usages IA. * Le Cloud and Threat Report 2026 indique que 47 % des utilisateurs d'IA générative passent encore par des comptes personnels. * Selon les analyses sectorielles, 38 % des employés partagent des informations sensibles avec des plateformes d'IA sans validation. Le Shadow AI était déjà un problème majeur avec ChatGPT et Claude utilisés via comptes perso. Avec les Agent Skills, on entre dans une nouvelle dimension : ce n'est plus seulement de la donnée qui sort, c'est du savoir-faire métier qui est encapsulé, versionné, partagé, et totalement invisible pour la DSI. ## Pourquoi le format SKILL.md aggrave le Shadow AI ### 1. Le couplage fort avec le LLM ou l'agent Un skill, dans son architecture actuelle, est collé à son moteur d'exécution. Un skill Anthropic est conçu pour Claude. Un skill OpenAI est conçu pour GPT. Un skill Copilot Studio vit dans l'écosystème Microsoft. Conséquence pratique : pour utiliser un skill, il faut adopter (et souvent payer) le LLM correspondant. Chaque équipe métier qui découvre une bibliothèque de skills intéressante embarque avec elle un nouveau fournisseur, un nouveau modèle économique, un nouveau contrat de traitement de données. La DSI découvre l'engagement après coup. C'est le scénario classique du Shadow IT, mais avec un facteur multiplicateur : un skill n'est pas un outil isolé, c'est un bloc de capacité métier qui crée immédiatement de la dépendance opérationnelle. ### 2. Aucune notion d'organisation Un skill ne sait pas à quelle entreprise il appartient, à quel département, à quelle fonction. Il n'a pas de propriétaire identifié, pas de consommateur déclaré, pas d'unité organisationnelle de rattachement. Résultat : * **Pas de cartographie possible** : impossible de répondre à la question « combien de skills tournent dans mon entreprise ? » * **Pas de mutualisation** : trois équipes peuvent créer trois skills quasi-identiques pour la même tâche. * **Pas de cycle de vie** : qui maintient un skill quand son auteur quitte l'entreprise ? * **Pas d'audit** : impossible de produire la liste des systèmes IA déployés exigée par l'AI Act. L'article 4 de l'AI Act européen impose une « culture suffisante en matière d'IA » à l'ensemble des collaborateurs exposés à ces outils. Difficile à appliquer quand vous ne savez même pas quels skills sont en circulation. ### 3. Pas de permissions, pas de propriété, pas de traçabilité Un fichier `SKILL.md` ne porte aucune notion de : * Qui peut le créer. * Qui peut le consommer. * Qui est responsable de sa qualité et de sa conformité. * Quels usages doivent être journalisés. C'est un format de partage, pas un format de gouvernance. Et c'est précisément ce qui en fait, paradoxalement, le format idéal pour le Shadow AI : facile à créer, facile à distribuer, impossible à tracer à l'échelle de l'entreprise. ### 4. La duplication et la dérive Sans catalogue centralisé, le savoir-faire métier se dilue dans une infinité de copies divergentes. Le skill « génération de rapport client » existe en sept versions, chacune avec sa propre interprétation des règles, ses propres données d'entreprise codées en dur, ses propres bugs. Lorsque l'audit RGPD arrive, lorsque l'AI Act demande de documenter le système d'IA utilisé pour une décision automatisée, lorsqu'un client demande à exercer son droit à l'effacement, personne n'est capable de répondre. ## Ce n'est pas un bug, c'est une couche manquante Il faut être juste avec Anthropic : le format SKILL.md n'a jamais prétendu être une plateforme de gouvernance. C'en est un excellent, mais ce n'est qu'un format. Le problème, c'est qu'aucune couche d'organisation ne vient s'ajouter au-dessus, et que la communauté traite ce vide comme s'il n'existait pas. Le parallèle est instructif. Le code source ne se gouverne pas tout seul : il a fallu inventer Git, puis GitHub, puis les revues de pull request, puis les pipelines CI/CD, puis les politiques de branche. La donnée ne se gouverne pas toute seule : il a fallu inventer les data catalogs, les data contracts, les data products. Les skills aussi ont besoin de leur couche d'orchestration. ## Une piste : capturer les initiatives avec un framework comme skilder C'est précisément l'angle d'approche d'un framework comme skilder. L'idée n'est pas de remplacer le format SKILL.md (qui reste excellent), mais d'ajouter par-dessus une couche d'organisation, de propriété et de coordination. ### Le concept clé : le Rôle Un **Rôle** est une collection de skills nommée et thématique, qui correspond à une fonction ou une persona identifiée dans l'entreprise. Au lieu de laisser flotter les skills en vrac, on les regroupe par usage métier : * Un Rôle « Pre-Sales » réunit les skills utiles pour gérer les objections, mobiliser la veille concurrentielle, accompagner un prospect dans le cycle de vente. * Un Rôle « Legal Assistant » réunit les skills d'analyse de contrats, de veille réglementaire, de rédaction d'avenants. * Un Rôle « DevOps » réunit les skills de déploiement, de monitoring, de réponse incident. Quand un collaborateur (ou un agent) endosse le Rôle « Pre-Sales », il accède d'un coup à l'ensemble cohérent des capacités validées pour cette fonction. Ni plus, ni moins. ### Pourquoi ça change tout Ce mécanisme apparemment simple résout plusieurs problèmes structurels du Shadow AI : 1. **Il capture les initiatives plutôt que de les interdire.** Un commercial qui a bricolé son propre skill peut le proposer à l'intégration dans le Rôle « Sales ». L'initiative individuelle devient un actif d'entreprise au lieu de rester dans l'ombre. 2. **Il rend la cartographie triviale.** La question « quels skills tournent dans mon entreprise ? » devient simplement « quels Rôles avons-nous, et quels skills y a-t-il dedans ? ». Le catalogue est centralisé, versionné, audité. 3. **Il introduit une propriété explicite.** Chaque skill a un propriétaire et des consommateurs déclarés. La maintenance, la qualité, la conformité ont un nom et un visage. 4. **Il découple le savoir-faire du moteur d'exécution.** Avec une approche compatible MCP, le même skill peut être consommé par Claude, par Copilot, par un agent maison, sans réécriture. Fini le vendor lock-in implicite. 5. **Il rend la sélection de contexte intelligente.** Au lieu de charger toute la bibliothèque dans la fenêtre de contexte, l'agent ne charge que les skills du Rôle actif. Économie de tokens, baisse des hallucinations, performances accrues. 6. **Il offre une alternative crédible au Shadow AI.** Le problème central du Shadow AI n'est pas que les collaborateurs sont mal intentionnés. C'est qu'ils ont besoin de productivité et que les outils officiels arrivent trop tard. Donner aux équipes une plateforme où elles peuvent créer, partager et consommer des skills validés, dans le cadre de l'entreprise, c'est offrir la fluidité du shadow avec les garanties de l'officiel. ### L'architecture conceptuelle L'idée tient en quelques lignes : ``` Workspace (frontière entreprise) └── Rôles (fonctions / personas métier) └── Skills (unités de capacité, compatibles SKILL.md) ├── Instructions ├── Outils MCP (agnostiques au LLM) ├── Références (documents markdown) └── Scripts (Python, exécutés en sandbox) ``` Le format SKILL.md est préservé. Un skill Anthropic standard peut être importé tel quel. Mais il est désormais rattaché à un workspace, organisé en Rôles, exposé via un protocole agent-agnostique (MCP), tracé, versionné, et soumis à des permissions explicites. ## Ce que ça implique pour les DSI et les responsables IA Si vous portez aujourd'hui un sujet de gouvernance IA en entreprise, voici la question concrète à se poser : pouvez-vous, ce matin, lister tous les fichiers `SKILL.md` qui circulent dans votre organisation ? Si la réponse est non (et statistiquement elle l'est dans 80 % des cas), alors il ne suffit plus de produire une charte ou d'interdire ChatGPT. La couche manquante est structurelle : 1. **Cartographier l'existant.** Les skills déjà créés dans les dépôts Git, les `~/.claude/`, les marketplaces. C'est l'équivalent IA du registre des traitements RGPD. 2. **Centraliser la création.** Un seul endroit où on déclare, versionne et publie un skill, avec un propriétaire et un consommateur identifiés. 3. **Structurer par Rôle, pas par technologie.** Penser Rôles avant de penser modèles. Un commercial n'a pas besoin de savoir s'il utilise Claude ou GPT. Il a besoin du Rôle « Sales ». 4. **Découpler du LLM.** Choisir une couche d'abstraction (MCP est aujourd'hui le standard de fait) qui permet de changer de modèle sans réécrire les skills. 5. **Officialiser la création de skills internes.** Le Shadow AI prospère quand le canal officiel est plus lent que le canal sauvage. Si créer un skill validé prend 48 heures avec un propriétaire identifié, plus personne n'ira en bricoler un dans son coin. ## Conclusion Le format SKILL.md n'est pas le problème. C'est même probablement l'un des meilleurs formats d'encapsulation de savoir-faire IA qu'on ait vus émerger ces deux dernières années. Mais un format n'est pas une plateforme. Et tant que l'écosystème continuera à traiter les skills comme on traitait les scripts shell en 2005 (partagés à la main, sans propriétaire, sans catalogue, sans cycle de vie), alors le standard SKILL.md restera, malgré lui, le roi du Shadow AI : le format le plus pratique, le plus partageable et le plus invisible que les entreprises aient jamais laissé entrer dans leurs systèmes. La bonne nouvelle, c'est que la solution n'est pas de remplacer le format. C'est d'ajouter au-dessus la couche d'organisation qui lui manque. Des Rôles pour structurer les usages métier. Un workspace pour délimiter l'entreprise. Une compatibilité MCP pour éviter le vendor lock-in. Un catalogue pour rendre visible ce qui circule. Le Shadow AI n'est pas un signal qu'il faut interdire l'IA. C'est un signal qu'il faut lui donner enfin un cadre où elle peut s'épanouir sans se cacher. --- *Vous voulez cartographier les skills déjà en circulation dans votre organisation, ou structurer leur adoption autour de rôles métier clairs ? C'est exactement le problème que skilder résout.* --- Source: https://www.skilder.ai/fr/blog/skilder-obtient-une-bourse-digital-grant-de-20000-chf-de-la-fit # Skilder obtient une bourse Digital Grant de 20'000 CHF de la FIT > Skilder s'est vu octroyer une bourse Digital Grant de 20'000 CHF par la Fondation pour l'innovation et la technologie (FIT), la fondation vaudoise qui soutient les jeunes entreprises innovantes du canton. Language: fr · Category: governance · Author: L'équipe skilder · Published: 2026-06-23 Cette bourse a été annoncée en même temps que le soutien à deux autres start-up vaudoises : Isospec Analytics, spin-off de l'EPFL spécialisée dans l'identification de molécules biologiques pour la recherche médicale, qui reçoit un prêt Tech Growth de 400'000 CHF, et MYSTONES, qui obtient également une bourse Digital Grant de 20'000 CHF pour sa plateforme de suivi des athlètes. ## Le problème que Skilder adresse Dans la plupart des entreprises, chaque employé utilise les outils d'intelligence artificielle à sa façon. Les méthodes de travail, les règles et les bonnes pratiques restent dans les échanges individuels, sans jamais être partagées à l'échelle de l'organisation. Skilder propose une plateforme qui permet aux équipes de centraliser ces méthodes de travail et de les rendre accessibles à l'ensemble des outils d'IA utilisés dans l'entreprise, sans compétences techniques et sans changer les outils déjà en place. ## Ce que la bourse va financer Avec la bourse Digital Grant de 20'000 CHF octroyée par la FIT, Skilder pourra affiner sa plateforme avec ses premiers clients et développer sa présence sur le marché. Concrètement, cela signifie approfondir le travail avec les équipes qui utilisent déjà Skilder, resserrer le produit autour de ce qui fonctionne réellement au quotidien, et aller à la rencontre d'un plus grand nombre d'entreprises confrontées à la même dispersion de leurs pratiques d'IA. ## À propos de la FIT La Fondation pour l'innovation et la technologie (FIT) soutient les start-up innovantes du canton de Vaud à travers des bourses et des prêts couvrant plusieurs étapes de croissance, de la bourse Digital Grant et du prêt Tech Seed jusqu'au financement Tech Growth. Être sélectionné constitue un signal fort pour une jeune entreprise : cela suppose l'examen d'un jury d'experts et ouvre l'accès à l'écosystème d'innovation vaudois. ## Lire le communiqué Le communiqué complet de la FIT est disponible ici : [Isospec Analytics, MYSTONES et Skilder : trois start-up vaudoises soutenues par la FIT](https://www.fondation-fit.ch/fr/general/actualites/2026/isospec-analytics-mystones-et-skilder-trois-start-up-vaudoises-soutenues-par-la-fit) --- Source: https://www.skilder.ai/fr/blog/shadow-ai # Qu'est-ce que le shadow AI ? > Le shadow AI désigne l'usage non encadré d'outils d'IA générative par les employés. Définition, risques concrets, et comment y répondre sans casser la productivité. Language: fr · Category: governance · Author: Nicolas Corod (Fondateur & CEO) · Published: 2026-05-20 ## TL;DR Le **shadow AI** désigne l'usage d'outils d'IA générative grand public (ChatGPT, Claude, Gemini, Copilot personnel…) par les collaborateurs **sans cadre, sans audit, et souvent sans validation IT/sécurité**. C'est l'équivalent moderne du shadow IT, et le problème grossit vite : selon plusieurs études, **plus de 70 % des employés utilisent déjà une IA générative au travail**, et la majorité le fait avec leur compte personnel. ## Pourquoi le shadow AI est un problème ### 1. Fuites de données silencieuses Quand un collaborateur colle un brouillon de contrat, une base clients ou un extrait de code dans un chatbot grand public, ces données peuvent : - Être stockées par le fournisseur (politiques variables, souvent obscures). - Servir à entraîner des modèles futurs. - Sortir de l'UE (transfert hors RGPD). ### 2. Aucun audit, aucune politique Vous ne savez pas : - Qui utilise quoi. - Sur quels documents. - Avec quels prompts. En cas de contrôle CNIL ou d'incident, vous n'avez rien à montrer. ### 3. Valeur perdue Les usages restent **individuels**. Personne ne capitalise. Les prompts qui marchent se perdent dans les onglets. Les bons réflexes ne se diffusent pas. ## La fausse bonne réponse : interdire Interdire ne marche pas. L'IA générative est trop utile pour qu'on l'abandonne. Si vous interdisez, vos équipes : - Continueront sur leur téléphone perso. - Utiliseront des comptes anonymes. - Vous mentiront poliment. ## La vraie réponse : offrir une alternative gouvernée C'est exactement la raison d'être de [skilder](/fr) : donner à chaque collaborateur un assistant IA **aussi puissant que ChatGPT, mais sous contrôle**. - Les données restent dans l'UE. - Chaque interaction est journalisée. - L'usage individuel devient capital collectif (via les **casquettes** réutilisables). ## À retenir > Le shadow AI n'est pas un problème d'employés indisciplinés. C'est un problème d'offre interne. Tant que vos équipes n'ont pas mieux, elles utiliseront ChatGPT. Pour aller plus loin, voyez [la plateforme skilder](https://docs.skilder.ai). --- Source: https://www.skilder.ai/fr/blog/savoir-vs-savoir-faire # Savoir vs savoir-faire : la distinction qui tue silencieusement vos agents IA > 95 % des pilotes IA en entreprise échouent non parce que les modèles sont faibles, mais parce qu'on les charge de savoir et qu'on leur demande du savoir-faire. Deux catégories différentes. Language: fr · Category: governance · Author: Nicolas Corod (Stratégie) · Published: 2026-05-15 Si 95 % des pilotes IA en entreprise échouent, ce n'est pas un problème de modèle. C'est une erreur de catégorie. ## L'écart que personne ne nomme. La plupart des conversations sur l'IA en entreprise tournent autour d'un seul mot : **le savoir**. On parle de bases de connaissances, de graphes de connaissances, de récupération, de [RAG](https://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9ration_augment%C3%A9e_par_r%C3%A9cup%C3%A9ration), de fine-tuning sur données propriétaires. L'hypothèse implicite : si un agent IA *sait* assez de choses sur votre métier, il *fera* la bonne chose. Faux. Et la raison tient à une distinction que les philosophes posent depuis des décennies, mais que l'industrie de l'IA continue d'ignorer. Il existe deux façons de savoir : - **Le savoir-que** : la connaissance propositionnelle. Des faits, des politiques, de la documentation, des données. Paris est la capitale de la France. Notre politique de remboursement autorise les retours sous 30 jours. La facture n° 4521 est en retard. - **Le savoir-faire** : la connaissance procédurale. La capacité à exécuter correctement une tâche en contexte. Faire du vélo. Conclure une vente. Traiter cette facture en retard comme *cette entreprise précise* attend qu'on la traite. Gilbert Ryle a posé cette distinction comme l'opposition entre *knowing that* (la connaissance propositionnelle) et *knowing how* (la connaissance procédurale). Michael Polanyi désignait la seconde par « connaissance tacite » : ce qu'un expert sait sans pouvoir l'écrire entièrement. Peu importe le nom. Le point est le suivant : **connaître les faits d'un métier n'est pas la même chose que savoir l'exercer.** Et aujourd'hui, la plupart des investissements IA en entreprise achètent le premier en espérant le second. ## Pourquoi cela compte spécifiquement pour les agents. Pour les chatbots, l'écart entre savoir et savoir-faire restait tolérable. Un chatbot qui connaît vos politiques sans savoir les *appliquer* reste utile : un humain lit la réponse et décide quoi faire. Les agents changent l'équation. Un agent ne répond plus à des questions, il passe à l'action. Il envoie l'e-mail, met à jour le CRM, valide la note de frais, ouvre le ticket. L'écart entre *savoir* et *faire* cesse d'être philosophique : il devient opérationnel. Un agent riche en savoir mais pauvre en savoir-faire, c'est un collaborateur sûr de lui qui a lu le manuel sans jamais avoir fait le job. Ce n'est pas un actif. C'est une responsabilité avec un accès API. C'est, empiriquement, ce qui se passe. [L'étude MIT NANDA 2025](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) montre que 95 % des pilotes IA en entreprise n'ont aucun impact P&L mesurable. [S&P Global rapporte](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results) que 42 % des entreprises ont abandonné la plupart de leurs initiatives IA en 2025, contre 17 % l'année précédente. L'explication standard, c'est « le contexte ». Mais « contexte » est un mot vague qui masque le vrai sujet. Le contexte manquant, ce n'est pas davantage de documents à récupérer. C'est le **savoir-faire procédural, tacite et institutionnel** qui dit à un agent *comment cette entreprise exécute réellement cette tâche*. ## À quoi ressemble le savoir-faire en pratique. Prenons un exemple concret. Un chef de projet prépare son brief hebdomadaire au comité de direction. Les documents existent. Un LLM peut les lire. Un système basé sur le savoir peut les récupérer à la demande. Mais le travail réel exige un savoir-faire que les documents ne contiennent pas : - Ce qui compte comme « décision clé » pour *ce* comité (pas la définition du manuel) - Qui a le pouvoir de signature sur quoi, et les exceptions non écrites - Comment formuler une alerte risque pour que le directeur financier la prenne au sérieux sans déclencher un branle-bas de combat - Quels interlocuteurs reçoivent un pré-brief avant la réunion, et lesquels reçoivent la synthèse après - Les conventions de format qui se sont décantées sur dix-huit mois de retours Rien de tout cela n'est dans un document. C'est dans la tête du chef de projet. C'est dans le motif des briefs passés. C'est dans le ton du fil Slack du trimestre dernier. C'est **la façon dont le travail se fait réellement ici**, et c'est précisément la couche à laquelle les agents IA génériques, quelle que soit la puissance du modèle sous-jacent, ne peuvent pas accéder. ## L'erreur de catégorie que commettent les dirigeants. Quand les initiatives IA s'enlisent, le réflexe est en général d'acheter plus de la même catégorie. Plus de documents indexés. Une meilleure récupération. Un modèle plus gros. Un pipeline RAG plus sophistiqué. Parfois, du fine-tuning entre 10 000 et 35 000 dollars par modèle, plus des data scientists sur un marché du talent tendu. Rationnel si le problème est le savoir. Mauvaise prescription si le problème est le savoir-faire. Le savoir-faire ne vit pas dans les documents. Il vit dans **les procédures, les contraintes, les exceptions, les arbitrages et les conventions propres à chaque rôle**. Et il ne se généralise pas : la façon dont votre équipe conformité gère une exception n'est pas la façon dont votre équipe sales ops gère une exception, même au sein de la même entreprise. Empaqueter du savoir-faire, c'est encoder non seulement *quoi* faire, mais *comment cette équipe, dans ce rôle, sous ces contraintes, veut que ce soit fait*. C'est un autre type d'actif qu'une base de connaissances. Il doit être : - **Procédural** : décrire une séquence et ses exceptions, pas seulement des faits - **Lié au rôle** : rattaché à qui fait le travail, pas seulement à ce qui est fait - **Composable** : pour qu'un même savoir-faire soit réutilisé entre agents et contextes - **Auditable** : pour que, lorsque l'agent agit, on puisse remonter du raisonnement jusqu'à l'instruction ## Pourquoi c'est le point de départ de skilder. Nous ne pensons pas que la stack IA actuelle soit cassée. Nous pensons qu'elle est incomplète. Les modèles sont devenus extraordinairement capables. Les standards d'appel d'outils comme MCP ont rendu la connectivité tractable. Ce qui manque, c'est la couche entre les deux : celle qui transforme une capacité générique en *la manière dont cette entreprise travaille*. C'est ce que nous construisons. Nous empaquetons le savoir-faire dans ce que nous appelons des **casquettes** : des bundles par rôle qui capturent comment un poste précis s'exécute dans une organisation précise. Un agent enfile une casquette comme un nouvel arrivant prend ses fonctions : il hérite des procédures, des contraintes, des exceptions et des arbitrages qui définissent le travail compétent à ce poste. Un agent peut porter plusieurs casquettes et passer d'un contexte à l'autre. Une casquette peut être portée par plusieurs agents, pour que le savoir-faire se cumule au lieu de se fragmenter. Et comme les casquettes sont découplées de tout modèle particulier, le même savoir-faire fonctionne sur Claude, GPT, Gemini, ou ceux qui suivront. Le basculement, vu d'avion, est le suivant : les entreprises ont passé trois ans à acheter du savoir pour leur IA. Elles passeront les trois prochaines à lui apprendre à travailler. ## À retenir. Si vos pilotes IA s'enlisent, la bonne question de diagnostic n'est pas « *notre agent a-t-il accès à assez d'informations ?* ». C'est « *notre agent sait-il comment nous faisons réellement ce travail ?* ». Le savoir vous donne un stagiaire bien lu. Le savoir-faire vous donne un collaborateur formé. La différence, en production, est celle qui sépare une démo d'un déploiement. --- Source: https://www.skilder.ai/fr/blog/du-context-bloat-au-context-load # Du context bloat au context load. > Pourquoi votre IA d'entreprise s'alourdit à mesure qu'elle gagne en capacités, et comment un graphe de capabilities permet d'assembler le context comme un payload runtime plutôt qu'un fichier de config statique. Language: fr · Category: engineering · Author: Nicolas Corod (Ingénierie) · Published: 2026-05-05 *Pourquoi votre IA d'entreprise s'alourdit à mesure qu'elle gagne en capacités, et comment corriger le problème structurellement.* **TL;DR :** votre agent ne devient pas plus bête. Votre contexte devient plus lourd. --- ## Votre agent était excellent en v1. Puis sont arrivés le deuxième tool, le troisième garde-fou, le quatrième script de workflow. Chaque ajout avait du sens sur le moment. Personne n'a rien retiré. Arrivé en v3, votre agent traîne **8 000+ tokens de contexte avant même que l'utilisateur n'ait dit un mot**. Il ignore des instructions, coûte plus cher, et répond plus lentement. Le réflexe est d'incriminer le modèle. Mais le modèle n'a pas changé. Ce qui a changé, c'est le contexte. > **Le paradoxe des capabilities :** plus vous ajoutez à votre agent, moins il performe de manière fiable. Ce n'est pas un problème de modèle. C'est un problème d'architecture du contexte. --- ## Trois couches qui grossissent sans limite. Les agents d'entreprise transportent trois types de contenu, chacun raisonnable isolément, collectivement toxiques sans gouvernance : **Tools :** schémas d'API, définitions de fonctions. Un seul tool avec ses paramètres et exemples peut peser 200 à 400 tokens. 15 tools : jusqu'à 6 000 tokens avant le premier mot. **Skills :** instructions comportementales, règles de conformité, lignes de conduite de persona. Écrits une fois, jamais élagués. Ils accumulent les amendements comme un contrat juridique. **Scripts :** échafaudages de chain-of-thought, arbres de décision. Verbeux par construction. Un script de triage peut consommer 2 000+ tokens, dont l'essentiel est inutile à un appel donné. > À 3 $/M de tokens, 10 000 conversations par jour, 6 tours chacune : **environ 1 500 $/jour** rien qu'en coût de contexte système, avant même que la conversation ne démarre. --- ## Le bloat fait mal de quatre façons distinctes. | | | | ------ | -------------------------------------------------------------- | | ~2× | plus d'échecs de suivi d'instructions quand le context grossit | | 18-24 %| de latence en plus en passant de 1 400 à 8 400 tokens | | 440 K $| de surcoût annuel à 10 000 conversations/jour | *Issu de nos propres déploiements sur 3 pilotes entreprise (novembre 2024 à février 2025). Signal directionnel, pas un benchmark industriel. Les observations sur la latence rejoignent les [travaux d'Anthropic sur le context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), qui montrent que la précision du modèle décroît à mesure que la fenêtre de contexte se remplit.* Au-delà du coût et de la latence : le modèle se met à faire des arbitrages silencieux entre instructions (lesquelles suivre, lesquelles ignorer partiellement) d'une façon que personne ne peut prédire ni expliquer. Nous l'avons observé comme une hausse constante des escalades et des flags de revue de sortie dès que les system prompts dépassaient 6 000 tokens. > **Sur l'élargissement des fenêtres de contexte :** passer à un modèle avec une fenêtre de 500 K tokens ne corrige pas le bloat. Cela le rend simplement plus cher. Des fenêtres plus grandes relèvent le plafond. Elles ne corrigent pas le problème de discipline sur ce qui doit réellement être chargé. --- ## Arrêtez de déverser. Commencez à charger. La plupart des équipes traitent la fenêtre de contexte comme un fichier de configuration : on la remplit de tout ce dont l'agent pourrait avoir besoin et on la laisse statique. C'est l'état d'esprit du bloat. L'alternative : traiter le contexte comme un **payload runtime**. Assemblé à neuf à chaque appel. Contenant uniquement ce dont cet agent, traitant cette tâche, à ce tour, a réellement besoin. > **Le principe du load :** chaque token de votre contexte doit pouvoir répondre à la question : *pourquoi est-il ici, pour cet appel précis, maintenant ?* Si la réponse est « ça pourrait servir », ce token est probablement du bloat. --- ## Découplez les capabilities des agents. Patcher chaque agent individuellement ne passe pas à l'échelle. Dès que vous avez 6, 10, 15 agents, vous avez **n agents qui résolvent indépendamment le même problème de contexte**, sans gouvernance partagée, sans versioning partagé, avec des jours de décalage à chaque changement d'un tool ou d'une règle de conformité. La réponse structurelle : **les agents ne devraient pas posséder leurs capabilities**. Les tools, skills et scripts doivent être définis centralement, versionnés indépendamment, et assemblés dans le contexte dynamiquement au runtime selon le rôle et la tâche. En pratique, cela donne un graphe de capabilities : les nœuds sont des tools, skills et scripts, les arêtes définissent leurs relations. Un agent déclare un rôle. Un moteur de résolution traverse le graphe et charge exactement le bon bundle pour cet appel. > **Avant :** 12 tools + 6 blocs de skills + 2 scripts = 8 400 tokens par appel. > > **Après :** 3 tools + 1 bloc de skill + 1 script = 2 000 tokens par appel. Une réduction de 76 %, cohérente avec notre première migration pilote. --- ## Le paysage des modèles tire dans les deux sens. **Modèles frontier :** les fenêtres de contexte continuent de grossir, mais les coûts par token aussi. Un prompt boursouflé de 8 400 tokens sur un modèle frontier premium ne corrige pas le bloat. Il le fait tourner sur une infrastructure plus chère. **Small language models :** les SLMs (Phi-4, Mistral Small, Llama 3.2) montent vite pour les déploiements on-premise, sensibles au coût ou contraints par la souveraineté des données. Leurs limites de 4 K à 32 K tokens rendent l'architecture des capabilities non plus optionnelle, mais obligatoire. Le graphe de capabilities est une **couche d'abstraction indépendante du modèle**. Il se moque de savoir si le modèle sous-jacent dispose de 8 K ou de 800 K tokens. Il assemble le bon payload et le passe à n'importe quel modèle que le déploiement exige : la même architecture pour un SLM on-premise dans une banque régulée et un modèle frontier traitant des workflows entreprise complexes. --- ## Six questions pour auditer la santé de votre contexte. - **Ratio d'injection :** quelle proportion de votre system prompt est injectée à chaque appel vs conditionnellement ? Surtout systématique : risque de bloat. - **Utilisation des tools :** quelle part de vos tools enregistrés est réellement appelée ? Sous 40 % : c'est du tool sprawl. - **Âge des instructions :** quand avez-vous revu chaque bloc pour la dernière fois ? Tout ce qui n'a pas bougé depuis plus de 90 jours contient probablement de la redondance ou des contradictions. - **Cadence de retrait :** quand avez-vous retiré quelque chose pour la dernière fois ? Une équipe qui n'ajoute qu'accumule par définition. - **Propriété des capabilities :** si l'API d'un tool change, combien de définitions d'agents faut-il mettre à jour ? Au-delà de trois, vous avez un problème de gouvernance. - **Observabilité du contexte :** pouvez-vous voir le payload exact envoyé à chaque appel en production ? Sinon, vous ne pouvez ni auditer, ni optimiser, ni gouverner. > Un rôle d'agent bien cadré devrait transporter **2 000 à 3 500 tokens** de contexte système pour une tâche focalisée. Sur les agents que nous avons audités avant migration, la médiane était à 7 800 tokens. --- *Le context bloat est le symptôme d'un contexte traité comme un fichier de configuration. Le context load, c'est ce qui se passe quand vous le traitez comme de l'ingénierie.* --- Source: https://www.skilder.ai/fr/blog/context-lake # Le context lake : pourquoi votre data lake ne suffit pas pour les agents IA > Une nouvelle couche apparaît dans la stack agentique : le context lake. Sens métier, permissions d'outils et gouvernance ont besoin de leur propre maison. Language: fr · Category: governance · Author: Nicolas Corod (Stratégie) · Published: 2026-04-20 Une nouvelle expression circule sur les pages produit, les notes d'analystes et les schémas d'architecture : **context lake**. Port l'utilise pour décrire une couche de connaissance d'ingénierie. Tacnode en construit une version temps réel. Forrester a publié plus tôt cette année un papier expliquant pourquoi le sujet compte pour l'IA agentique. Un article arXiv l'a formalisé comme classe de système. Le terme converge, depuis des angles différents et avec des accents différents, vers la même intuition : l'infrastructure de données pensée pour l'ère analytique n'est pas celle dont l'ère agentique a besoin. La thèse à défendre : le context lake sera aussi fondateur pour l'entreprise agentique que le data lake l'a été pour l'entreprise analytique, et les acteurs qui le comprennent tôt tiendront un avantage structurel difficile à copier. ## Le data lake répond à « ce qui s'est passé ». Le context lake répond à « ce que je dois faire ». Depuis le milieu des années 2010, le data lake est le centre de gravité de la stratégie data en entreprise. Tout déverser dedans, formuler les questions plus tard, laisser les analystes et les modèles s'en sortir. Cela a fonctionné, à peu près, pour les dashboards, la BI et la première vague de machine learning. Cela a même fonctionné aux premiers jours de l'IA générative, quand « branchez vos documents sur une vector DB » passait pour une réponse complète. Ce n'en est plus une. Et la raison est simple : ce qu'on construit aujourd'hui au-dessus de la donnée d'entreprise est d'une nature radicalement différente d'un dashboard ou d'un modèle. C'est un agent. Et les agents n'ont pas besoin de données. Ils ont besoin de **contexte**. Un data lake est un réservoir passif. Il stocke des faits (transactions, logs, documents, événements) et attend qu'un humain ou une machine vienne poser une question. Sa valeur se mesure en volume, en fraîcheur et en performance des requêtes. Ses consommateurs sont des humains équipés de SQL, d'outils BI et de pipelines ML. Son modèle de gouvernance suppose un nombre relativement restreint d'utilisateurs avertis qui savent ce qu'ils cherchent. Un agent IA est un consommateur d'une tout autre nature. Il n'arrive pas avec une requête pré-écrite. Il arrive avec un objectif (« résolvez cette réclamation client », « clôturez les comptes du T3 », « négociez ce renouvellement ») et il doit déterminer, en cours de route, ce qu'il a besoin de savoir, quels outils il a le droit d'utiliser, quelles règles encadrent sa décision, et ce que « terminé » signifie réellement dans votre entreprise. Aucun volume de fichiers Parquet bien rangés ne lui dira rien de tout cela. Cette couche manquante (la logique métier, les permissions d'outils, les politiques, la connaissance institutionnelle sur la façon dont *votre* entreprise opère réellement) est ce que tient un context lake. C'est la différence entre confier à quelqu'un la Bibliothèque du Congrès et lui remettre le livret d'accueil de son poste. ## Ce qui vit réellement dans un context lake Les premières définitions qui émergent sur le marché insistent chacune sur une facette. Port se concentre sur l'ingénierie et l'ownership des services. Tacnode met l'accent sur la fraîcheur temps réel et la cohérence au moment de la décision. Tous les deux ont raison sur leur portion. Mais le tableau complet, à mon sens, est plus large. Trois éléments, et aucun ne vit proprement dans un système que vous possédez déjà. **Le sens métier.** C'est la couche sémantique dont un agent a besoin pour agir intelligemment en votre nom. Que veut dire « client actif » chez vous : quelqu'un qui s'est connecté ce mois-ci, ou quelqu'un dont le contrat est en cours ? Quels SKU sont arrêtés mais encore maintenus ? Quels comptes sont stratégiques et exigent un humain dans la boucle ? Cette connaissance existe aujourd'hui, mais elle est dispersée entre les pages Confluence, les threads Slack, la tête des collaborateurs séniors et la mémoire orale. Un data lake détient les transactions ; il ne détient pas la signification. **Les outils et les capacités.** La puissance d'un agent vient de sa capacité à *faire des choses* : appeler des API, écrire dans des systèmes de référence, envoyer des communications, déplacer de l'argent. Un context lake catalogue quels outils existent, ce qu'ils font, quand les mobiliser et, surtout, sous quelles conditions chaque agent a le droit de les utiliser. Ce n'est pas la même chose qu'un API gateway. Un API gateway demande « cette requête est-elle authentifiée ? ». Un context lake demande « est-ce le type de décision que cet agent devrait prendre maintenant, pour ce client, pour ce montant, sans escalade ? ». **La gouvernance et la politique.** Chaque industrie régulée a ses règles : ce qui peut être automatisé et ce qui ne peut pas, ce qui doit être journalisé, ce qui exige une revue humaine, ce qui ne doit jamais quitter une juridiction donnée. Dans un monde de logiciel déterministe, ces règles s'incrustent dans le code applicatif. Dans un monde d'agents probabilistes qui raisonnent sur du langage naturel, les règles elles-mêmes doivent devenir des artefacts de premier rang : interrogeables et auditables. Le context lake est l'endroit où la politique devient exécutable, pas comme des `if` enfouis, mais comme une couche gouvernée que l'agent consulte avant d'agir. Le point intéressant sur ces trois éléments, c'est qu'aucune entreprise ne les détient au même endroit aujourd'hui. La sémantique métier vit dans la tête des gens et dans des docs éparpillées. Les permissions d'outils vivent dans les API gateways et les politiques IAM. La gouvernance vit dans des PDF juridiques et des tableurs de conformité. Le travail du context lake consiste à rendre les trois lisibles, interrogeables et gouvernés dans une couche unique. ## Pourquoi cela doit être une nouvelle couche, pas une option d'un produit existant L'objection évidente arrive vite : ne peut-on pas tout poser dans le data lake ? Ou dans la vector DB ? Ou dans le framework d'agent ? Beaucoup essaient. Voici pourquoi cela ne tient pas. Le data lake est optimisé pour le volume et les requêtes analytiques, pas pour les lookups basse latence et haute précision dont un agent a besoin en cours de décision. Les vector DB sont bonnes pour la similarité sémantique, mais n'ont aucune notion native de permission, de politique ou d'affordance d'outil. Elles iront chercher avec entrain un document que l'agent n'a aucun droit d'exploiter. Quant aux frameworks d'agents, ils bougent trop vite et se fragmentent trop pour devenir le système de référence d'un actif aussi durable que vos règles métier. Vous ne voulez pas coupler votre modèle de gouvernance à la bibliothèque d'orchestration à la mode ce trimestre. Ce dont l'entreprise a besoin, c'est d'une couche *agnostique au framework d'agent, gouvernée de manière centrale et bâtie dès le premier jour autour des trois primitives du travail agentique* : savoir, agir, et avoir le droit. C'est une forme de produit différente de tout ce qui existait dans la modern data stack il y a deux ans, et c'est précisément pour cela que plusieurs acteurs, dont skilder, convergent aujourd'hui pour le construire. ## L'enjeu stratégique Soyons direct sur la raison pour laquelle ce sujet compte au niveau exécutif, parce qu'il est facile d'entendre « nouvelle couche dans la stack » et de zapper en se disant que c'est de la plomberie. Les entreprises qui déploieront des agents avec succès sur les trois prochaines années ne seront pas celles qui ont le plus de données. Ce seront celles qui auront fait le travail de rendre leur contexte (leur jugement, leurs règles, leur connaissance institutionnelle) lisible par des machines. Ce travail n'est pas un projet de week-end. C'est la version suivante de ce qu'on appelait « transformation digitale », et c'est le véritable avantage durable. Vos concurrents peuvent acheter les mêmes modèles et les mêmes data warehouses. Ils ne peuvent pas répliquer facilement une décennie de sagesse opérationnelle codifiée. À l'inverse, les entreprises qui tenteront le raccourci, en jetant des agents sur un data lake brut en espérant que le LLM s'en sorte, vont générer une leçon très coûteuse sur la différence entre contexte et information. On voit déjà les premières versions de cette leçon en production. Des agents qui prennent avec assurance la mauvaise décision. Des agents incapables d'expliquer leur raisonnement à un auditeur. Des agents qui tournent magnifiquement en démo et s'effondrent dès qu'ils rencontrent la réalité désordonnée du fonctionnement réel de l'entreprise. ## Par où commencer Si vous êtes dirigeant et que vous réfléchissez à la préparation de votre organisation pour la vague agentique, la question à ramener à vos équipes n'est pas « quel modèle utiliser » ni « quelle vector DB choisir ». C'est plus simple et plus exigeant : *Si nous devions remettre à un collaborateur nouvellement arrivé, très compétent, le livret qui lui explique comment notre entreprise fonctionne réellement (les règles, les outils, les arbitrages, les choses jamais écrites), pourrions-nous le faire ? Et sinon, qu'est-ce que cela demanderait ?* Ce livret, c'est votre context lake. La catégorie est encore en train de se définir, les éditeurs sont encore en train d'émerger, le terme lui-même cherche encore son sens partagé. Mais le besoin sous-jacent est déjà réel, et les agents sont déjà à la porte. Quel que soit le nom qui s'imposera, le travail de construction de cette couche est celui qui séparera les entreprises pour lesquelles les agents paient de celles pour lesquelles ils ne paient pas. --- Source: https://www.skilder.ai/fr/blog/au-dela-de-mcp-vs-skills # Au-delà de « MCP vs skills » : composer une architecture d'agent à l'échelle > MCP résout le problème de connectivité N×M. Les skills résolvent la saturation du contexte. La vraie opportunité n'est pas d'en choisir un : c'est de composer des skills au-dessus de MCP, organisés par contexte métier. Language: fr · Category: engineering · Author: Nicolas Corod (Ingénierie) · Published: 2026-02-05 Cadrer le débat comme « MCP vs skills » passe à côté du sujet. Comme Kurtis Van Gent l'a [récemment défendu](https://kvg.dev/posts/20260125-skills-and-mcp/), ces deux approches répondent à des problèmes différents : [MCP](https://modelcontextprotocol.io/) s'attaque au problème d'intégration N×M, les skills répondent à la saturation du contexte. Exact. Mais la vraie opportunité, c'est de les composer dans une architecture unifiée. Chez [skilder](https://www.skilder.ai), nous avons construit précisément cela : des skills qui composent des outils MCP en capacités cohérentes, organisés par contexte métier, et exposés via un serveur MCP unique avec une divulgation progressive intégrée au protocole. ## Deux problèmes, une seule architecture. **Le problème d'intégration N×M.** Vous avez N agents (Claude Code, Cursor, votre SDK maison) et M sources de données (GitHub, Slack, Postgres). Sans standardisation, chaque paire agent-outil exige un connecteur sur mesure. MCP ramène cela à N+M avec un protocole universel. **Le problème de saturation du contexte.** Votre agent a accès à 80 outils. Chaque schéma d'outil consomme des tokens. Chargez-les tous d'entrée et vous brûlez 30 000 tokens avant même que l'utilisateur ait dit bonjour. Pire, les modèles raisonnent moins bien lorsqu'ils doivent arbitrer entre des options non pertinentes. L'équipe ADK de Google parle de « signal degradation ». Les agent skills résolvent cela par la divulgation progressive. L'agent voit d'abord des métadonnées légères. Les instructions complètes et les outils ne se chargent qu'à la demande. ## Là où chaque approche échoue, prise isolément. **Le coût de contexte de MCP.** Chaque serveur MCP connecté déverse ses définitions d'outils dans votre fenêtre de contexte. Connectez-vous à GitHub, Slack, Postgres et un serveur CI/CD : des centaines de définitions d'outils chargées avant le moindre travail. Les recherches d'Anthropic ont elles-mêmes montré qu'un chargement à la demande faisait passer la consommation de 150 000 à 2 000 tokens dans un cas réel. **Le problème d'isolation.** Un skill apprend à un agent à déployer du code. Mais atteindre le système de déploiement effectif suppose des scripts maison (dépendants de l'environnement, fragiles) ou un repli sur MCP (et la perte de l'efficacité contextuelle). Écrivez un skill sur macOS, partagez-le avec une collègue sur Windows, et il cassera. **La prolifération multi-serveurs.** Les équipes se retrouvent avec cinq serveurs MCP connectés, une douzaine de skills éparpillés, et aucune relation claire entre les deux. L'agent doit deviner quel skill s'applique à quel serveur, quels outils appartiennent à quel workflow. La charge cognitive s'empile. ## La thèse de la composition. Le correctif : les skills deviennent la couche de composition au-dessus de MCP. Un skill regroupe des outils MCP liés en une unité cohérente, avec des instructions sur la façon de les utiliser ensemble. Un skill « deploy-to-staging » relie les outils précis dont il a besoin et guide l'agent dans le workflow. L'agent voit « deploy-to-staging » comme un concept unique. Il n'a pas besoin de savoir que GitHub et CircleCI existent comme systèmes distincts. MCP gère la connectivité. Le skill gère la chorégraphie. Chez [skilder](https://www.skilder.ai), nous exposons tout cela via un serveur MCP unique. Votre agent se connecte à un seul endpoint au lieu de cinq. La divulgation progressive est inscrite dans le protocole lui-même : l'agent démarre avec un catalogue léger des skills disponibles et ne charge les schémas d'outils complets que lorsque c'est nécessaire. Résultat : au lieu de payer 20 000 tokens d'entrée pour 10 serveurs d'outils, vous payez environ 2 900 tokens, avec des capacités équivalentes chargées à la demande. ### Contexte métier, pas catalogue d'outils. Une liste plate de skills crée son propre problème. Dans un environnement d'entreprise, des dizaines de skills couvrant plusieurs équipes recréent la même surcharge cognitive, un cran plus haut. Nous organisons les skills en groupes de contexte métier : des collections nommées par rôle, domaine ou workflow. Un groupe « DevOps » réunit déploiement, monitoring et rollback. Un groupe « Customer Support » réunit recherche, facturation et escalade. L'agent navigue des concepts métier plutôt que des catégories techniques. Cela fait le pont entre la façon dont les ingénieurs pensent (outils, API) et la façon dont les organisations pensent (rôles, processus, domaines). ### De la transparence à la délégation. Tous les workflows n'exigent pas le même niveau d'implication de l'agent. Les regroupements d'outils simples ont besoin d'un contrôle total de l'agent. Les workflows complexes et éprouvés gagnent à être délégués. [skilder](https://www.skilder.ai) couvre tout le spectre : de l'agent qui orchestre des outils individuels en pleine transparence, jusqu'à l'exécution en sous-agent où un processus autonome absorbe la complexité. Les organisations démarrent en mode transparent et font monter en délégation les workflows éprouvés, à mesure qu'ils prouvent leur fiabilité. ## Pourquoi cela passe à l'échelle. **Efficacité du contexte.** Les agents paient pour ce qu'ils utilisent. Pas pour ce qu'ils pourraient utiliser. **Charge cognitive réduite.** Des capacités pré-composées avec des instructions claires. Les erreurs de sélection d'outils chutent quand les agents travaillent avec des workflows cohérents plutôt qu'avec des schémas d'outils bruts. **Point de connexion unique.** Un seul serveur MCP à connecter, configurer et sécuriser. Pas de prolifération d'identifiants. **Gouvernance d'entreprise.** Chaque invocation de skill et chaque appel d'outil sont tracés. Les pistes d'audit complètes alimentent l'optimisation : skills inutilisés, patterns de timeout, points chauds d'échec. Les skills s'améliorent à partir des données d'usage au fil du temps. **Suivi des dépendances.** Quand un serveur MCP sous-jacent change, les skills affectés sont identifiés automatiquement. Les mises à jour se propagent dans le système au lieu d'exiger des audits manuels. ## Compromis. **Complexité d'écriture.** Créer des skills composés suppose de comprendre à la fois le workflow et les outils sous-jacents. Notre approche : la génération de skills assistée par IA. Décrivez un workflow en langage naturel. [skilder](https://www.skilder.ai) amorce la structure du skill. **Complexité du débogage.** Les couches d'abstraction ajoutent de la complexité au débogage. Mitigation : une télémétrie structurée à chaque couche, avec un contexte de trace qui circule à travers toute la stack. **Surcoût de découverte.** La divulgation progressive ajoute un aller-retour avant que l'agent n'utilise les outils. Les skills préchargés contournent cela pour les workflows connus. Pour la plupart des cas d'usage en entreprise, les économies de contexte dépassent largement ce coût. ## Pour démarrer. 1. **Identifiez les workflows à forte valeur.** Trouvez trois à cinq workflows où votre équipe coordonne régulièrement plusieurs outils. Ce sont vos premiers skills composés. 2. **Commencez simplement, montez vers la délégation.** Démarrez avec des skills qui regroupent des outils liés et de bonnes instructions. Promouvez les workflows stables vers plus d'automatisation à mesure qu'ils prouvent leur fiabilité. 3. **Organisez par contexte métier dès le départ.** Structurez les skills par rôle ou domaine dès le début. Imposer une structure plus tard est plus difficile. 4. **Exposez via une passerelle unique.** Connectez vos agents à travers un seul serveur MCP. Ajouter des skills n'augmente pas le coût de contexte de base. ## Perspectives. La [proposition SEP-2076](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076) suggère d'ajouter les Agent Skills directement à la spécification [MCP](https://modelcontextprotocol.io/). Un support natif des skills composés, avec dépendances d'outils et divulgation progressive, ferait de ce pattern un standard plutôt qu'un montage maison. Au-delà : les graphes de skills fédérés. Des organisations publient des collections de skills que d'autres consomment et étendent. Des graphes DevOps maintenus par la communauté, enrichis de workflows spécifiques à chaque entreprise. La composition à l'échelle de l'écosystème. Le débat MCP vs skills est une fausse opposition. MCP résout la connectivité. Les skills résolvent l'efficacité du contexte. Le modèle que nous avons construit chez [skilder](https://www.skilder.ai) les compose : des skills au-dessus de MCP, organisés par contexte métier, exposés via un serveur unique avec divulgation progressive au niveau du protocole. L'avenir de l'architecture d'agent, c'est des skills au-dessus de MCP, composés en un graphe de connaissances qui passe à l'échelle de votre organisation. --- Source: https://www.skilder.ai/fr/blog/skill-graphs-mise-a-echelle # Au-delà du SKILL.md unique : comment les skill graphs passent à l'échelle > Un fichier de skill seul plafonne vite. Les skill graphs transforment l'expertise métier en réseau navigable que les agents traversent au lieu de deviner. Language: fr · Category: engineering · Author: Nicolas Corod (Ingénierie) · Published: 2026-01-31 On sous-estime la puissance du savoir structuré. Il rend possible des applications d'une nature nouvelle. Aujourd'hui, les agent skills écrits capturent un seul aspect d'une tâche. Un skill pour résumer, un skill pour la revue de code, et ainsi de suite. Souvent un fichier, une capacité. C'est suffisant pour les tâches simples. La vraie profondeur exige autre chose. Imaginez un skill de conseil hypothécaire qui doit couvrir les critères d'éligibilité au prêt, les cadres de conformité réglementaire, les méthodologies d'évaluation du risque, les normes d'estimation immobilière et les bonnes pratiques de communication client. Un SKILL.md seul ne peut pas tout porter. ## Le problème : un skill isolé heurte un plafond de complexité. Quand vous essayez de capturer un domaine métier complexe dans un seul fichier, vous heurtez des limites dures : - **Frontières artificielles** : des concepts liés se retrouvent séparés parce qu'ils « appartiennent » à des skills différents. - **Duplication du savoir** : les concepts partagés sont recopiés dans plusieurs skills, ce qui crée un cauchemar de maintenance. - **Connexions perdues** : les relations entre concepts ne sont pas navigables, elles restent implicites. - **Effondrement à l'échelle** : au-delà de 500 à 1 000 lignes, un fichier unique devient ingérable. Ce n'est pas un problème théorique. Essayez de loger toute la connaissance d'un prêteur hypothécaire dans un seul SKILL.md : produits de prêt, règles de souscription, exigences de conformité, cadres d'évaluation du risque, critères d'éligibilité client. Vous créez soit un monolithe massif, soit une fragmentation telle que l'agent ne voit plus comment les pièces s'articulent. L'approche mono-fichier vous force à choisir entre profondeur et navigabilité. Le skill graph supprime cet arbitrage. ## Skill graphs : l'évolution suivante. Un skill graph est un réseau de fichiers de skills interconnectés qui se référencent les uns les autres. Au lieu d'un gros fichier, vous avez plusieurs petites pièces composables qui se relient entre elles. Chaque fichier porte une pensée, une technique ou une règle métier complète. Les connexions entre eux forment un graphe traversable que l'agent navigue intelligemment. Un skill graph applique le même schéma de découverte de skill récursivement à l'intérieur du graphe lui-même. Chaque nœud porte des métadonnées que l'agent peut scanner sans lire le fichier en entier. Chaque arête porte du sens parce qu'elle est intégrée au contexte : l'agent suit les chemins pertinents et ignore le reste. **Divulgation progressive :** - Index, puis descriptions, puis liens, puis sections, puis contenu complet. La plupart des décisions se prennent avant la lecture d'un seul fichier complet. ## Skills isolés vs skill graphs : la comparaison. | Dimension | Skills isolés | Skill graphs | |-----------|--------------|--------------| | **Profondeur** | Limitée au contenu d'un seul fichier | Illimitée, suit la complexité du domaine | | **Maintenabilité** | Une mise à jour exige de toucher le fichier entier | Un node mis à jour, tout le graphe en profite | | **Composabilité** | Difficile à réutiliser entre contextes | Conçu pour la composition et la réutilisation | | **Flux de contexte** | Silos isolés de savoir | Réseaux d'expertise interconnectés | | **Comportement de l'agent** | Suit des instructions | Comprend les relations du domaine | | **Time to value** | Rapide pour les tâches simples | Composé dans le temps, à mesure que le graphe grandit | | **Passage à l'échelle** | Casse au-delà de 500 à 1 000 lignes | Tient sur des milliers de nœuds interconnectés | ## À quoi ressemble un skill graph en pratique. Une fois passé du fichier unique au réseau d'expertise, le même schéma se retrouve d'un secteur à l'autre : - **Skill graph d'une entreprise du bâtiment** : protocoles de sécurité, exigences de conformité, gestion fournisseurs, planification de projet, checklists qualité. Chaque pièce reliée à des procédures connexes pour que le contexte circule entre elles. - **Skill graph d'un acteur des services financiers** : produits hypothécaires, critères de souscription, conformité réglementaire, règles d'éligibilité client, cadres de risque. Tout traversable depuis un point d'entrée unique. - **Skill graph d'un industriel** : standards qualité, workflows de production, exigences fournisseurs, politiques d'inventaire, maintenance des équipements. Rien de tout cela ne tient dans un fichier unique, et pourtant chaque ensemble fonctionne comme un graphe. ## Primitives d'infrastructure. Une architecture de skill graph repose sur trois éléments centraux : - **Connexions sémantiques** intégrées au contexte en langage naturel, pour que les liens portent du sens et pas seulement des références. - **Métadonnées structurées** avec descriptions, pour que les agents scannent et décident sans lire les fichiers complets. - **Cartes thématiques** qui organisent les grappes de skills liés en domaines navigables. Les skills référencent d'autres skills, qui référencent d'autres skills, et le graphe descend aussi profondément que le domaine l'exige. ## Architecture d'implémentation. L'architecture de skill graph que skilder met en œuvre suit ce schéma : **1. Génération de skills** : les documents et politiques internes sont traités pour produire des nœuds de skill structurés, sans requérir d'expertise ML. **2. Couche de combinaison** : les skills s'agrègent avec des intégrations d'outils via le [Model Context Protocol (MCP)](https://modelcontextprotocol.io/), apportant à la fois du contexte et des capacités d'action. **3. Regroupement par rôle** : les skills sont organisés en bundles spécifiques à un domaine (par exemple : conseiller hypothécaire, responsable sécurité) qui représentent des contextes opérationnels complets. **4. Exécution distribuée** : l'infrastructure se répartit entre les organisations avec traçage d'exécution et auditabilité complets. Ces composants fonctionnent ensemble comme des nœuds d'un graphe interconnecté, et non comme des capacités isolées. ## Ce que cela change. Les approches traditionnelles s'accompagnent de contraintes lourdes : - **Implémentations RAG sur mesure** : 10 000 à 35 000 $ par modèle, 6 à 12 mois. - **Chatbots génériques** : aucun contexte métier, adoption limitée sur les tâches critiques. - **Fine-tuning** : exige des compétences ML rares, réentraînement coûteux à chaque mise à jour. Les skill graphs proposent une autre voie : - Expertise métier conditionnée comme une infrastructure traversable. - Les agents parcourent la logique métier de façon contextuelle. - Le contexte se compose et évolue avec l'usage. - Les mises à jour se propagent dans le graphe sans réentraînement. La différence se joue entre un agent qui suit des instructions et un agent capable de parcourir les relations du domaine. ## Émergence par l'usage. Les skill graphs présentent des propriétés émergentes intéressantes à mesure qu'ils grandissent : - Les contributeurs individuels créent des skills pour leurs workflows propres. - Les schémas d'usage révèlent quelles connexions conceptuelles sont réellement pertinentes. - Les traces de navigation montrent comment les agents traversent le savoir métier en pratique. - Des motifs inter-organisationnels font remonter des approches communes à des problèmes similaires. - Des méta-motifs émergent des données agrégées de parcours du graphe. Cela crée une boucle de rétroaction où l'infrastructure devient plus efficace à mesure qu'elle est utilisée, sans exiger une curation centralisée de chaque connexion. ## Considérations de déploiement. Les skill graphs qui portent de la logique métier soulèvent des questions de déploiement sérieuses. [L'implémentation skilder](https://www.skilder.ai) y répond par : - **Résidence des données** avec options d'infrastructure hébergée en UE. - **Conformité par construction** pour le RGPD et les cadres similaires. - **Déploiement gouverné** à l'échelle de l'entreprise. - **Architecture BYOK** (*Bring Your Own Key*) pour éliminer les coûts de pass-through sur les API de LLM. Les organisations conservent le contrôle de leurs graphes de savoir tout en bénéficiant de la composabilité du skill graph. ## Perspective. Les skills représentent une approche de l'ingénierie du contexte : du savoir sélectionné, injecté là où il est nécessaire. Les skill graphs prolongent cette idée en rendant ce savoir navigable plutôt que monolithique. Au lieu d'injections uniques, les agents traversent des structures de connaissance et ne tirent que ce que le contexte courant exige. À mesure que les entreprises continuent leur adoption de l'IA, les questions de structuration et de maintenance du contexte métier prendront vraisemblablement une importance croissante. --- ## Références 1. Anthropic : [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) 2. Dgraph : [Graph Database for Knowledge Infrastructure](https://dgraph.io/) --- Source: https://www.skilder.ai/fr/blog/agent-skills-vs-plateformes-workflow # Agent Skills ou plateformes de workflow : que choisir vraiment ? > Plateformes de workflow contre agent IA : tout dépend du désordre réel. Cadre de décision entre workflows déterministes et agent skills adaptatifs, et l'hybride qui gagne. Language: fr · Category: product · Author: Nicolas Corod (Produit) · Published: 2026-01-29 La plupart des DSI font face à la même décision quand un nouveau processus interne arrive sur la feuille de route : l'automatiser avec une plateforme de workflow comme Zapier, ou le confier à un agent IA. La réponse honnête, c'est que le choix dépend du niveau de désordre réel, et qu'il définira la façon dont l'entreprise pilotera son automatisation sur les cinq prochaines années. Les workflows excellent quand les entrées sont prévisibles et que le processus bouge peu. Les agent skills prennent le relais quand les entrées sont non structurées, que les règles dérivent, ou que la tâche demande un vrai jugement. Choisir le mauvais outil se paie en dette de maintenance dans les six mois : soit une chaîne fragile de « si/alors » qui se casse à chaque cas limite, soit un agent qui agit avec aplomb sur un format d'entrée auquel personne ne s'attendait. Cet article pose un cadre de décision : quand chaque approche est la bonne, pourquoi les agent skills gagnent silencieusement la bataille de l'automatisation du travail intellectuel, et comment les meilleurs montages en production combinent les deux. ## Posons d'abord les définitions. ### Les plateformes de workflow : la chaîne de montage programmée. Voyez des outils comme [Zapier](https://zapier.com/), [Make](https://www.make.com/) ou [n8n](https://n8n.io/) comme des **chaînes de montage que vous programmez vous-même**. La logique est simple : SI [le déclencheur se produit] ALORS [action 1] puis [action 2] puis [action 3]. Exemple : un nouvel e-mail arrive, on extrait la pièce jointe, on l'enregistre dans Google Drive, on notifie l'équipe sur Slack. **Là où elles brillent :** - Exécution prévisible et reproductible. - Piste d'audit claire (vous voyez exactement ce qui s'est passé). - Pas d'IA requise, pure logique. - Coût fixe (abonnement mensuel). **Là où elles coincent :** - Rigides. Le moindre imprévu casse le workflow. - Les scénarios complexes exigent des dizaines d'étapes et de conditions. - La maintenance vire au cauchemar à mesure que les cas particuliers se multiplient. - Vous programmez en réalité pour un monde qui n'existe pas : un monde parfaitement prévisible. **L'analogie :** une plateforme de workflow, c'est un distributeur automatique. Vous tapez B7, vous obtenez un snack. Mais si vous lui demandez « quelque chose de sain avec des protéines », il vous regarde sans comprendre. ### Les agent skills : l'assistant intelligent avec sa boîte à outils. Imaginez maintenant autre chose : un assistant IA (type Claude ou GPT) qui **comprend votre objectif** et dispose d'outils, e-mail, tableurs, bases de données, API. Vous ne programmez pas chaque étape. Vous décrivez la cible : « Traiter les demandes de devis entrantes et les router vers le commercial pertinent selon le produit et la région. » L'agent trouve comment faire. Il lit l'e-mail, comprend le contexte, extrait l'information utile, tranche, et agit. **Là où ils brillent :** - Adaptation aux entrées inattendues (e-mails désordonnés, demandes inhabituelles). - Gestion de l'ambiguïté par raisonnement. - Un prompt remplace des dizaines d'étapes de workflow. - Évolution facile : changez les instructions, le comportement suit. **Là où ils coincent :** - Moins prévisibles (la même entrée peut produire des sorties légèrement différentes). - Les coûts montent avec l'usage (tokens). - Ils exigent des garde-fous contre les actions non voulues. - Plus durs à auditer (« pourquoi a-t-il fait ça ? »). **L'analogie :** un agent skill, c'est un stagiaire futé. Donnez-lui un objectif, il trouve les étapes. Il peut vous surprendre, parfois en bien, parfois moins. ## Le vrai test : la comparaison côte à côte. Concret. Imaginez que vous recevez des demandes de devis par e-mail. Vous devez : 1. Extraire le nom du client, l'entreprise, le produit visé. 2. Vérifier s'il s'agit d'un client existant dans le CRM. 3. Router vers le bon commercial selon la région. 4. Envoyer un accusé de réception. 5. Créer une tâche dans l'outil de gestion de projet. ### Comment une plateforme de workflow s'en sort. Vous construisez une automatisation à 15 étapes : 1. Déclencheur : nouvel e-mail avec « devis » dans l'objet. 2. Parsing du corps de l'e-mail avec des regex. 3. Extraction du nom (pattern match). 4. Extraction de l'entreprise (pattern match). 5. Extraction du produit (détection de mots-clés). 6. Appel API au CRM : recherche par e-mail. 7. Condition : si trouvé → branche A, sinon → branche B. 8. Récupération de la région depuis le CRM. 9. Mapping région vers commercial (table de correspondance). 10. Envoi d'un accusé de réception via template. 11. Création de la tâche dans l'outil projet. 12. Gestion d'erreurs à chaque étape. 13. Journalisation. 14. …et ainsi de suite. **Ça marche.** Jusqu'au moment où quelqu'un envoie une demande de devis avec l'objet « Petite question sur les prix » (pas de mot-clé « devis »). Ou écrit son nom d'entreprise dans la signature plutôt que dans le corps. Ou demande sur deux produits. Ou répond à un ancien fil. Chaque cas limite réclame une nouvelle branche. Votre automatisation propre devient une toile emmêlée. **Réalité de la maintenance :** au bout de six mois, plus personne ne veut y toucher. ### Comment un agent skill s'en sort. Vous écrivez une seule instruction : > « Quand un nouvel e-mail arrive qui ressemble à une demande de devis, extrayez le nom du client, l'entreprise et le produit visé. Vérifiez dans notre CRM s'il s'agit d'un client existant. Routez vers le commercial pertinent selon sa région (utilisez le mapping des territoires). Envoyez un accusé de réception personnalisé et créez une tâche de suivi. » L'agent lit l'e-mail, y compris les passages écrits à la main, désordonnés et non structurés. Il comprend que « Petite question sur les prix de l'offre entreprise » est une demande de devis. Il trouve le nom de l'entreprise dans la signature. Il gère l'ambiguïté. **Et les cas limites ?** L'agent raisonne dessus. « Cet e-mail mentionne deux produits. Je les note tous les deux et je laisse le commercial trancher. » **Réalité de la maintenance :** changer la logique de routage ? Mettez à jour le prompt. Fini. ### Le tableau comparatif. | Critère | Plateforme de workflow | Agent skill | |---------|------------------------|-------------| | **Complexité de mise en place** | Élevée (15+ étapes) | Faible (1 prompt + outils) | | **Gestion des variations** | Casse à la moindre entrée inattendue | S'adapte par raisonnement | | **Maintenance** | Lourde (gestion des cas limites) | Légère (mise à jour du prompt) | | **Modèle de coût** | Fixe (abonnement) | Variable (par token) | | **Auditabilité** | Excellente (logs clairs) | Moyenne (traces de raisonnement) | | **Prévisibilité** | Très élevée | Élevée, mais pas absolue | | **Cas d'usage** | Processus stables, fort volume | Tâches variables, à fort jugement | ## Quand utiliser quoi : un cadre pratique. ### Choisissez une plateforme de workflow quand : - Votre processus est **100 % prévisible** et bouge rarement. - Vous exigez **zéro tolérance à la variation** (conformité, juridique, transactions financières). - Le **volume est élevé** et les entrées parfaitement structurées. - Vous devez tenir une **piste d'audit en béton** pour le régulateur. - Vos équipes doivent **le maintenir sans expertise IA**. **Exemples :** traitement de factures avec PDF normalisés, séquences d'inscription puis d'e-mail de bienvenue, alertes de stock sur seuils fixes. ### Choisissez un agent skill quand : - Les entrées sont **variables ou non structurées** (e-mails, documents, conversations). - La tâche demande un **jugement contextuel** (« Est-ce urgent ? », « Qui doit traiter ça ? »). - Votre processus **évolue souvent** (nouveaux produits, règles qui bougent). - Le **volume est modéré** mais la **complexité est élevée**. - Vous traitez du **langage naturel** humain. **Exemples :** triage du support client, analyse documentaire, qualification de leads, synthèse de recherche, traitement de contenu. ### L'hybride optimal : le meilleur des deux mondes. Voici ce que font les équipes lucides : **un agent skill à l'entrée, un workflow à la sortie**. L'agent gère la réception désordonnée et imprévisible : comprendre les e-mails, classifier les demandes, extraire des données structurées du chaos. Puis il passe une charge propre et structurée à un workflow qui exécute les actions déterministes : mise à jour du CRM, envoi de notifications, création de fiches. **Pensez-le ainsi :** - L'agent skill, c'est le cerveau (comprendre, décider, router). - La plateforme de workflow, ce sont les mains (exécuter, enregistrer, notifier). Cet hybride vous donne de l'adaptabilité là où vous en avez besoin, et de la prévisibilité là où elle compte. ## Pourquoi les agent skills gagnent silencieusement. Soyons directs : pour la plupart des automatisations de travail intellectuel, les agent skills deviennent le meilleur choix. Pour quatre raisons. **1. Le monde réel est désordonné.** Vos clients n'écrivent pas des e-mails parfaitement formatés. Vos données ne sont pas toujours propres. Vos processus ont des exceptions. Les workflows sont bâtis pour un monde idéal, les agents pour le monde réel. **2. Les coûts de token chutent vite.** L'argument économique contre les agents (« trop chers à l'échelle ») s'effrite. Les coûts ont baissé de plus de 90 % en deux ans. La tendance continue. **3. Les skills deviennent des briques réutilisables.** Comme les workflows ont leurs templates prêts à l'emploi, les agent skills deviennent modulaires. « Skill de traitement d'e-mails », « skill d'extraction documentaire », « skill de consultation CRM » : on les emboîte. **4. La maintenance ne se compose pas pareil.** La complexité d'un workflow croît avec les cas limites. La capacité d'un agent croît avec de meilleures instructions. L'un passe à l'échelle dans la douleur, l'autre passe à l'échelle avec grâce. **Au fond :** un workflow automatise ce que vous aviez anticipé. Un agent skill gère ce que vous n'aviez pas vu venir. ## Ce que ça implique pour vous. Avant votre prochaine automatisation, posez-vous trois questions. 1. **À quel point mes entrées sont-elles prévisibles ?** Plus de 90 % identiques : workflow. Variables : agent skill. 2. **Cette tâche demande-t-elle du jugement ?** Oui : agent skill. Non : workflow. 3. **À quelle fréquence ce processus va-t-il changer ?** Souvent : agent skill. Rarement : workflow. Et si vous hésitez ? Commencez par un agent skill. Vous pourrez toujours ajouter des composants workflow plus tard pour les parties déterministes. Le paysage de l'automatisation se déplace. Les workflows ne disparaîtront pas : ils restent imbattables pour l'exécution pure et prévisible. Mais pour la réalité désordonnée des opérations métier, les agent skills s'imposent de plus en plus comme le bon outil. La question n'est plus « workflow ou agent ? ». C'est « comment combiner les deux intelligemment ? ». --- Source: https://www.skilder.ai/fr/blog/rag-vs-agent-skills # RAG vs agent skills : la différence à connaître > Le RAG récupère du contenu. Les skills empaquettent des compétences. Pourquoi les confondre limite la conception des agents IA, et un cadre pour choisir entre les deux. Language: fr · Category: engineering · Author: Nicolas Corod (Recherche) · Published: 2026-01-21 ### « Donc en gros, les agent skills, c'est juste une autre façon de donner des documents à l'agent, non ? » Cette question revient sans cesse dans les conversations sur les agents IA. Et à chaque fois, elle révèle un malentendu de fond qui limite la façon dont les entreprises pensent les capacités de leurs agents. Les [agent skills](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) et le [RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) ne sont pas la même chose. Ils résolvent des problèmes différents, opèrent à des niveaux différents, et les confondre conduit à sous-estimer ce que les skills peuvent réellement apporter à votre stratégie IA. Clarifions. ## Qu'est-ce que le RAG ? Une définition rapide. Le RAG (Retrieval-Augmented Generation) est un mécanisme de récupération. Son rôle est de chercher dans un corpus de documents et de renvoyer l'information pertinente à l'agent. Quand un utilisateur demande « Quelle est notre politique de retour pour les commandes internationales ? », le RAG parcourt les documents de politique, trouve la section pertinente et la transmet à l'agent. L'agent utilise ensuite ce contenu récupéré pour formuler sa réponse. Le RAG est essentiellement un moteur de recherche pour votre base de connaissance interne. Il trouve et renvoie du contenu existant. Rien de plus, rien de moins. C'est précieux. Sans RAG, un agent ne connaît que ce qu'il a appris pendant l'entraînement : un savoir générique, sans aucune notion des informations propres à l'entreprise. Le RAG comble ce vide en donnant à l'agent accès aux documents propriétaires. Mais la récupération est le point d'arrêt du RAG. Il répond à la question : *« Quelle information existe sur ce sujet ? »* ## Qu'est-ce qu'un agent skill ? Un skill est fondamentalement différent. Il ne s'agit pas de récupérer de l'information. Il s'agit de permettre une exécution compétente. Un [skill](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) empaquette trois éléments : la connaissance métier liée à une tâche précise, la logique de processus qui décrit comment traiter cette tâche correctement, et les capacités d'exécution pour réellement déclencher des actions. Prenons un exemple concret. Un utilisateur dit : « Je veux retourner ce produit commandé il y a trois semaines. » Avec le RAG seul, l'agent peut chercher dans le document de politique de retour et en restituer le contenu. Il récupère et relaie de l'information. Avec un skill de gestion des retours, l'agent comprend les règles de politique, connaît les étapes du processus d'évaluation d'une demande de retour, peut vérifier l'historique de commande et l'éligibilité, et peut déclencher le retour dans le système si les conditions sont réunies. Il n'informe pas seulement. Il exécute. Un skill répond à une question différente : *« Comment cette tâche doit-elle être traitée, et quelles actions sont requises ? »* ## RAG vs agent skills : la distinction de fond. La confusion entre RAG et skills vient souvent d'une ressemblance de surface : tous deux consistent à « donner de l'information à l'agent ». Mais la nature de cette information est totalement différente. **Le RAG fournit du contenu** : du texte brut récupéré depuis des documents, que l'agent doit interpréter seul. **Les skills fournissent du contexte** : de la connaissance structurée qui façonne la manière dont l'agent raisonne, décide et agit dans des situations précises. | Aspect | RAG | Agent skill | |--------|-----|-------------| | **Finalité** | Récupérer du contenu existant depuis des documents | Permettre une exécution compétente | | **Sortie** | Information renvoyée à l'agent | Action + résultat livrés à l'utilisateur | | **Contient** | Mécanisme de recherche + corpus documentaire | Connaissance + logique de processus + capacité d'exécution | | **Analogie** | Accès à une bibliothèque | Formation professionnelle | | **Répond à** | « Quelle information existe ? » | « Comment faut-il faire ? » | Pensez-y ainsi : le RAG, c'est donner à quelqu'un l'accès à une bibliothèque. Les skills, c'est lui donner une formation professionnelle. L'accès aux manuels de médecine ne fait pas de quelqu'un un médecin. La formation, qui combine connaissance, méthode et capacité pratique, oui. Un agent avec du RAG sait chercher. Un agent avec des skills sait accomplir une tâche avec compétence. ## Pourquoi c'est central pour la conception d'un agent IA. Quand les entreprises traitent les skills comme « une autre façon de donner des documents », elles conçoivent leurs agents autour de la récupération plutôt que de la capacité. Résultat : un agent qui répond à des questions, mais qui peine à aider concrètement les utilisateurs à accomplir leurs tâches. Cela se traduit de plusieurs façons : - Des agents qui fournissent une information juste, mais laissent toutes les actions à l'utilisateur. - Des agents qui n'ont pas de méthode constante pour traiter les demandes complexes. - Des agents qui ne savent pas adapter leur comportement au contexte de la situation. Passer d'une pensée centrée sur le RAG à une pensée centrée sur les skills change la question de conception : on ne demande plus « à quels documents l'agent doit-il avoir accès ? », mais « quelles compétences l'agent doit-il maîtriser pour faire son travail ? ». ## Quand utiliser RAG ou skills : un cadre pratique. Voici une façon simple de déterminer quelle approche s'applique à un besoin donné. **Utilisez le RAG quand** l'objectif est de faire remonter de l'information existante : répondre à des questions sur des politiques, retrouver de la documentation, fournir un support de référence. **Utilisez les skills quand** l'objectif est l'exécution compétente d'une tâche : traiter des demandes qui exigent de comprendre un contexte, appliquer des règles, suivre un processus et déclencher des actions. **Utilisez les deux quand** un agent doit fonctionner comme un assistant capable, et non comme une interface de recherche. C'est le cas dans la plupart des applications réelles. ## La question de l'intégration. Une question naturelle se pose : où placer les intégrations d'outils dans ce modèle ? Les architectures traditionnelles séparent souvent connaissance (RAG), raisonnement (le LLM) et actions (intégrations d'outils) en couches distinctes. Cela crée de la complexité et de la fragmentation : l'agent doit coordonner des systèmes qui ne se comprennent pas intrinsèquement. Une approche plus efficace regroupe ces éléments. Quand connaissance métier, logique de processus et capacité d'exécution sont empaquetées en un skill unifié, l'agent gagne une compétence cohérente plutôt que des morceaux déconnectés. C'est l'approche retenue par [skilder](https://skilder.ai) : les skills sont des compétences complètes, pas seulement des documents ou des connexions à des outils. L'agent ne récupère pas une politique, puis ne calcule pas séparément comment l'appliquer, puis n'invoque pas séparément un outil. Il dispose d'une capacité intégrée pour traiter ce type de tâche. Chez skilder, un Hat regroupe les skills, le contexte et les permissions propres à un rôle, ce qui rend ce schéma opérationnel à l'échelle de l'entreprise. ## À retenir. **Le RAG est un mécanisme de récupération.** Il cherche dans des documents et renvoie du contenu. Précieux pour accéder à l'information, mais limité à cette fonction. **Les skills sont des compétences empaquetées.** Ils combinent connaissance métier, méthodologie de processus et capacité d'exécution en une aptitude unifiée à traiter des tâches précises. **Ils sont complémentaires, pas concurrents.** La plupart des agents en production ont besoin des deux. Pour les équipes qui construisent des agents IA, la question stratégique n'est pas seulement « quelle information l'agent doit-il avoir ? », mais « quelles compétences l'agent doit-il maîtriser pour bien faire son travail ? ». La réponse à cette question décide si vous obtenez un chatbot ou un assistant capable. --- Source: https://www.skilder.ai/fr/blog/retrieval-nouvelle-intelligence # La retrieval est la nouvelle intelligence. > À mesure que les agents accèdent à plus d'outils, le goulot d'étranglement se déplace du raisonnement vers la retrieval. Pourquoi choisir le bon outil devient la prochaine frontière des agents IA. Language: fr · Category: engineering · Author: Nicolas Corod (Recherche) · Published: 2026-01-19 ## La personne la plus douée, avec la mauvaise boîte à outils. Vous appelez une artisane pour réparer un robinet qui fuit. Elle arrive avec 500 outils dans son utilitaire. Elle sait se servir de chacun. Mais elle attrape une scie au lieu d'une clé à molette. Le robinet n'est pas réparé. Pas par manque de compétence. Parce qu'elle a choisi le mauvais outil. C'est exactement ce qui se passe à l'intérieur des agents IA tous les jours. Un agent prend votre demande, choisit un outil dans sa panoplie et l'exécute. Quand ça marche, l'effet est magique. Quand ça rate, l'échec est précis : il a pris le mauvais outil. Ou il n'a pas su que le bon existait. L'industrie a passé des années à rendre les modèles plus intelligents. Meilleurs en raisonnement, en code, en compréhension du langage. Mais un problème plus discret a grossi en arrière-plan. À mesure que les agents accèdent à plus d'outils, trouver le bon devient plus difficile. Ce problème porte un nom : la retrieval, c'est-à-dire la sélection du bon outil pour la tâche. ## Qu'est-ce que la retrieval ? La retrieval, c'est le processus qui consiste à trouver et sélectionner le bon outil pour une tâche donnée. Quand vous demandez à un assistant IA de « me préparer une présentation », l'agent doit déterminer quel outil traite les slides. Quand vous dites « résume ce document », il attrape un outil différent. Quand vous dites « nettoie ça », il doit interpréter votre intention puis la rapprocher d'une capacité précise. L'IA ne vous renvoie pas dix options à choisir. Elle prend un outil et l'exécute. Si elle se trompe, vous obtenez un mauvais résultat sans forcément comprendre pourquoi. Ce problème prend de l'ampleur dans la recherche. Des chercheurs de Stanford et Harvard ont récemment publié un [cadre d'analyse expliquant pourquoi les systèmes d'IA agentique s'effondrent en production](https://www.marktechpost.com/2025/12/24/this-ai-paper-from-stanford-and-harvard-explains-why-most-agentic-ai-systems-feel-impressive-in-demos-and-then-completely-fall-apart-in-real-use/), et la retrieval des outils y est identifiée comme un point de défaillance central. Le [projet ToolBench](https://github.com/OpenBMB/ToolBench), mis en avant à [ICLR 2024](https://iclr.cc/), a construit un benchmark de plus de 16 000 API réelles et constaté que même les modèles avancés peinent à maintenir leur précision de retrieval à mesure que le catalogue d'outils grossit. Plus récemment, [MCP-Bench](https://arxiv.org/abs/2508.20453) a testé des agents sur 250 outils et confirmé que retrouver le bon outil à partir d'instructions floues reste l'un des défis non résolus les plus durs du design d'agents IA. ## Pourquoi ça casse. L'échec de retrieval le plus dangereux est celui que vous ne voyez jamais. L'agent ne choisit pas le mauvais outil. Il ne choisit aucun outil, parce qu'il ne sait pas que le bon existe. Vous lui demandez de « vérifier ce contrat pour repérer les clauses risquées ». Il possède un outil spécialisé de revue juridique, mais le système de retrieval ne le fait pas remonter. L'agent utilise donc un outil texte générique à la place. Vous obtenez une réponse moyenne et concluez que l'IA n'en est pas capable. En réalité, l'outil parfait restait inutilisé dans la boîte. C'est l'échec invisible, et il érode la confiance plus vite que n'importe quelle erreur visible. Plusieurs forces rendent la retrieval difficile. Chaque outil est livré avec une description. Pensez-y comme à l'étiquette d'un bocal. L'agent lit ces étiquettes pour décider lequel attraper. Mais les étiquettes sont écrites par des humains. Les humains sont incohérents. Un outil annonce « générer des fichiers DOCX ». Un autre « créer des documents professionnels ». Un troisième « rédiger des rapports formatés ». Tous les trois font à peu près la même chose avec des mots différents. L'agent doit comprendre que votre demande de « note soignée » correspond à n'importe lequel des trois. L'échelle amplifie le problème. Un agent avec cinq outils décide vite. Un agent avec 200 outils affronte des recouvrements, des ambiguïtés et une context window saturée. Chaque description prend de la place en traitement. Certains systèmes ne montrent à l'agent qu'un sous-ensemble d'outils. Mais si le bon ne figurait pas dans le sous-ensemble ? Reste la partie humaine. Les gens parlent d'une façon qui ne colle pas proprement aux descriptions d'outils. « Répare mes données » peut vouloir dire supprimer des doublons, corriger un format, combler des trous, ou restructurer le fichier. Chaque cas demande une opération différente. Le système de retrieval porte tout le poids de cette traduction entre la façon dont on parle et la façon dont les outils sont étiquetés. ## Le casse-tête multi-outils. Tout ce qui précède concerne des tâches qui n'ont besoin que d'un outil. Beaucoup de tâches réelles en demandent plusieurs, qui s'enchaînent. Vous voulez lire un PDF, en extraire un tableau, nettoyer les données, et exporter le tout vers un tableur. Cela fait quatre outils, l'un après l'autre. L'agent doit planifier la chaîne complète avant de démarrer. Il doit sélectionner des outils qu'il n'a pas encore utilisés, pour des étapes qu'il n'a pas encore franchies. Le mode de défaillance classique : l'agent termine l'étape 1 puis peine à trouver le bon outil pour l'étape 2. Chaque transition est un nouveau problème de retrieval. Les erreurs s'accumulent d'étape en étape. ## Vers quoi on se dirige. L'industrie commence à prendre la retrieval au sérieux. Quelques directions se dessinent. Première piste : les compétences composables. Au lieu de traiter chaque outil comme une brique isolée, les systèmes permettent de les combiner comme des plugins. Une compétence « lire PDF » se branche à une compétence « nettoyer les données » qui se branche à une compétence « exporter vers un tableur ». L'agent ne fait pas la retrieval de chaque pièce depuis zéro. Il récupère un workflow déjà composé. Des unités petites, ciblées, qui s'emboîtent selon ce que la tâche demande. Deuxième piste : une meilleure organisation, ce que certains appellent un graphe de savoir-faire vivant. Au lieu d'une liste plate de 200 outils, les compétences et les outils sont cartographiés dans un graphe structuré et évolutif de relations. Le graphe capture quels outils sont apparentés, lesquels se composent bien, lesquels couvrent un terrain proche, et comment ils ont performé sur les tâches passées. Le mot-clé est « vivant » : quand une nouvelle compétence est ajoutée, le graphe l'intègre. Quand un outil existant sous-performe ou devient redondant, le graphe se restructure. Il apprend des usages et s'adapte dans le temps. C'est la couche d'infrastructure qui manque à la plupart des plateformes d'agents IA aujourd'hui. Le modèle est le cerveau. Les outils sont les mains. Sans système de retrieval qui joue le rôle d'index intelligent et évolutif, le cerveau continue à attraper les mauvaises mains. Un graphe de savoir-faire bien tenu devient le tissu conjonctif entre ce dont l'utilisateur a besoin et ce que l'agent sait faire. Des plateformes comme [skilder](https://www.skilder.ai/fr) construisent cette infrastructure : **un système où les compétences sont structurées, composables et gouvernées via un graphe vivant que les agents interrogent en temps réel. L'objectif est de transformer la retrieval en couche pilotée et évolutive, plutôt qu'en élément ajouté après coup**. Chez skilder, ces compétences sont regroupées en casquettes (nos `Hat`, au sens technique du produit) : des assemblages propres à un rôle qui réunissent compétences, contexte et permissions, et qu'un agent enfile pour une mission donnée. La prochaine frontière des agents IA n'est pas de les rendre plus intelligents. C'est de leur donner la bonne infrastructure pour trouver, composer et déployer les bonnes compétences au bon moment. **La retrieval est la nouvelle intelligence.** --- Source: https://www.skilder.ai/fr/blog/skills-arme-secrete-agents-ia # Skills : l'arme secrète des agents IA plus malins > Les Agent Skills sont des jeux d'instructions modulaires qui étendent les capacités d'une IA. Anatomie d'un SKILL.md, activation, et comment construire le vôtre. Language: fr · Category: product · Author: Nicolas Corod (Produit) · Published: 2026-01-11 ## Qu'est-ce qu'un agent skill. Imaginez donner à votre assistant IA une « antisèche » pour des tâches précises. C'est, en substance, ce qu'est un [Agent Skill](https://claude.ai/) : un jeu d'instructions structuré qui apprend à une IA à traiter un type de demande avec expertise et cohérence. Au lieu d'espérer que l'IA devine le format que vous préférez pour vos rapports ou retienne les conventions de code de votre entreprise, vous encodez ces exigences dans un skill. L'agent le lit dès qu'il est pertinent, et chaque sortie correspond à vos attentes. Imaginez recruter un spécialiste. Un généraliste rendra un travail correct, mais un spécialiste qui dispose de bonnes pratiques documentées livre un résultat excellent, à chaque fois. Un skill, c'est précisément ce dossier de bonnes pratiques que l'agent ouvre avant de produire quoi que ce soit. Une précision utile avant d'aller plus loin : chez skilder, plusieurs skills sont assemblés dans une **casquette** (en anglais : `Hat`). La casquette est la couche métier visible côté utilisateur, celle que vos collaborateurs choisissent (« Assistant juridique », « Analyste financier », « Chargé de support N1 »). Les skills, eux, sont les briques techniques que la casquette mobilise en coulisse. Vous pouvez voir le skill comme la compétence atomique, et la casquette comme le rôle qui l'orchestre. On revient sur ce lien en fin d'article. ## L'anatomie d'un agent skill. Tout skill suit une structure prévisible. Voici ce que contient le dossier : ``` skill-folder/ ├── SKILL.md # Fichier d'instructions principal ├── references/ # Documentation de support │ ├── templates.md │ └── examples.md └── assets/ # Images, templates, échantillons └── template.docx ``` Le fichier `SKILL.md` est le cerveau de l'opération. Il contient tout ce que l'agent a besoin de savoir. ## La structure d'un SKILL.md, en détail. Un `SKILL.md` bien rédigé suit ce format : ```markdown --- name: document-creator description: Crée des documents professionnels selon les standards de l'entreprise --- # Skill créateur de documents ## Contexte et objectif Quand utiliser ce skill et quels problèmes il résout. ## Étapes du workflow Processus pas-à-pas que l'agent doit suivre. ## Règles et contraintes Limites strictes, exigences de format, choses à éviter. ## Exemples Exemples d'entrées et de sorties attendues. ``` Chaque section a un rôle précis : **Frontmatter (name + description) :** aide l'agent à savoir quand ce skill s'applique. Une description claire améliore le matching de contexte. **Contexte et objectif :** explique le « pourquoi » du skill. À quel moment l'agent doit-il l'activer ? Quels résultats comptent ? **Étapes du workflow :** le cœur procédural. On déroule chaque étape, dans l'ordre. **Règles et contraintes :** les garde-fous. Que l'agent ne doit-il jamais faire ? Quel format est obligatoire ? **Exemples :** montrer plutôt que décrire. Des exemples concrets éliminent l'ambiguïté. ## Comment un skill s'active. Le flux d'activation est direct : 1. **Demande utilisateur :** quelqu'un sollicite l'agent (« Rédige le rapport trimestriel »). 2. **Matching de contexte :** l'agent scanne les skills disponibles et identifie ceux qui correspondent, à partir de la description. 3. **Lecture du skill :** avant d'agir, l'agent lit le `SKILL.md` complet. 4. **Exécution du workflow :** l'agent suit les étapes documentées pour produire la sortie. Tout cela se fait automatiquement. L'utilisateur n'a pas à invoquer un skill explicitement : le matching s'opère sur la base du contexte. C'est ce qui distingue un skill d'un simple prompt collé en début de conversation. Le skill vit dans un dossier, il est versionné, partagé entre équipes, et il s'active uniquement quand il est pertinent. Vous ne polluez plus chaque conversation avec un long préambule ; vous laissez l'agent piocher la bonne fiche au bon moment. ## Cas d'usage concrets. **Création de documents :** définissez les templates, les règles de mise en forme et la structure des sections. Chaque rapport suit la même charte. **Génération de code :** encodez le style guide, les conventions de nommage et les patterns d'architecture de l'équipe. Fini les pull requests inégales. **Rédaction de contenu :** précisez le ton, la structure, l'audience cible et les exigences SEO. La voix de marque reste constante d'une sortie à l'autre. **Analyse de données :** documentez vos styles de visualisation, vos méthodes statistiques et vos formats de reporting préférés. **Support client :** créez des skills pour les scénarios récurrents, avec réponses validées et critères d'escalade. ## Construire votre premier skill. Commencez simplement. Choisissez une tâche répétitive pour laquelle vous redonnez sans cesse les mêmes consignes. Voilà votre premier candidat. Voici un exemple minimal fonctionnel : ```markdown --- name: meeting-notes description: Met en forme les notes de réunion avec actions et décisions --- # Skill notes de réunion ## Objectif Transformer une transcription brute en notes structurées. ## Workflow 1. Extraire les points clés discutés 2. Identifier les décisions prises 3. Lister les actions, avec responsable et échéance 4. Mettre en forme avec le template standard ## Règles - Toujours indiquer la date et les participants - Chaque action doit avoir un responsable - Résumé inférieur à 200 mots ## Exemple de sortie ### Réunion : planification T1 **Date :** 2024-01-15 **Participants :** Alice, Bob, Carol **Décisions :** - Budget validé pour les nouveaux outils **Actions :** - [ ] Alice : remettre le comparatif fournisseurs avant le 20 janvier - [ ] Bob : planifier les démos finalistes avant le 25 janvier ``` ## Ce qui fait un skill efficace. Les meilleurs skills partagent quelques traits : **Spécifique plutôt que général.** Un skill « écrire des emails » est trop large. Un skill « écrire les emails de relance après une démo commerciale » est actionnable. **Frontières claires.** Définissez ce que le skill fait ET ce qu'il ne fait pas. L'ambiguïté crée l'incohérence. **Exemples concrets.** Les consignes abstraites s'interprètent. Les exemples posent la vérité de terrain. **Itération continue.** Votre première version ne sera pas parfaite. Mettez les skills à jour en fonction de la qualité observée, et traitez le `SKILL.md` comme du code : revue, versionnement, changelog. Les meilleurs skills d'une équipe sont souvent ceux qui ont été retravaillés trois ou quatre fois après une mise en production. ## Skills, casquettes, et gouvernance. Si vous opérez à l'échelle d'une entreprise, la question suivante arrive vite : qui écrit les skills, qui les valide, qui les voit ? C'est exactement pour cela que la casquette existe au-dessus du skill. Le skill est une compétence technique, granulaire ; la casquette est un rôle métier, une combinaison de skills, de contexte et de permissions, validée par l'organisation. Concrètement : votre service juridique peut maintenir un skill « relecture de NDA » et un skill « clauses RGPD », et votre équipe RH peut assembler une casquette « Onboarding » qui mobilise ces deux skills, plus un troisième sur la rédaction de contrats de travail. Chaque skill évolue dans son coin ; la casquette, elle, est l'objet contractuel que le collaborateur enfile et que la DSI audite. Cette séparation a un effet pratique : vos meilleurs prompts cessent de vivre dans des onglets, des Notion privés ou des Slack DM. Ils deviennent des artefacts partagés, mesurables, et réutilisables d'une équipe à l'autre. ## À retenir. Les Agent Skills transforment un assistant IA générique en un spécialiste calé sur vos besoins. Ils sont simples à créer, faciles à maintenir, et améliorent nettement la cohérence des sorties. La structure est standardisée : un dossier avec `SKILL.md` au cœur, plus des références et des assets optionnels. L'agent associe lui-même les skills aux demandes, par le contexte. Chez skilder, les skills individuels sont regroupés en casquettes (en anglais : `Hat`) : des assemblages tournés métier qui combinent skills, contexte et permissions, et que l'agent enfile pour une mission donnée. Là où le skill est la brique, la casquette est le rôle. **Étape suivante :** identifiez une tâche que vous répétez chaque semaine. Documentez le processus idéal dans un `SKILL.md`. Vous verrez vos sorties IA gagner en régularité, vite.