Skip to main content

Agent Capability Plane

Use this page when you need to understand how Helpifyr decides which agent-facing capabilities are admitted, projected, and safe to consume before any runtime executes them.

When to use this page​

  • You need to know how capability truth becomes readable to Reed, Warp, or other agent-facing consumers.
  • You are checking whether a skill pack or capability is merely proposed, fully admitted, or blocked.
  • You need the semantic boundary between Fabric-owned capability truth and downstream runtime execution.

Prerequisites​

Architecture / Flow​

Step-by-step procedure​

1. Start from Fabric-owned capability admission truth​

The Agent Capability Plane is the semantic layer that says which capability classes, skill packs, and projection verdicts are valid for downstream consumers to read.

That means:

  • Fabric owns admission, projection, and verdict semantics
  • downstream runtimes do not invent their own admission grammar
  • missing or stale projection must fail closed

2. Treat projection readback as the consumable surface​

ACP is not a runtime executor. It publishes read-only capability and verdict truth that downstream consumers use to decide whether a lane is admitted, guarded, or blocked.

Key boundaries include:

  • lifecycle state such as proposed, admitted, active, quarantined, or revoked
  • projection revision and compatibility posture
  • explicit verdicts instead of implicit green behavior

3. Keep Reed and Warp consumption read-only and revisioned​

The public-safe model is that agent-facing consumers read one explicit projected truth rather than reconstructing capability posture from side documents or chat history.

Consumers should assume:

  • projection missing means stop
  • stale revision means stop
  • compatibility mismatch means stop
  • runtime execution still belongs to the runtime owner, not to ACP itself

4. Use ACP to separate semantic truth from execution ownership​

ACP explains which capability may be consumed and under what posture.

It does not mean:

  • Fabric now owns downstream execution
  • a visible capability is automatically routable
  • readback evidence becomes a mutation authority

Verification​

This page is being applied correctly when a reader can:

  1. explain who owns capability admission truth versus runtime execution
  2. identify why Reed and Warp consume only read-only projected capability truth
  3. explain why stale or missing projection must fail closed

Common failure modes​

Treating runtime execution as ACP truth​

Problem:

  • readers assume that because ACP names a capability, Fabric also owns the downstream action path.

Better path:

  • treat ACP as admission and projection truth only, then follow the runtime owner for execution behavior

Treating side documentation as enough for capability admission​

Problem:

  • local docs, PRs, or notes are used as if they replaced the projected capability registry.

Better path:

  • require explicit projected capability truth and revisioned readback before calling a lane admitted

Source Truth​

Next paths​