Skills contain much of an organization's reusable know-how and make workflows more deterministic.
2
Without governance, teams duplicate skills, quality declines as models change, ownership stays unclear, and security risks enter through scripts and permissions.
3
A central skills platform needs a searchable catalog, dependencies, versioning, access control, evaluation, observability, and named owners across technical domains.
Summary
Imad Touil argues that skills are where an AI-native organization's practical know-how becomes executable. He places them inside a larger agentic stack with workflows, hooks, MCP servers, subagents, and context management, then explains why those other components do not capture enough reusable structure. Skills can define specialized tasks, compose across workflows and harnesses, reduce context usage through progressive disclosure, and apply rules such as data-retention and GDPR requirements. Without governance, teams create duplicate skills, lose track of ownership, allow quality to decay as models change, and risk importing insecure scripts. Touil proposes a central platform with search, metadata, dependencies, versions, access controls, evaluation, and observability. Architects, engineering leads, infrastructure leads, and security leads must own different parts of the system. He also argues that the same approach should later cover complete workflows and support skill evaluation and controlled auto-evolution.
Skills contain the know-how that makes workflows deterministic
Touil separates the agentic stack into an inner loop and an outer loop. The inner loop includes the coding harness, context manager, tools, MCPs, memories, states, and a skills loader. The outer loop contains workflows, skills, subagents, MCP servers, and hooks. Hooks respond to events, MCP servers provide tools that teams often consume rather than build, and subagents mainly delegate work to protect the context window. He says the reusable know-how ends up at the skills level. If skills lack structure, the workflow does not have a deterministic basis. He describes workflows as harness blueprints that shape how a coding harness behaves at runtime.
A product increment is only one step in a much larger delivery lifecycle
The familiar sequence of specify, plan, break work into tasks, and implement covers only a product increment. Touil expands the lifecycle to include product strategy, success metrics, roadmaps, market research, competitive analysis, customer interviews, discovery, solution validation, experiments, and user stories. Teams also need to prepare data, clean or adjust catalogs, and connect core systems before development. Data product delivery includes pipelines, data-quality validation, and cataloged assets. After the increment, platform engineering provisions infrastructure, launches the product, handles incidents, and optimizes performance. The lifecycle starts again after launch.
Organizations run several different delivery lifecycles
Touil says an organization does not have one workflow that can build everything. He has seen separate delivery lifecycles for mobile applications, departments, platforms, employee-facing systems, and customer-facing products. Each may have different systems, constraints, and operating practices. The larger the digital platform, the more complex the overall delivery landscape becomes. He estimates that the lifecycle shown in his talk represents only part of what an organization may need, and says the exact shape differs from one organization to another.
Skills should follow software design principles from the microservices era
Touil applies familiar software design ideas to skills. They should be reusable, modular, discoverable, portable across workflows and agent harnesses, specialized for a defined task, and composable without duplication or conflicts. He also expects consistency, deterministic behavior, and sensible context costs. A skill should not become a monolith that tries to do everything. Touil says the shared standard makes it possible to move a skill between harnesses such as Cloud Code and Cursor. He describes skills as a unit that makes organizational know-how executable, portable, and less expensive to place into a model context.
Progressive disclosure puts only the needed skills into the context
Skills address a context-window problem through progressive disclosure. Touil describes the goal as placing the right skills, in the right amount, at the right time for the task. This avoids loading every available instruction into the context and reduces token usage. The skill remains available as a reusable definition rather than being rewritten inside each workflow. He connects this cost benefit to the wider design requirements for skills, where specialization and composition help a harness select a focused set of instructions.
Composable regulation skills can produce an audit trail
Touil uses data retention as an example of a regulation skill. A workflow handling customer data can pull a retention-policy skill together with disclosure standards, GDPR rules, and fill-in templates. A regulatory disclosure review workflow then applies those components during runtime. The expected output includes an audit report and an identification of anything that needs improvement. That feedback can go back to the codebase. The example shows how organizations can encode rules once and apply them across web, mobile, and other applications instead of relying on each person to steer an agent manually.
Ungoverned skills create familiar forms of technical debt
Without governance, teams using the same technology stack will build the same skills repeatedly. Quality declines when skills are not tested and maintained against newer models as well as their original tasks. People cannot reliably discover a skill or find its owner. Composability also needs coordination because independently designed skills can duplicate work or conflict. Security adds another risk: skills can contain scripts, and a public skill may include prompt injection or insecure code. Touil compares a skills catalog with an internal developer portal, where users can find ownership and maintenance information for a service. Permissions are also needed because some skills contain sensitive business logic.
A central skills platform needs both technical controls and human ownership
Touil proposes a progression from individual creation to team collaboration and then to a centralized platform. The platform should provide searchable metadata, an MCP connection for finding skills, and a CLI for pulling them into an IDE or sandbox. It should track dependencies, versions, lifecycle state, access, evaluation, and observability. When a newer version exists, a harness can pull it from the registry. Governance then assigns responsibility to architects, engineering leads, infrastructure leads, and security leads, each covering the policies in their domain. Touil is direct that technology cannot decide who governs the system. People must own that work.
Governance can reduce duplication across teams, but it does not solve every workflow problem
Touil describes a simulation with 15 teams, between five and 12 engineers per team, skill contributions, daily usage, duplication, quality, and security measures over six months. In the ungoverned case, teams create and use skills without shared visibility. A missing regulation skill can make engineers repeatedly guide an agent, increasing token use and time spent. Team maturity also differs, so quality and security vary. In the governed case, a published skill becomes visible to later engineers, and their harness can find and reuse it. Touil then extends the same central-platform idea to complete workflows, which teams can discover, run, test, improve, and publish.
"If you don't have the right structure of your skills then you're not really having a deterministic workflow."06:44
Who should watch
You are building agent workflows across several teams and need a way to reuse instructions instead of recreating them.
Your skills contain scripts, regulatory rules, or sensitive business logic, and you need ownership, security checks, and access controls.
You run an internal developer platform and want to extend its catalog, versioning, and evaluation model to agent skills and workflows.
