Skills as Tool Gates: A Better Way to Scale AI Agent Context

A technical case study of NanthAI:Edge.

Most AI agents scale the wrong way: every new capability adds more prompt text, more tool schemas, and more chances for the model to choose badly. In NanthAI:Edge, this is not just a theory. The current visible skill catalog is about 5.1k tokens as metadata, compared with about 67k tokens for the full visible skill bodies. The base registry exposes 4 tools, compared with 115 in the fully expanded registry. That does not prove better task success, but it does prove the context surface is radically smaller.

Abstract

Tool-using large language model (LLM) agents face a structural tension between capability breadth and context economy. Every additional workflow instruction and every additional tool schema injected into the model context consumes tokens, increases latency and cost, and can make tool selection less reliable. This article develops the design pattern of progressive skill-gated tool access, in which a compact, cache-stable catalog of skills mediates both on-demand instruction loading and incremental expansion of the executable tool registry.

A skill is treated as a modular, discoverable instruction package with metadata, full behavioural guidance, and declared tool-profile requirements. Rather than injecting all skills and all tools into every request, the system first exposes lightweight skill metadata; the model invokes load_skill when a task matches a skill; loaded skills then inject detailed instructions and activate the relevant tool profiles.

The article positions this pattern against literature on prompt bloat, function-calling scalability, retrieval-based tool selection, prompt caching, progressive disclosure, and modular agent architecture. It then analyzes NanthAI:Edge as a concrete case study using implementation details provided by the system author. NanthAI:Edge organizes capability through three layers: account tier, skills, and executable tools. The article explains expected benefits, central risks, and the implementation tradeoffs of this architecture.

Summarised tool-registry workflow, as gated by skills

1. Introduction

Modern agentic LLM systems are typically constructed by composing three kinds of context into each request: system instructions, tool schemas, and conversation state. As agents accumulate capabilities, each layer tends to grow. New workflows add new prompt instructions. New integrations add new tool schemas. New user preferences and memories add more context. The resulting system is capable, but increasingly heavy.

This creates two related problems:

1. Prompt bloat occurs when the system prompt accumulates extensive behavioral instructions, policies, workflow guidance, examples, memory, and contextual rules.
2. Tool-registry bloat occurs when many executable tools are exposed to the model regardless of whether they are relevant to the current task.

Both are expensive. They consume input tokens, raise latency, increase provider cost, and complicate prompt caching. More importantly, they may degrade decision quality. A model asked to select among dozens or hundreds of tools must compare more candidates, attend over more descriptions, and resolve more semantic overlap.

Recent work on retrieval-augmented tool selection supports this concern. Gan and Sun’s RAG-MCP study reports that retrieving relevant tool schemas, instead of passing all schemas, improved selection accuracy from 13.62% to 43.13% on one MCPBench WebSearch setup while reducing prompt tokens by roughly half. Those figures are benchmark-specific and should not be generalised blindly, but they illustrate the core pressure: flat exposure of all tools is often a poor information architecture.

This article examines a structured alternative: progressive skill-gated tool access.

The pattern is simple:

1. Expose a compact catalog of available skills.
2. Let the model load a relevant skill through load_skill.
3. Inject full skill instructions only after activation.
4. Expand the active tool registry only through profiles required by loaded skills.

The design adapts progressive disclosure from UX and information hiding from software architecture to the economics of LLM context windows. The hidden detail is not hidden from a human user; it is hidden from the model until the task justifies exposing it.

We analyse this pattern through NanthAI:Edge, a commercial agent runtime whose architecture implements layered account capability, skill discovery, skill loading, and profile-gated tool expansion. NanthAI-specific details in this article are case-study implementation details provided by the system author.

The article contributes:

1. A conceptual framework for skills as progressive gates to instructions and tools.
2. A case-study analysis of NanthAI:Edge’s three-layer architecture.
3. A discussion of cache stability, routing intent, and profile-based registry expansion.
4. A risk catalogue emphasizing wrong skill selection and missing skill loads.

2. Background: Prompt Bloat, Tool Schemas, and Agentic Tool Use

2.1 Function Calling and Tool Exposure

Function-calling APIs require tools to be described to the model through names, natural-language descriptions, and structured parameter schemas. The model decides whether to call a tool, which tool to call, and what arguments to provide. Benchmarks such as the Berkeley Function Calling Leaderboard evaluate this capability across single-turn, multi-turn, parallel, and relevance-sensitive settings.

Tool use is not one capability. It decomposes into several:

• Tool selection: choosing the right function.
• Argument construction: producing valid and semantically correct parameters.
• Call sequencing: invoking tools in the right order.
• Result interpretation: using tool outputs correctly.
• Task completion: satisfying the user’s actual intent.

A system can select the right tool but fail on arguments. It can call a plausible tool but fail the task. It can succeed once but degrade over multi-turn trajectories. This is why final-answer scoring alone is insufficient for evaluating agentic systems.

2.2 Prompt Bloat

Prompt bloat is often framed as a cost issue, but the deeper issue is focus. Long prompts may include relevant information, irrelevant information, outdated instructions, duplicated policy, and many tool definitions. Larger context windows allow this information to fit, but fitting information is not the same as using it reliably.

Long-context research such as “Lost in the Middle” shows that models may use information less reliably depending on where it appears in the context. Other long-context and tool-calling studies suggest that context length, tool count, and multi-turn accumulation can interact in brittle ways. Exact thresholds vary by model and task, so this article avoids claims like “models fail after N tools.” The defensible claim is narrower: unnecessary instructions and irrelevant schemas increase the model-facing decision surface and can worsen routing conditions.

2.3 Tool-Registry Bloat

Tool-registry bloat is the tool-specific version of prompt bloat. A large flat registry forces every available tool to compete for attention on every task. This is especially problematic when tools overlap semantically: multiple search tools, multiple document tools, multiple calendar tools, multiple workspace tools, or multiple integration-specific variants.

Retrieval-based tool-selection work directly targets this problem. RAG-MCP retrieves relevant schemas before prompting rather than exposing all tools. Tool Attention and dynamic schema-loading approaches similarly argue for reducing the active candidate set. These approaches do not prove that skill gating works, but they support the broader idea that the model should not always see every executable capability.

2.4 Tool Description Quality

Reducing tool exposure is not sufficient. The tools and skills that remain visible must be clearly described. ToolACE reports gains from verified, high-quality function-calling data, showing that schema and description quality affect tool-use accuracy. Studies of API documentation similarly suggest that unclear parameter documentation and complex interfaces increase errors.

This creates the central design tension:

• Detailed instructions and schemas improve execution.
• Globally exposing all detailed instructions and schemas creates bloat.

Progressive skill gating addresses the tension by separating discovery metadata from execution detail.

2.5 Prompt Caching

Prompt caching can reduce latency and cost when stable prefixes are reused. But caching rewards stable prompt structure. If tool lists or system instructions are rewritten unpredictably, cache reuse may degrade.

This creates a second design tension:

• Dynamic loading reduces irrelevant context.
• Dynamic insertion can break cache stability.

A viable skill-gating architecture must therefore manage where and how loaded instructions appear. NanthAI:Edge’s approach, described later, is to keep a stable base prompt and catalog, then append normalized loaded-skill blocks in predictable positions.

3. Skills as Modular Instruction Packages

A skill is a named, discoverable capability package. It is not merely a tool and not merely a prompt snippet. It sits between user intent and executable functions.

A skill typically includes:

• slug
• name
• summary
• runtimeMode
• full workflow instructions
• required tool IDs
• required tool profiles
• required integrations
• required account capabilities
• policy constraints
• versioning metadata

A tool is an executable operation. A skill is a workflow-level capability that may use zero, one, or many tools.

For example, a document-generation tool may create a .docx file. A “research paper writing” skill may define source-handling rules, citation discipline, structure, synthesis requirements, and document-generation expectations, and may activate document, search, and analysis tools.

Progressive skill gating operates across three disclosure layers:

This structure turns skills into context-management primitives. They are simultaneously:

• units of capability;
• units of instruction scope;
• units of tool-registry expansion;
• units of governance and observability.

4. NanthAI:Edge Case Study

This section summarises case-study implementation details provided by the system author. It should be read as architecture documentation, not independently audited evidence.

4.1 Three-Layer Capability Model

NanthAI:Edge organizes capability through three layers:

1. Account capability and tier
2. Skills
3. Executable tools

The account layer determines what the user is allowed to access. Free users receive plain chat with no model-invoked tool registry. Pro users on tool-capable models receive a small base registry.

The skill layer contains modular instruction packages with metadata and activation rules.

The executable tool layer contains actual tool schemas and implementations, but heavy tool families are not exposed by default. They are unlocked by skill-declared profiles.

4.2 Base Registry

The base registry contains lightweight general-purpose tools such as:

• load_skill
• list_skills
• search_chats
• fetch_image

The crucial tool is load_skill. It makes routing a first-class model action. The model does not need every instruction up front; it needs enough metadata to decide when deeper instructions are required.

4.3 Skill Metadata

NanthAI skills include structured metadata:

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

This metadata supports both model-facing discovery and runtime policy enforcement. A skill requiring Slack, for example, can be hidden if the user has not connected Slack. A skill requiring a pro capability can be omitted for free users.

4.4 Available Skills Catalog

Skills resolved as available are rendered into an <available_skills> XML block in the system prompt. This catalog contains compact metadata, not full instructions.

A simplified example:

<available_skills>
<skill slug="analytics_report">
<name>Analytics Report</name>
<summary>Use when the user needs data analysis, charts, or structured analytical output.</summary>
</skill>
<skill slug="document_drafting">
<name>Document Drafting</name>
<summary>Use when the user needs a structured document, proposal, memo, or generated file.</summary>
</skill>
</available_skills>

The catalog is a routing surface. It tells the model what capabilities exist without forcing the model to process every workflow in full.

4.5 Skill States

NanthAI resolves skills across four scopes:

• account settings;
• persona;
• chat;
• turn-level overrides.

Each skill can be assigned one of three states:

• always: full instructions injected every turn;
• available: listed in the catalog and loadable on demand;
• never: excluded entirely.

This enables fine-grained policy. Universal rules can be always-on. Specialized workflows can be available. Disallowed or irrelevant capabilities can be hidden.

4.6 load_skill

When the model determines that a task matches a skill, it calls load_skill with the skill slug. The runtime returns full instructions and routing metadata.

Instead of relying on raw tool-result transcripts, NanthAI normalizes loaded instructions into a dedicated loaded-skills system message. This makes active instruction state explicit and avoids accumulating noisy tool-call history.

4.7 Progressive Tool Profiles

Skills declare requiredToolProfiles. Loading a skill can activate one or more tool profiles. Author-provided profiles include:

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

Examples:

• docs unlocks document and file generation/editing tools.
• analytics unlocks Python and data tools.
• workspace unlocks workspace file and execution tools.
• integration profiles unlock app-specific tools only when connected.
• subagents unlocks subagent spawning only when allowed.

The registry therefore expands according to activated skills, not according to total platform capability.

4.8 Runtime Guard

NanthAI includes a runtime guard instructing the model not to invent unavailable tools: no local filesystem access, no shell, no browser automation, no unconfigured MCP servers, and no raw network fetches outside explicit NanthAI tools.

This prompt-level guard is not a security boundary by itself. The actual security boundary must be enforced by runtime authorization and tool allowlists. But the guard reinforces the model’s understanding of the active capability surface.

5. Architecture Analysis

5.1 Token-Cost Model

Under a monolithic design, the per-turn prompt cost approximates:

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

Under progressive skill gating, the cost approximates:

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

The critical distinction is what scales with total platform capability. In the monolithic design, heavy instruction and schema costs scale with all available capabilities. In the progressive design, heavy costs scale with activated capabilities. The catalog still grows, but only as compact metadata.

This is the economic core of the architecture.

5.2 Catalog as Cache-Stable Routing Surface

The available_skills block is intended to be stable across turns unless user capability, persona, chat settings, or turn overrides change. Stability matters because prompt caching depends on reusable prefixes. A compact stable catalog can remain cache-friendly, while full skill bodies remain deferred.

5.3 Loaded-Skills Block

Normalizing loaded skill instructions into a dedicated system message has two benefits:

1. First, it keeps instruction state clean. The model sees loaded skill guidance as active system context rather than as a historical tool result.
2. Second, it helps preserve prompt-cache structure. If loaded skills are appended after stable base prompt and catalog content, new activations extend the context without rewriting the stable prefix.

This is one of the most important architectural insights in the NanthAI design: dynamic capability expansion and prompt caching are not naturally compatible, so the message structure must explicitly reconcile them.

5.4 Profile-Based Registry Expansion

Tool profiles create indirection between skills and tools. This is preferable to each skill directly owning a long list of individual tool schemas.

Profile indirection has several advantages:

• multiple skills can share a profile;
• profiles can be tested as capability bundles;
• integration availability can be checked once per profile;
• related tools can be exposed together;
• policy can be applied at the profile level;
• the active registry remains explainable.

For example, many skills may need document generation. Rather than duplicating document tool lists across skills, they can activate the docs profile.

5.5 Routing Intent

In a flat registry, intent is implicit. If the model calls a tool, engineers must infer why. In a skill-gated system, routing intent becomes explicit:

user task → loaded skill → activated profile → selected tool

This improves observability. Failures can be decomposed by layer:

• Was the correct skill visible?
• Was it loaded?
• Did it activate the right profile?
• Was the right tool selected?
• Were the arguments correct?
• Did the final answer satisfy the task?

This is a substantial evaluation advantage over monolithic prompting.

6. Central Counterargument: Metadata Routing Can Fail

The strongest objection to progressive skill gating is that hiding full instructions can harm routing.

A model may not be able to distinguish between similar skills from metadata alone. If catalog summaries are too short, vague, or overlapping, the model may:

• load the wrong skill;
• fail to load any skill;
• load too many skills;
• activate the wrong tool profile;
• produce a plausible but under-specified answer.

This is not a minor edge case. It is the central tradeoff. Progressive gating exchanges one problem, global bloat, for another problem, routing recall and precision.

The architecture is strongest when:

• the skill catalog is moderate in size;
• skill summaries are discriminative;
• skills are not heavily overlapping;
• fallback clarification is allowed;
• routing decisions are logged and evaluated;
• semantic retrieval can assist catalog matching.

It is weakest when:

• there are thousands of similar skills;
• summaries are generic;
• tasks require subtle distinctions;
• the model is discouraged from asking clarifying questions;
• missing a skill silently produces a poor but plausible output.

A robust implementation should therefore combine model judgment with deterministic checks, retrieval, versioning, and evaluation.

7. Risks and Failure Modes

R1: Wrong Skill Selection

The model loads a near-miss skill. This may inject wrong instructions and activate irrelevant tools.

Mitigations: discriminative summaries, examples, “when not to use” notes, offline routing tests, confidence thresholds.

R2: Missing Skill Loads

The model proceeds without loading a skill. This is dangerous because output may look acceptable while violating workflow requirements.

Mitigations: stronger load guidance, missed-skill detectors, post-hoc classifiers, clarification behavior.

R3: Stale Instructions

Loaded skill instructions may persist after a skill is updated.

Mitigations: skill version IDs, cache invalidation, reload rules, compatibility tests.

R4: Hidden Coupling

Skills and profiles may drift. A skill may assume tools not actually available in its profile.

Mitigations: requiredToolProfiles, requiredToolIds, profile tests, dependency linting.

R5: Added Latency

load_skill adds a tool-call round before work begins.

Mitigations: keep high-frequency workflows as always, speculative preload, or hybrid base registry.

R6: Cache Invalidation

Dynamic content inserted too early can break cache reuse.

Mitigations: stable prefix discipline, append-only loaded-skill block, cache tests.

R7: Prompt Injection

User-authored skills may contain unsafe instructions.

Mitigations: skill review, policy linting, sandboxing, permission scopes, runtime enforcement.

R8: Over-Reliance on Model Judgment

The model may be a poor router under ambiguity.

Mitigations: retrieval-assisted routing, deterministic policy gates, user clarification, telemetry.

8. Discussion

Progressive skill gating reframes tool registration as capability architecture. Rather than a flat list of tools, the agent runtime becomes layered:

account policy → skill catalog → skill loading → profile activation → tool execution

This has several implications:

1. Skills become the primary unit of governance. Tier access, integration state, tool profiles, and runtime modes can all be expressed through skill metadata.
2. Routing becomes inspectable. load_skill events can be logged, measured, and evaluated.
3. Marketplaces become more tractable. User-authored skills can declare their requirements and be admitted with bounded capability scope.
4. Hybrid designs are likely best. Small universal tools should remain in the base registry. Specialized, high-risk, expensive, or long-tail tools should be gated. always skills should be rare. available should be the default for specialized workflows. never should suppress disallowed capabilities.
5. Skill catalog quality becomes a product surface. Catalog summaries are not internal labels; they are model-facing routing interfaces. They require the same discipline as API documentation.

This is the direction we are taking in NanthAI:Edge: capabilities should be discoverable without being permanently injected, and powerful tools should appear only when the active workflow justifies them.

9. Static Architecture Measurements

While full behavioural validation requires a benchmark suite, some claims can be evaluated directly from the current NanthAI:Edge implementation. In particular, the codebase allows measurement of the context surface exposed by the skill catalog and progressive tool registry.

These measurements quantify the context-economy side of the argument: how much prompt and tool-schema material is avoided by exposing compact skill metadata and a small base registry instead of injecting every skill body and every tool schema up front.

9.1 Skill Catalog Compression

The current NanthAI:Edge system catalog contains 55 visible skills and 11 hidden or non-visible skills. Visible skills are rendered into the model-facing available_skills catalog as lightweight metadata: skill name, summary, and requirement hints. Their full instruction bodies are withheld until a skill is explicitly loaded.

Measured against the current visible catalog:

This means that the default skill-discovery surface is approximately one thirteenth of the size of the full visible skill instruction set. The model can still see that the capabilities exist, but it does not pay the full instruction cost unless a task actually requires one.

This supports the first context-economy claim of the architecture: skill discovery can remain broad while instruction activation stays selective.

9.2 Tool Registry Compression

The tool-registry effect is even sharper. In the current progressive registry, the base tool set exposes only four general-purpose tools:

• load_skill
• list_skills
• search_chats
• fetch_image

When all tool profiles are expanded, the registry contains 115 tools. The schema-token difference is substantial:

This supports the second context-economy claim: the model’s default executable action space is far smaller than the platform’s total capability surface.

Under a monolithic design, the model would see the full registry on every tool-capable turn. Under progressive registry expansion, it sees only the base tools until a loaded skill activates one or more profiles.

9.3 Example Active-Profile Costs

Different workflows activate different tool profiles. The savings therefore depend on the task. A narrow analytics workflow exposes far fewer tools than a document-generation workflow, and both expose far fewer than a fully expanded registry.

These examples illustrate why profile-based indirection matters. A data-analysis task does not need calendar, Slack, document-editing, scheduled-job, or persona-management tools. A Slack task does not need Python execution or document-generation tools. A document task may need the relatively heavy docs profile, but still avoids most integration and runtime tools unless explicitly required.

The system therefore shifts tool-schema cost from “everything available to the user” to “everything justified by the currently activated workflow.”

9.4 Interpretation

These measurements validate the architecture’s context-reduction premise, not its full behavioral promise.

They show that NanthAI:Edge’s progressive design materially reduces:

• default skill-instruction exposure;
• default tool-schema exposure;
• model-facing action-space size;
• prompt material that must remain stable for caching;
• irrelevant tool candidates before task-specific activation.

However, the measurements do not prove that the model routes better, chooses tools more accurately, or completes tasks more successfully. Those claims require behavioral evaluation.

The static measurements answer one question:

Does progressive skill gating actually reduce context and schema exposure in this implementation?

The answer is yes. In the current implementation, the reduction is large: approximately 92.5% for skill instructions and 97.7% for the base tool registry relative to full exposure.

10. Conclusion

Agentic AI systems face a growing information-architecture problem. As tools, integrations, workflows, and policies accumulate, monolithic prompt-and-tool-registry designs become increasingly costly and difficult to evaluate. Large context windows help with capacity, but they do not solve relevance, routing, cache stability, or governance.

Progressive skill-gated tool access offers a principled alternative. A compact skill catalog provides discoverability. load_skill provides explicit activation. Loaded skill instructions provide task-specific guidance. Tool profiles provide bounded registry expansion. Runtime authorization and guards preserve capability boundaries.

The NanthAI:Edge case study shows how this pattern can be implemented through account tiers, layered skill states, available-skill catalogs, normalised loaded-skill messages, profile-gated registries, and runtime guards. The architecture is promising because it aligns context cost with activated capability rather than total platform capability.

The central unresolved question is empirical: does the routing cost introduced by metadata-first skill selection outweigh the benefits of reduced prompt and registry bloat? The answer will depend on catalog size, skill overlap, model family, task distribution, and implementation quality.

Agent platforms should expose capabilities progressively, make routing observable, and activate tools only when the task justifies them.

References

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• NanthAI:Edge architecture description. Author-provided case-study material; not independently verified.

Also published on LinkedIn.