---
title: "How HCP works"
description: "The path every command and trigger takes through a pack, the runtime and a host, and the page that explains each HCP object."
canonical: https://harnesscontextprotocol.io/docs/concepts
---

# How HCP works

> The path every command and trigger takes through a pack, the runtime and a host, and the page that explains each HCP object.

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.

```text
                          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](/docs/concepts/command#the-twin-face)).
Before any Adapter runs, the request passes a fail-closed pipeline:

```text
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](/docs/runtimes/execution),
[Execute specification](/docs/specification/execute)).

## 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.

```text
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](/docs/concepts/sense),
[Sense specification](/docs/specification/sense)).

## 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](/docs/hosts)).

## The objects

Each object has one home page. The normative definitions live in
[§1 Terminology](/docs/specification/terminology).

| Object | What it is |
|--------|------------|
| [Pack](/docs/concepts/pack) | The install unit: three files under one id, in one of five [classes](/docs/packs/best-practices#pack-classes) |
| [Command](/docs/concepts/command) | A named operation with a CLI face and a JSON face, identified by `verb_key` |
| [Policy](/docs/concepts/policy) | The pack's rules, one row per command and per trigger |
| [Access](/docs/concepts/access) | What runs without asking, set by the user or operator |
| [Binding](/docs/concepts/binding) | How a command gets credentials at exec time |
| [Principal](/docs/concepts/binding#principal) | Who acts, established by the runtime and never a pack field |
| [Sense](/docs/concepts/sense) | Triggers a pack may announce |
| [Skill](/docs/concepts/skill) | `HARNESS.md`, the one screen that teaches the commands |
| [Adapter](/docs/concepts/adapter) | How a command reaches the world: `wrap`, `composite`, `openapi` or `sense_only` |
| [Invoker](/docs/runtimes/execution#invoker) | Agent, API, UI or a person at the CLI; never redefines Policy or Binding |
| [Runtime](/docs/runtimes) | Loads, authorises, binds, executes and routes Sense |
| [Lifecycle](/docs/concepts/lifecycle) | Lint, install, activate, connect, availability, exec |

## Sitemap

- [Documentation](https://harnesscontextprotocol.io/docs)
- [Packs](https://harnesscontextprotocol.io/packs)
- [Glossary](https://harnesscontextprotocol.io/docs/reference/glossary)
- [llms.txt](https://harnesscontextprotocol.io/llms.txt)
- [llms-full.txt](https://harnesscontextprotocol.io/llms-full.txt)
- [OpenAPI](https://harnesscontextprotocol.io/openapi.json)
- [MCP](https://harnesscontextprotocol.io/mcp)