SkillSmithAn Agent’s “External Brain”—
Built for Real Productivity

Why Traditional Skill Invocation Wastes Context

Traditional Raw-Skills invocation is straightforward: once the system determines that a task requires a skill, it gives the complete skill package to the model and lets the model read and interpret it.

This works for small-scale tasks, but creates three problems under frequent use.

First, large amounts of content unrelated to the current task still enter the model context. Our analysis of original skill execution traces from representative tasks shows that an agent loads approximately 17.8K source tokens per invocation on average, and about 51.21% of them are never referenced later in the execution trace.

Second, when the same skill is invoked repeatedly, the model repeats similar interpretation and planning work. Many steps are stable—reading inputs, calling scripts, filling templates, and validating output—yet the conventional approach asks the model to reinterpret them online every time.

Third, the more complex the skill package, the more the model must identify key information within a long context. For tasks whose workflows are already stable, this creates unnecessary model calls and cost pressure.

SkillSmith: Define the Boundary First, Invoke It at Runtime

SkillSmith’s core idea is simple: do not make the agent reread the entire manual for every task. Compile the skill in advance into a clearly bounded interface.

This interface is called a Boundary Contract. It records what a skill can reliably provide at runtime, what inputs it requires, what outputs it produces, which execution constraints apply, how results should be validated, and how the system can fall back to the original materials when the interface is insufficient.

A Boundary Contract plays a role similar to API documentation. The agent does not need to load the complete skill package at the outset. It first sees a compact skill summary. Once it determines that the skill is needed, the system progressively reveals the relevant operations, policy constraints, and fallback materials.

The method overview illustrates SkillSmith’s complete flow: offline compilation on the left organizes a skill package into a Boundary Contract; runtime invocation on the right allows the agent to select interfaces, execute operations, obtain guidance, or fall back to the original materials as needed.

Different Skills Require Different Compilation Strategies

Real-world skill packages vary widely in form. SkillSmith does not force every skill into one fixed workflow. It first identifies the skill’s natural structure.

Common structures include:

After compilation, all of these skills are exposed to the runtime through a consistent Boundary Contract. Their original structures are preserved, while the agent sees an interface that is clearer, smaller, and easier to invoke.

Three Runtime Outcomes: Execute, Guide, or Fall Back

SkillSmith does not turn a compiled skill into an opaque black box that attempts to handle everything. It functions as a constrained skill runtime layer.

After the agent selects a skill, the runtime uses the Boundary Contract and the current task to choose among three outcomes:

Execute: When conditions are clear and policy allows it, execute a typed operation or script directly.

Guidance: When the current situation still requires model judgment, return relevant guidance and reference information.

Fallback: When the interface does not cover the request or policy prohibits direct execution, return to the original skill materials.

This distinction matters. Real-world tasks often involve file formats, external tools, semantic judgment, human preferences, or security policies. A system must know what it can do, what it cannot do, and when control should return to the agent.

Key Results: Fewer Tokens, Less Time, and Fewer Iterations

Across seven representative tasks, completing the work directly with original skill packages requires approximately 1.5 million tokens, 999 seconds, and 107 reasoning iterations.

With SkillSmith, the same tasks require approximately 620,000 tokens, 494 seconds, and 61 reasoning iterations.

The end-to-end results compare Raw-Skills, SkVM-Compiled Skills, and SkillSmith across tokens, time, and reasoning iterations. The primary benefit of SkillSmith comes from reducing the context and reasoning repeatedly spent interpreting skills at runtime.

These figures do not imply that every task will improve by the same fixed percentage. SkillSmith is most effective for tasks with relatively stable workflows, substantial skill materials, and frequent invocation.

Compile with Stronger Models, Invoke Frequently with Economical Models

SkillSmith also supports a practical separation between compilation and runtime execution.

For important, frequently used skills, a more capable model can organize skill boundaries during the offline phase. At runtime, a more economical model can invoke the resulting interfaces. This shifts part of the cost of “understanding the skill manual” from online execution to offline compilation. This does not mean that smaller models can replace stronger models without conditions.

More precisely, stronger models can help distill skill structure, while economical models can handle more frequent execution when given clear interfaces.Cross-model results support this finding: once skill structure has been compiled in advance, different runtime models can reduce part of their online interpretation burden through a clearer interface.

Use Cases

The most direct value of SkillSmith is that it allows an agent performing repeated professional work to behave more like an experienced employee: learn the workflow clearly once, then avoid rereading the manual from the beginning every time a similar task appears.

Limitations

SkillSmith is not universal. If a skill package is incomplete, outdated, or highly dependent on a specific environment, the compiled interface will inherit those problems. Changes to tool versions, file formats, dependencies, or execution policies also require renewed validation or recompilation.

SkillSmith primarily reduces the cost of repeatedly interpreting a skill. It cannot eliminate every task cost. External tool execution, file I/O, video processing, complex semantic judgment, and human-preference decisions still take place at runtime.SkillSmith makes reusable skills more efficient, more explicit, and easier to control. It does not automatically make every task simple.

Conclusion

Once agents enter production, the bottleneck is not only model capability. It is also how we provide models with knowledge, tools, and workflows.

Many traditional skill systems resemble handing an agent a complete manual and asking it to read, interpret, and break down the steps again every time. SkillSmith compiles the stable, reusable, and executable parts of that manual into clearly bounded interfaces. At runtime, the agent reads less irrelevant content and spends more of its budget where judgment is truly required.

Turning agents into real productivity tools requires more than larger models. It also requires a better way to organize skills.