Engineering Practice: Wiring the Yakit Plugin Store Into the AI Agent Capability Orchestration Pipeline

Content Overview

• Target scenario: Plugin authors and platform maintainers who want their security plugins to be searched, selected, orchestrated, and executed by an AI Agent.
• How it works: Plugins, Tools, Blueprints, Skills, and Focus Mode are abstracted into a unified Capability set, then executed through layered intent routing, progressive disclosure, capability-catalog Grounding, and a unified dispatcher.
• Key conclusion: A plugin store is not only a script download entry point; it can also become the Agent's capability catalog. Discoverability, constraints, and result verification matter just as much as model capability.

FAQ

Does integrating a plugin with AI require rewriting an adaptation layer?

No. Following the flow described in this article, a plugin author only needs to enable "Expose to AI" and add an accurate plugin description to enter the unified capability catalog.

How does the system reduce the chance of the AI picking the wrong plugin?

Capabilities first pass through intent routing and catalog Grounding, then the candidate set is progressively narrowed. The execution phase is still managed and verified by the unified dispatch pipeline.

Background

In the past, if you wanted to expand the security capabilities of an AI, there were usually two approaches:

Either build a new AI tool from scratch, or attach capabilities piece by piece through mechanisms such as MCP, Skill, and Forge.

This approach obviously works, but it has several clear engineering constraints:

• Poor ecosystem reuse: Security capabilities already consolidated in the plugin store cannot be consumed directly by the AI.
• Rising maintenance complexity: As tools, Skills, and templates keep growing, capability boundaries become increasingly fragmented, and the orchestration logic grows heavier and heavier.

Meanwhile, the Yakit plugin store has already accumulated a large number of mature security plugins. If the AI cannot directly consume these ready-made capabilities, then a huge amount of security power remains stuck in the stage of "humans can click it, the AI cannot use it."

Therefore, the core of this update is not "we added a few more AI tools." It is that the plugin store has officially entered the AI Agent's capability orchestration pipeline.

What this upgrade fundamentally changes

The key to this plugin integration capability is not simply exposing plugins to the AI. It is unifying plugins, AI Tools, Blueprints, Skills, and Focus Mode into a higher-level Capability set.

This means that when the AI executes a task, it is no longer rigidly bound to a fixed tool. Instead, it goes through a more complete capability orchestration pipeline:

1. Identify the user's true intent;

2. Retrieve candidate capabilities based on that intent;

3. Within the candidate set, identify the most relevant plugin, tool, Blueprint, or Skill;

4. Choose the appropriate loading and execution path based on capability type;

5. Verify the result, supplement context, and decide on the next action.

From an architecture perspective, this upgrades the plugin store from "an asset library humans can click and execute" into a Dynamic Capability Bus for the AI Agent.

Capability Platform Overview Architecture Diagram

Writing an AI plugin: from "script" to "orchestrable capability"

Getting a plugin onto this pipeline does not require writing a complex AI adaptation layer. You only need to turn on the "Expose to AI" switch on the plugin edit page and fill in the plugin description.

The significance behind this action is actually large:

It is not a simple visibility toggle. It adds a layer of Agent-facing semantic metadata to the plugin.

This metadata carries at least three responsibilities:

1. Capability declaration: Tells the AI what this plugin is and what problems it is suited to solve;

2. Semantic recall: Provides descriptive words, keywords, and task scenarios for subsequent capability retrieval;

3. Execution hints: Helps the Agent judge at which stage this capability should be invoked.

In other words, once a plugin is "exposed to AI," it is no longer just a piece of code in a script repository. It is promoted into a capability node that an Agent can retrieve, understand, and invoke.

How it avoids being "rigid"

Saying "the AI can automatically invoke plugins" sounds a lot like ordinary function binding. In reality, this mechanism is more like an intelligent orchestration pipeline with multiple layers of decision-making.

1) Layered intent routing: not every request takes the same path

The system does not perform deep reasoning on every request. It first does a lightweight assessment of input scale and a preliminary intent classification.

For short, unambiguous, clearly targeted requests, the system preferentially enters a fast lane:

• Uses rules to identify trivial queries such as simple greetings and status checks;
• Uses keywords and BM25 for lightweight capability recall;
• If a clear capability is already matched, it proceeds directly to the execution phase.

For compound tasks such as "I want to do a penetration test," "help me test this site," or "check for weak passwords," the system upgrades to a Deep Intent Recognition flow.

At this stage, the AI no longer just does keyword matching on the original sentence. It first compresses the user input into a more stable set of intermediate semantic structures, such as:

• intent summary
• retrieval tags
• retrieval questions
• recommended capabilities

The value of this step is:

The user is speaking in natural language, but what the system needs is a task-level semantic representation that can drive capability retrieval and execution. This is in fact a typical Hierarchical Intent Routing: low-cost pre-routing first, then a decision about whether to enter heavier deep analysis.

2) Progressive disclosure: the AI does not see the entire plugin store, only a capability set that has been progressively narrowed

A crucial point about this mechanism is that it does not expose all plugins to the model at once, in full. If every plugin and every parameter across the entire platform were stuffed directly into the context, the result would usually not be smarter, only messier. So a strategy better suited to an Agent is adopted: Progressive Disclosure.

Capabilities are not all unfolded at once; they are exposed layer by layer, by phase:

• Expose metadata first: Only let the model see capability names, descriptions, keywords, and usage;
• Then expose the candidate set: Filter out the small batch of capabilities most relevant to the user's task;
• Then do identifier verification: Confirm that the recommended capabilities actually exist and are executable;
• Only then execute: Enter the corresponding channel (Tool / Plugin / Blueprint / Skill) based on capability type.

The essence of this design is to control context noise and increase the decision density of the Agent. It lets the model face only "the most relevant capability slice for the current round" rather than one giant capability table.

From a system design perspective, this is a very typical Capability Surface Minimization approach:

While preserving the breadth of capabilities, compress the surface area of capabilities exposed to the model in each round.

3) Capability catalog Grounding: constrain first, recommend second, reduce hallucinated invocations

The biggest problem with relying solely on a large model for semantic association is that it may "invent a plausible but nonexistent capability name." In a security scenario, this kind of problem is especially unacceptable.

So before capability retrieval, this mechanism adds a layer of Capability Catalog Grounding:

• The system first builds a catalog of capabilities that actually exist;
• The catalog contains identifiers for Tools, Plugins, Blueprints, Skills, Focus Mode, and so on;
• The AI can only match and recommend within this catalog;
• After recommending, it still goes through an identifier verification step to ensure the name can actually be resolved at runtime.

This step is critical.

It restricts "the AI's right to recommend" to within "the set of capabilities that actually exist," which significantly reduces the risk of mis-dispatch caused by hallucinations.

So, precisely speaking, the AI here is not "freely inventing capabilities." It is performing semantic navigation within a constrained capability graph.

Capability Catalog Grounding Flow

4) Unified capability dispatch: a plugin is not a special case, it is one type within the capability dispatcher

Once candidate capabilities are filtered out, the system does not write a separate special logic for plugins. It enters a unified capability dispatch flow.

This step can be understood as Unified Capability Dispatch.

The same capability identifier can be resolved into different types at runtime:

• tool
• plugin
• blueprint / forge
• skill
• focus mode

Different capability types take different execution paths:

• Tool / Plugin is better suited for direct invocation;
• Blueprint / Forge is better suited for multi-step orchestration and asynchronous execution;
• Skill is more like methodology and context loading;
• Focus Mode is more like entering a specific task mode.

This means plugin integration is not an isolated feature. It is folded into a unified capability model. The plugin store is no longer just a "plugin repository"; it is a first-class capability source within the Agent's execution system.

5) Intent awareness is not one-shot; it runs through the entire execution process

Traditional automated execution is often: identify the task once, then run to the end. But real security tasks are not linear. Especially across scanning, verification, judgment, and response analysis, the task goal keeps converging. So this mechanism has another layer worth highlighting: Runtime Intent Perception.

After key actions are executed, after verification, or even when repeated attempts or strategy looping occurs, the system re-perceives the current state and generates a brief process profile, for example:

• What it is doing right now;
• What the current theme is;
• What keywords are currently being hit;
• Whether the situation has materially changed;
• Whether the next step should expand or converge.

This gives the Agent a runtime perception ability closer to "continuous thinking," rather than only being smart once at the start of the task.

If the intent recognition above solves the "starting-point problem," then this layer of runtime perception really solves the "am I drifting off-course during execution" problem. In technical terms, this is closer to a Runtime Situational Awareness.

Why plugins can be found more accurately

Being exposed to the AI is not enough. The system also has to make plugins "findable," and findable in a way that is closer to the user's natural language.

So for capability retrieval, the system does not simply do exact string matching. It combines several signals:

• Plugin name hit
• Description hit
• Keyword hit
• Task semantic hit
• Explicit capability name mention

From an engineering perspective, this gives capability recall:

• Explainability: Because every hit can be traced back to a plugin name, description, or keyword;
• Robustness: Even when the user's wording does not exactly match the plugin name, it can still get close based on semantics;
• Controllability: Hit results still have to go through real identifier verification in the end.

Therefore, users do not need to remember plugin names.

The user only needs to describe "I want to detect Fastjson," "help me check for weak passwords," or "analyze the possible attack surface of this system," and the system will try to map this natural language onto the correct capability set.

Case 1: Fastjson vulnerability detection

Take Fastjson vulnerability detection as an example. This pipeline roughly works as follows:

1. The AI extracts the target URL from the task;

2. Identifies that the current task belongs to a vulnerability verification / Java deserialization / RCE detection scenario;

3. Recalls plugins related to Fastjson from the capability set;

4. Narrows the candidate plugins down to an executable capability;

5. Invokes the corresponding plugin to launch detection;

6. Makes a result judgment based on the response and latency characteristics;

7. Writes the verification result back into the context as input for the next decision.

This shows that what the AI is starting to possess is a task-level capability loop, not a one-shot tool call.

Case 2: Weak password detection

Looking again at the weak password detection example makes it easier to understand the role of a Skill in this setup.

The weak password detection Skill itself does not necessarily execute the scan directly. It is more like providing the AI with a specific task framework:

• First identify the target system type;
• Then judge which kind of authentication-surface detection is more appropriate right now;
• Finally invoke the corresponding plugin to perform verification.

For example, when the target characteristics look more like WebLogic, the AI converges the capability set onto the WebLogic weak password detection plugin, rather than blindly firing off a pile of unrelated plugins.

This shows that within this system a Skill is not simple prompt wrapping. It is more like a layer of task constraints and methodology injection:

• It gives the AI domain context;
• It constrains the boundaries of the AI's actions;
• It reduces the probability of wrong capability recall;
• It makes plugin invocation closer to the concrete task scenario.

If plugins are responsible for "execution,"

then a Skill is more responsible for "methodology,"

and the Agent is responsible for "stringing methodology and execution capability together."

A crucial shift: the AI moves from "knowing" to "doing"

The real change brought by this plugin integration is that the AI moves from "knowledge-type capability" to "operational capability."

In the past:

• The AI could explain vulnerabilities;
• The AI could suggest approaches;
• The AI could generate detection recommendations;
• But actual execution still required a human to click the plugin, pick parameters, and read results.

Now:

• The AI can proactively discover plugins based on intent;
• It can combine Skills and Blueprints to understand task context;
• It can incorporate plugins as execution units into the task flow;
• It can make result judgments after execution and decide the next action.

This means the Agent's capability boundary is no longer mainly determined by the model itself, but increasingly by the ecosystem of orchestrable capabilities.

In other words:

The model is responsible for understanding and decision-making; the plugin ecosystem is responsible for execution and expansion.

Only the combination of the two is truly deployable security automation.

Summary

The significance of this "plugin store integration" is not just giving the AI one more entry point for invoking plugins. It is formally connecting the plugin store into the Agent's capability loop:

• Intent recognition
• Capability recall
• Catalog Grounding
• Identifier verification
• Unified dispatch
• Execution verification
• Context write-back

From this perspective, the plugin store is no longer a static asset library; it is the AI Agent's external capability pool;

A Skill is no longer just a prompt; it is task methodology;

A Blueprint is no longer just a template; it is a complex-task orchestrator.

What ultimately takes shape is, in effect, a Capability-Oriented AI Orchestration for security scenarios.

This also means everyone can, on top of the existing AI Agent capability base, exercise more creativity:

• Automated asset inspection
• Batch vulnerability scanning
• Multi-target weak password verification
• Compliance checks
• Task orchestration in red-team / blue-team exercises
• Industry-specific security workflows built on Skills

The truly imaginative part is not "whether the AI can call one more plugin,"

but this: the plugin ecosystem has finally become a capability ecosystem that the AI can understand, recall, execute, and verify.

What plugin integration brings is not simple "tool access." It evolves the AI from a static knowledge assistant into a security Agent with intent recognition, capability discovery, execution orchestration, and result verification. Once the plugin store becomes the AI's capability foundation, the ceiling of security automation is no longer set solely by the model itself, but by whether the entire plugin ecosystem can be continuously organized, continuously reused, and continuously amplified.

---

This article was first published on the Yak Project official account. Read the original (Chinese).