Verified Digital Agents → Blocks → HITL

HITL — Human in the loop

The block that owns human decisions on agent actions. Your rules set what an agent does alone and what comes to a person; anything beyond the limits is surfaced, decided by someone with the authority to decide it, and sealed.

Live · signed A2A card + MCP/REST (9 skills) · standalone at hitl.getvda.ai and in production via the hospitality flagship

Domain-blind by construction

An item is a decision, some evidence, and an authority requirement. Nothing in HITL knows about hotels, or credit, or hiring. That is deliberate: an approval queue that understands your domain has to be rebuilt for the next one, and the governance question — did someone with authority decide this, and can you prove it? — is identical across every domain.

Approval that survives an audit

"A human approved it" is not evidence. HITL records the parts that make it checkable:

Who was asked	The authority band the item was routed to, from a registered authority config.
Who decided	The asserted actor is recorded separately from the authenticated account — because the account that submitted a decision is not necessarily the person who made it, and conflating them destroys the evidence.
What they were deciding	The sealed statement binds the specific values decided, so an approval cannot silently be re-used for a different question.
That it happened	Sealed to Witness as a `hitl_decision`, under customer-managed custody — so it is provable against Witness, not merely asserted by it.

Callers are registered, not self-declared

A service cannot admit itself. A caller is registered by genesis, authenticated with HITL's controller key — an operator action the calling service cannot perform for itself. Until then, a raise returns a typed refusal naming the unknown escalation label, which each client surfaces honestly as unavailable rather than pretending to have queued something.

Degrading honestly

HITL unreachable at activation → the consumer's gate REFUSES.
    A decision it cannot resolve is never treated as a pass.

Resolved but seal still PENDING → refused until the seal lands.
    Resolved is not durably anchored.

No credential → the client is unavailable,
    never a fabricated resolution.

Every one of those is a case where it would be easier to let the action through. That is exactly why they are the interesting cases.

Composed with ACP

The clearest worked example of blocks composing: a governance change needing ratification is raised by ACP to HITL, resolved by an authorised human on ACP's own surface, sealed by HITL, and ACP's activation gate is fed by that sealed resolution. ACP owns the surface; HITL owns the item. Neither reimplements the other.

See the full flow on demo data → Demo data