Stop Stacking Agents: The Technical Case for Reusable Skills

1. Background: The Real Conflict After Agents Move from Demos to Production

Early agent development often followed a “one agent per scenario” path: one for finance, one for operations, one for data analysis, each with its own tools, prompts, and orchestration logic. This approach can show results quickly in demos, but once it enters production, problems surface fast: similar capabilities are built repeatedly, tool permissions are scattered, execution is hard to audit, failures are hard to reproduce, and a version upgrade can affect the entire system. On the surface, the team has multiple agents; in practice, it maintains multiple fragile and non-reusable processes.

As standardized context protocols, AI coding tools, and agent development kits mature, the industry is entering a new stage. Models are no longer just “interfaces that generate text”; they are deeply integrated with file systems, code execution environments, data access interfaces, logs, and monitoring systems. The key question is no longer “Can the model call tools?” but “How can model capabilities be organized into reusable, testable, and governable engineering assets?”

An important turning point comes from AI coding practice. Teams have found that code is not only the input and output of programming scenarios; it is also a general interface to the digital world. Data reading, file organization, format conversion, rule validation, and service calls can all ultimately be completed through code or a controlled execution environment. In other words, AI coding tools themselves can be viewed as a general-purpose executor. Consider financial report generation: the model can call a general data access interface to retrieve and analyze data, organize intermediate results in the file system, then generate a report from a template and run validation. What really needs to be reused in this process is not the shell called “financial report agent,” but a set of clearly bounded skills such as data retrieval, cleaning, aggregation, validation, and report rendering.

2. Core Judgment: Agents Orchestrate, Skills Execute Deterministically

“Stop building agents” does not mean abandoning agents. It means shifting the center of gravity from pursuing the number of agents to accumulating skill assets. A more reasonable layering is:

• Agent layer: Understands goals, decomposes tasks, selects skills, handles exceptions, and decides whether human confirmation is needed.
• Skill layer: Encapsulates an operation with a clear boundary, explicit input/output contract, and independent testability and reusability.
• Runtime layer: Provides file systems, code execution, network access, data interfaces, permission sandboxes, audit logs, and resource limits.
• Context protocol layer: Describes available skills, parameter constraints, return results, and error semantics in a standardized way, reducing coupling between models and the runtime environment.

In this layering, agents are more like “schedulers,” and skills are more like “standard parts.” Schedulers can be replaced as model capabilities improve, while standard parts can be reused across different agents and business processes. The underlying execution capabilities are often more general than expected: reading data, converting formats, running validation, writing to storage, generating summaries, and calling services. These capabilities do not inherently belong to a specific business domain; they are foundational operations of the digital world.

3. Why Skill Abstraction Scales Better: Five Engineering Benefits

1. Significantly better reuse. Once “read a class of data and validate completeness” is abstracted into a skill, financial reporting, operations dashboards, and audit sampling can all reuse it instead of rebuilding the toolchain for each scenario.

2. Stronger testability. An agent’s planning path is uncertain, but a skill can have an explicit input/output contract. Teams can write unit tests, contract tests, and regression cases for skills, confining uncertainty to the orchestration layer.

3. Clearer permission boundaries. A skill can declare the minimum permissions it requires, such as read-only data access, restricted directory writes, or no external network access. Compared with exposing a large set of tools directly to an agent, skill-level permissions are easier to audit.

4. More complete observability. Each skill invocation can record an input summary, output summary, latency, error code, and resource consumption, forming a traceable execution chain. When a problem occurs, it can be traced to a specific skill rather than an entire natural-language process.

5. Better composability. Complex tasks can be completed by composing skills, with the orchestration layer selecting skill sequences based on context. Skill versions can be upgraded, rolled out gradually, and rolled back independently, reducing overall system change risk.

4. Reference Architecture and Illustrative Code

A practical skill-based architecture usually includes skill registration, contract descriptions, runtime context, execution sandbox, result validation, and audit logs. The following pseudocode illustrates a skill interface without binding to any specific platform or product:

interface Skill {
  name: string;
  description: string;
  inputSchema: JSONSchema;
  outputSchema: JSONSchema;
  requiredPermissions: string[];
  run(ctx: RuntimeContext, input: unknown): Promise<SkillResult>;
  verify(result: SkillResult): ValidationReport;
}
interface RuntimeContext {
  workspace: Workspace;
  dataAccess: DataAccess;
  logger: AuditLogger;
  sandbox: ExecutionSandbox;
}
// Register a skill: capability description and permission constraints are versioned with the skill
runtime.registerSkill({
  name: "summarize_dataset",
  description: "Run aggregation and outlier checks on a structured dataset",
  inputSchema: datasetSummaryInput,
  outputSchema: datasetSummaryOutput,
  requiredPermissions: ["data:read", "workspace:write"],
  async run(ctx, input) {
    const data = await ctx.dataAccess.read(input.datasetRef);
    const summary = aggregateAndValidate(data, input.rules);
    await ctx.workspace.write(input.outputPath, summary);
    return { ok: true, summary };
  },
  verify(result) {
    return validateAgainstSchema(result, datasetSummaryOutput);
  }
});

The agent side no longer directly holds a large number of low-level tools. Instead, it discovers skills through a standardized context, reads their contracts, and selects them for invocation. The skill side handles deterministic execution and self-validation. In this way, model capability upgrades do not break skill implementations, and skill upgrades can be managed through versioning and evaluation systems.

5. Adoption Path: Extract Skill Assets from High-Frequency Tasks

A recommended sequence is:

1. Inventory high-frequency operations: Identify repeated actions in existing processes, such as data reading, format conversion, validation, rendering, and notification.
2. Define contracts: For each skill, specify inputs and outputs, error codes, permissions, timeouts, and resource limits. Avoid “do-everything” skills.
3. Build a skill repository: Manage skills by domain and capability tags, and record versions, dependencies, evaluation results, and consumers.
4. Integrate runtime governance: Unify sandboxes, logs, monitoring and alerting, auditing, and quotas so that skill invocations are traceable and rate-limitable.
5. Build evaluation sets: Prepare normal, boundary, and exception cases for critical skills, and include regression testing in the release process.
6. Gradual rollout and rollback: Release skill versions independently, start with small-traffic agents, and then expand gradually.

When deploying on cloud infrastructure, runtime foundations can be built from general object storage, logging services, monitoring and alerting, and container platforms, but the core principles remain unchanged: skills are assets, agents are orchestration, protocols provide decoupling, and governance is the baseline.

6. Risks and Boundaries

Skill abstraction is not a silver bullet. If skills are too fine-grained, orchestration becomes complex; if they are too coarse-grained, reusability decreases. Loose contract design can leak uncertainty into the execution layer, and overly broad permission declarations can weaken the value of sandboxing. Teams should therefore adhere to the principles of “single responsibility, explicit contracts, least privilege, verifiable results, and rollback-capable versions.” At the same time, retain human confirmation and approval paths for high-risk operations, and add data masking and access auditing for skills that involve sensitive data.

7. Conclusion

The industry is moving from “stacking a dedicated agent for every scenario” to “using a general runtime to host reusable skills.” Code serves as a general interface to the digital world, enabling models to complete real tasks through controlled execution environments; standardized context protocols reduce coupling; and skill abstraction leaves uncertainty to the orchestration layer while consolidating determinism, testability, and governance in the execution layer. For teams, the real competitive advantage is no longer how many agents they have, but whether they can continuously accumulate high-quality, composable, and auditable skill assets to support the scaled evolution of agents in production.