Skip to content
B BYOAg
Menu
Browse BYOAg
Draft

Portable authority

Describe authority by meaning, not vendor tool names

A BYOAg host should be able to understand what an agent may do without knowing the agent’s internal tool names. Capabilities provide that shared semantic layer.

The permission envelope

Authority is an intersection

Connecting an agent does not grant every action available in an experience. Effective authority is the overlap of three independent boundaries.

1 · Connection

May this installation connect?

Pairing establishes a durable, revocable relationship with a specific agent installation.

2 · Engagement

What may it do here?

The signed descriptor narrows authority for one experience and one operating context.

3 · Runtime

Is this action allowed now?

The client still applies local policy before exposing or invoking a concrete tool.

Portable vocabulary

Operations express intent

Capabilities describe what an operation means. Concrete APIs, MCP tools, and function names remain implementation details that can differ between platforms.

  • read
  • reveal
  • create
  • modify
  • delete
  • execute
  • transact
  • communicate
  • delegate
  • administer

Effects and data

Qualifiers make risk legible

A capability can also express the resource it affects, the classes of data involved, whether an effect is reversible, and where confirmation is required.

These qualifiers let clients reason about risk without pretending every platform exposes the same interface.

Resolution

From semantic contract to concrete tool

An experience can publish a capability contract. A compatible host may then map that meaning to its own callable surface.

Capability contract

{
  "id": "game.move.submit",
  "operation": "execute",
  "resource": "current_match",
  "effects": ["changes_shared_state"],
  "confirmation": "policy_driven"
}

Host-specific mapping

{
  "tool": "arena_submit_move",
  "satisfies": "game.move.submit",
  "transport": "mcp"
}

Portable skills

Skills declare what they need

A skill can declare required and optional capabilities. A future resolver can compare them with the signed engagement and the client’s local mappings before activation.

Required

All must resolve

If one is missing, the skill remains unavailable and explains the unmet requirement.

Optional

Graceful enhancement

Optional capabilities can unlock richer behavior without preventing the core skill from running.

Namespaces and versions

Stable meaning without one global catalog

  • Use a stable namespace for domain-specific capabilities.
  • Keep identifiers semantic; do not encode a vendor function name.
  • Version breaking changes to meaning or required behavior.
  • Prefer small, composable capabilities over broad claims of unrestricted access.