How HCP works

HCP is one harness model: a pack declares what a capability can do, and the runtime that already drives the agent decides whether each call runs. Commands come in through Execute and announcements of change go out through Sense, and both cross the same Policy, Binding and sandbox, so an observation becomes an action only by passing every gate a typed command passes. Read the two loops below, then open the object you need from the table at the end.

                          HARNESS PACK
                     (three files, one id)
            ┌─────────────────┴─────────────────┐
            │                                   │
      EXECUTE (inbound)                   SENSE (outbound)
      named commands                      declared triggers
      CLI face + JSON face                stimuli[] + Policy rows
            │                                   │
            └─────────────────┬─────────────────┘
                              │
             Policy · Binding · Principal · sandbox
                              │
        runtime: catalog · grants · mint hub · sink · audit

The harness is the runtime: whatever already drives the agent loads packs, resolves grants, mints Binding and runs Adapters. HCP therefore needs no network "HCP server" and no daemon, and a company may keep its runtime proprietary while the pack format and the rules stay open.

Execute: the inbound loop#

An Invoker, whether a person at a terminal, an agent in a tool loop, a product API or a UI gesture, runs a command: a closed, named operation the pack declared. Its CLI face and its JSON face are the same command under the same Policy and Binding (the twin face). Before any Adapter runs, the request passes a fail-closed pipeline:

Principal → scope (tenant · project · land) → capability grant
  → confirm (if Policy says so)
  → Binding mint (no ambient env fallback)
  → Adapter → sandbox → structured result + audit

Any step may deny with a reason (denied: missing verb.exec.write …, confirm required), and then nothing downstream runs (Execution, Execute specification).

Sense: the outbound loop#

A pack announces that the world changed by declaring triggers (stimulus refs) in its manifest, each with its own Policy row. The runtime delivers them by whatever means it chooses, and only while the sense.enable grant is on.

world changes ──► pack announces trigger ──► runtime sink records
                                                │
                                          (optional wake)
                                                ▼
                                  Invoker runs Execute (read → gated write)

Sense is emit-only, so a trigger must not mint credentials, bypass Binding or turn into a command. Polling a status command is Execute, and a runtime's uptime monitor is no pack trigger. The loops stay apart because an event that could execute could also spend money, while an Execute that owned push would have agents polling forever and calling it Sense (Sense, Sense specification).

What both loops share#

Both loops sit on one Policy file with a row per command and per trigger, one Binding that names the credential mode and the hub that mints it, the Principal the runtime establishes, and the sandbox, which denies unknown binaries, jails the working directory and inherits no ambient credentials. Secrets never live in the pack.

What a host sees#

A host is the agent product that adopts HCP: it presents commands to its agent loop, invokes Execute and may subscribe to Sense. Coding agents get one Skill and the hcpx binary, so adding a pack adds no tools, while in-process loops get one typed tool per command the Principal may run (Adopt in hosts).

The objects#

Each object has one home page. The normative definitions live in §1 Terminology.