This post is part of a series exploring the necessity of a new, autonomous communication protocol for AI agents. As we move toward a world where AI operates independently, establishing structure, security, and accountability becomes paramount. You can follow the complete series through the links below:

Part 1: AI Agents, Autonomy, and the Need for a New Communication Protocol

Part 2: The Role and Responsibilities of the Central Hub

Part 3: Identity, Authority, and Boundaries

Part 4: Definitions of Capability and Skill

In this protocol, skills refer to callable, contract-bound technical abilities, while capability represents the higher-level qualification state that determines under what conditions and to what extent an agent may use certain skills.

Talking about an agent with an identity alone is insufficient. What an agent can do is at least as important as who it is. In practice, most security and abuse problems stem not from agent identity, but from which abilities agents can access and under what conditions.

For this reason, the protocol defines what an agent can do not through ambiguous behaviors or free-text commands, but through explicitly defined skills. The primary goal is to eliminate implicit assumptions such as “the agent seems to be able to do this” and to make abilities as visible, auditable, and restrictable as possible.

Why skills are a separate concept

Many existing agent systems acquire abilities through prompts, scripts, or model-internal steering. This approach may work at small scales, but it produces serious problems as scale increases. What an ability actually does, what data it accesses, or what side effects it has are often unclear.

In the protocol, a skill is the fundamental unit defined to eliminate this ambiguity. A skill represents a function that an agent can invoke under explicit conditions, with clearly defined boundaries, and that can be audited. It is neither a free-form command sequence nor a hidden, model-embedded capability.

Another important distinction is that skills do not belong to a specific agent or model architecture. The protocol treats skills as first-class entities. This allows the same skill to be reused by different agents, suspended when necessary, or revoked entirely. Secure operation at scale depends on this approach.

Skill contracts: explicitly defining intent

Each skill is represented within the protocol by a skill contract. This contract does not describe how the skill works internally, but rather what it intends to do and what it must not do.

Contracts are designed primarily to be human-readable. The goal is for both technical auditors and domain experts to understand a skill’s scope. These documents are not executable code; they are declarative and version-controlled to avoid ambiguous behavior. A skill contract describes the frame of behavior, not the behavior itself.

This human-readable text is then transformed into a canonical intermediate representation used by the protocol. This step is critical for eliminating ambiguity: two skill definitions with the same meaning must produce the same canonical representation. This representation becomes the shared reference point for auditing, certification, and evaluation.

Finally, the skill is compiled into a specific execution structure. This structure guarantees that the skill runs only in a protected environment, with defined permissions and controlled resource usage. A compiled skill is immutable; even the smallest change requires a new version and re-verification. This prevents “silently expanding” capabilities.

Permissions and constraints: what is forbidden matters as much as what is allowed

One of the most critical components of a skill is its permission declaration. Each skill must explicitly state what operations it can perform, what resources it requires, what forms of data access are allowed, and how it can interact with the outside world.

The approach here is deliberately strict: permissions are whitelisted. Anything not explicitly allowed is forbidden. This prevents capability acquisition by inference and simplifies security assumptions.

In addition, each skill declares its constraints. Limits such as execution time, memory usage, and input/output sizes are enforced not by the skill itself, but by the execution environment. Even if a skill attempts to violate its limits, the system stops it.

Domain context: not every skill is meaningful everywhere

Skills are always associated with one or more domains within the protocol. Domains such as law, medicine, or software determine where a skill can be used and what evaluation criteria apply.

This distinction matters because the same technical function can carry very different risks in different domains. A skill defined for one domain cannot be used to bypass oversight in another. Domain scope anchors both authority and responsibility in context.

Security: a skeptical-by-default approach

Before being added to the hub, a skill undergoes a comprehensive verification process. This process asks not only “does it work?” but “does it work as it claims?” Static analysis, permission boundary checks, adversarial testing, and domain-specific benchmarks are part of this process.

This verification is deliberately conservative. In cases of uncertainty, the default decision is rejection. The goal is long-term reliability rather than speed.

Even approved skills are not considered permanently safe. New attack techniques, evolving domain standards, or changes in model capabilities require periodic re-evaluation. Skills that fail are suspended or revoked.

Skill composition: controlled expansion, not unchecked power

Real-world tasks are rarely accomplished with a single skill. For this reason, the protocol allows skill composition. However, such composition must be explicit and auditable. Composed skills cannot exceed defined boundaries, domain scopes must be compatible, and resulting behavior must remain analyzable.

The resulting composite is treated as a new skill and verified from scratch. Composition is never a way to bypass oversight.

Chain of responsibility

Finally, every skill is explicitly linked to an author, a version, and a domain. When a skill behaves incorrectly, not only the skill itself but also the structures that produced and used it are evaluated. If necessary, the skill is revoked, the author’s domain score is affected, and higher-level structures that relied on it are reviewed.

The underlying assumption is clear: uncontrolled capability growth is far more dangerous than slow progress. The protocol accepts this risk from the outset and shapes its design accordingly.