AI-Native Organisations Run on Skills: How to Structure and Scale Them — Imad Touil, QuantumBlack

The hands drop as the questions get harder. Who has created and used skills? Who shares them with a team? Who governs and maintains them across an organization? Imad Touil, a distinguished engineer at QuantumBlack, sees only a few hands left for the last question. That gap sets up the practical problem: a useful procedure on one engineer’s machine still needs a way to become shared, maintained organizational knowledge.

The agentic software stack has two loops in Touil’s model. The inner loop is the coding agent and its harness—the runtime that manages context, tools and MCP connections, memory and state, and skill loading. The outer loop is the workflow that arranges skills, sub-agents, MCP servers, and hooks around the work. These layers serve different purposes: the harness supplies execution machinery, while the workflow shapes how that machinery behaves for a particular job.

Supporting infrastructure makes those loops usable across an organization. A sandbox supplies the execution environment. An MCP gateway manages tool access, and a model gateway manages and optimizes access to local or frontier models. A knowledge graph represents core IT systems, code, and shared registries. The context layer then brings the task’s ingredients together: project instructions, tool schemas that explain what can be called, conversation history, and retrieved files or code. Skills operate inside this larger system; they do not replace its tools, runtime, or context.

The familiar coding-agent sequence is straightforward: specify what to build, plan the design, break the work into tasks, and implement them. At organizational scale, that sequence builds a product increment. It sits inside a much longer journey from deciding what the business needs to operating something customers can use.

Product strategy comes first: define success metrics and a roadmap, using market research, competitive analysis, and customer interviews as inputs. Discovery turns that direction into problem statements, possible solutions, validation, experiments, and user stories. Those steps determine whether the proposed implementation is worth doing before a coding agent starts producing it.

Even then, development may depend on data work. A team might need to clean its data catalog, adjust endpoints or integrations with core systems, build a data pipeline, and validate data quality. Preparing those assets makes the product increment possible. After implementation, platform engineering supplies infrastructure and infrastructure-as-code modules; launch starts another phase of performance optimization and incident resolution, feeding the next cycle.

There is also more than one software development lifecycle within a company. Mobile applications, internal employee platforms, customer-facing products, and different departments can require different workflows. A universal workflow would have to absorb all those differences. Touil instead treats the organization as a collection of lifecycles, each with procedures that can be made explicit and shared where appropriate.

Within the workflow, Touil assigns four components distinct jobs:

• Hooks: Trigger actions at events along the workflow.
• MCP servers: Expose tools, often supplied by products the organization already uses.
• Sub-agents: Execute delegated tasks in separate contexts, reducing pressure on the main context window.
• Skills: Carry the organization’s know-how about how a task should be performed.

This division explains why connecting tools and delegating work can still leave a workflow underspecified. The agent needs the procedure as well as the means to act.

Workflows are “harness blueprints”: they shape the coding harness’s behavior at runtime. Skills make those blueprints more explicit by supplying repeatable task instructions and, where needed, scripts. Touil describes the intended result as deterministic. The supported mechanism is narrower: reusable instructions constrain the work, and a saved script can perform a specific operation consistently; neither establishes that every model decision or complete workflow result will be identical.

The adoption story moves from Anthropic’s introduction of skills to an open standard and uptake across agent harnesses. Touil’s snapshot of public repositories and registries illustrates growing creation, while his benchmark discussion reports better software-engineering and cybersecurity task outcomes with skills than without them. The comparison supplies motivation rather than an effect size: no scores or experimental conditions are given here, so it cannot tell a team how much improvement to expect on its own tasks.

The engineering problem looks familiar from microservices: many small capabilities need to remain understandable and useful together. A skill should describe one specialized task rather than grow into a monolith of everything an agent might need. Smaller responsibilities make it easier to reuse the procedure and combine it with other procedures without duplicating or conflicting instructions.

Several design properties work together:

• Reuse and modularity: Package a task so another team can use it without recreating the same procedure.
• Discovery: Make the skill findable by the team or agent that needs it.
• Portability: Use the shared standard to carry skills across workflows and supporting harnesses; Touil uses moving from Claude Code to Cursor as his example.
• Composition: Design responsibilities so multiple skills can run together without overlapping rules that fight each other.
• Consistency: Preserve a repeatable method for performing the task instead of asking every engineer to steer the agent from scratch.

Cost efficiency comes from progressive disclosure: bring in the relevant skill, in the amount needed, at the point when the task needs it. Loading an organization’s whole procedural library into every context would consume tokens regardless of relevance. Selective loading makes the library available without making every task carry all of it. Touil’s aim is to make organizational know-how executable and portable while reducing the context cost of using it.

A data-retention policy makes this concrete. When an agent manipulates customer data, it needs instructions about the applicable retention rules. That procedure is specialized enough to become one skill. It can then be reused wherever customer data is handled, rather than being rediscovered through a new conversation for each application.

The retention-policy example expands into a regulatory disclosure review. Retention is only one responsibility. The catalog also contains disclosure standards, GDPR rules, and fill-in templates. A workflow pulls these skills at runtime so that a feature handling data can be reviewed against the relevant procedures across web, mobile, and other applications.

The visible change is in what the workflow produces: a storable audit report and identified improvements that can feed back into the codebase. The causal sequence is cataloged rules, runtime composition, review, then actionable output. The report gives the review a persistent result; the improvement findings connect it to development rather than leaving it as a separate compliance exercise.

How do separate policy skills become one review with a feedback path? The diagram shows the shared workflow as the meeting point for four specialized inputs. Its two outputs have different destinations: preserve the report, and use the findings to improve the code. Composition lets the rules stay separately maintained while contributing to the same task.

Once teams build skills independently, reuse can fail before anyone notices. Teams on the same stack and infrastructure recreate the same procedures. Meanwhile, a skill that worked for its original task can age as models change. Maintaining quality therefore requires testing against both the intended task and newer models, rather than treating the first successful run as permanent validation.

Discovery and ownership are linked. Touil invokes Backstage and the internal developer portal: a service catalog lets an engineer find who owns a microservice without asking around. A skills catalog needs the same property. Finding the procedure is useful; finding the person responsible for fixing and maintaining it makes reuse sustainable. Composition also needs coordination over task responsibilities and domains, because publishing several skills does not automatically make them work together.

Security has two separate mechanisms to address:

• Imported instructions and scripts: Public skills can contain prompt injection or insecure scripts. Because a skill can execute a script for a task, bringing one into the environment requires a checking pipeline for executable content as well as instructions.
• Sensitive business logic: Some internal skills encode knowledge that everyone in the organization should not access. Access control must govern who can retrieve and use those procedures.

Adoption starts locally. Individuals need an agreed, structured way to create, test, improve, and use skills. Sharing with the team comes next, allowing people working on the same products and stack to refine the procedure together. The centralized platform then makes that work available beyond the originating team.

The platform needs several capabilities with distinct jobs:

• Searchable catalog and metadata: Help agents and engineers discover relevant skills. Touil proposes an MCP interface for catalog search and a CLI for pulling skills into an IDE or sandbox.
• Dependencies: Record relationships between skills so the platform can account for what a procedure needs.
• Versioning and lifecycle: Identify current releases and let an agent detect and retrieve an updated skill while building a feature.
• Access control: Make it possible to understand and govern who accesses which skills.
• Evaluation and observability: Keep quality assessment and operational visibility alongside distribution.

The hard question arrives after those capabilities exist: who governs them? Architecture leads, infrastructure leads, and cybersecurity leads need to own appropriate domains and ensure updates follow organizational policies. The precise assignment depends on the company’s structure. A platform can distribute a release; people must decide what belongs in it and what changes are acceptable. This is where, in Touil’s phrasing, technology stops solving the problem.

What makes reuse become shared improvement rather than one-way downloading? The circulation below connects a maintained catalog to local execution and contributions back. Teams pull shared skills, use them, and return improvements. Named domain owners provide the policy responsibility around that circulation.

Touil illustrates the organizational effect with a simulation of fifteen teams over six months. Its inputs include engineers’ skill contributions, average daily utilization, duplication between teams, and quality and security ratios. It illustrates uneven productivity, cost, and implementation quality under different maintenance practices; it is a constructed scenario rather than measured evidence of a six-month organizational deployment.

The regulatory example explains the cost mechanism behind the scenario. Without a maintained procedure, a human repeatedly steers the agent toward the required rules—“vibe coding back and forth.” Each correction consumes time and tokens, and the outcome depends on that person’s knowledge. A reusable regulation skill supplies the procedure upfront, reducing the need to reconstruct it during every implementation.

The governed scenario changes what happens when the next engineer tries to create a skill. Once a shared skill is published, the coding harness can discover that it already exists and pull it. Discovery interrupts duplication at the moment it would otherwise begin. Teams gain common procedures even while their work remains different.

The same approach must extend to complete workflows. Skills are only one component. An engineer who needs to provision infrastructure should be able to retrieve a workflow with its required skills, run and test it, and return improvements to the centralized platform. That shares the arrangement of the work as well as the individual procedures it uses.

The closing recommendations begin with a skills registry. Touil points to internal developer portals as a familiar place for centralizing this capability, alongside tools dedicated to skills. The practical requirement is a shared place to discover and maintain procedures; the product choice can follow the organization’s existing platform.

Evaluation remains an open design question. A useful starting point is linting or static checks against Anthropic’s skill best practices, looking for structural and invocation problems. A poorly structured skill may be hard for an agent to use; a skill that is not invoked appropriately cannot improve the intended task. These checks complement the earlier requirement to validate task performance and retest as models change.

Auto-evolving skills raise the stakes. A closed loop can keep changing procedures automatically, but Touil’s response to the promise is blunt: “So what?” The earlier maintenance problems still apply, now with a machine accelerating the changes. Ownership, evaluation, security checks, and organizational policies need to govern that loop. Otherwise, the organization is simply maintaining automatically changing skills without a way to keep their evolution aligned with its needs.