HookBus Agent: an open-source reference runtime for governance-native agent execution

HookBus Agent is an open-source CLI agent and reference runtime for governance-native agent execution.

Existing agent runtimes can be adapted to AgentHook through publisher shims. That matters, because enterprises will continue to run Claude Code, Codex, Amp, OpenCode, Hermes, OpenClaw, browser tools, shell tools, and other agent surfaces.

But adapters can only govern the lifecycle boundaries a runtime exposes. Wrappers matter, but wrappers are not the same as a runtime designed around governance from the start.

HookBus Agent is being built to show the stronger architecture: an AgentHook-native runtime where evidence, admission control, goal state, approvals, denials, and replayable audit records are part of the execution path from the start.

Why build a reference runtime?

AgentHook is a v0.2 draft runtime evidence and decision interface for AI agents. It defines how runtimes emit lifecycle events, how subscribers return allow, deny, and ask, and how evidence can be reconstructed later.

Publisher adapters prove that existing agents can interoperate with that standard. A native reference runtime proves the stronger claim: an agent can be built with runtime evidence, approval boundaries, goal state, and audit records as first-class runtime behaviour.

HookBus Agent should prove that:

• AgentHook can be implemented natively, not just adapted.
• Governance decisions can sit before execution, not only after observation.
• Runtime evidence can be designed for reconstruction from the start.
• HookBus can act as the control backbone for governed agent execution.
• Enterprise approval and audit workflows can plug into a native runtime boundary cleanly.

What governance-native means

HookBus Agent is not being positioned as another coding assistant with a governance plugin. The design goal is a runtime where governance is part of the execution path:

• Runtime contract before execution: the agent discovers AgentHook.md and agenthook.lock.json before work starts, then emits runtime-contract evidence.
• Lifecycle evidence by default: sessions, prompts, goals, model calls, tool calls, approvals, denials, errors, and stop events are emitted as AgentHook-shaped evidence.
• Admission-bound tool control: governed actions can be allowed, denied, or paused before execution.
• Goal and tool-activity lineage: the runtime records how work progresses through the run, not merely that a tool was called.
• Replay-oriented evidence: events are structured so audit, incident review, and governance playback can reconstruct what happened.

Runtime prompt
  -> AgentHook event
  -> HookBus
  -> subscriber decision
  -> allow / deny / ask
  -> evidence record

Agent proposes shell command
  -> PreToolUse event emitted
  -> HookBus routes to policy subscriber
  -> subscriber returns deny
  -> command is not executed
  -> denial is recorded as runtime evidence

Where HookBus Agent fits

The approval boundary

HookBus Agent can emit events, honour subscriber decisions, and expose when an action requires approval. HookBus can route those events and return allow, deny, or ask.

Full human-in-the-loop approval is an enterprise control-plane concern: approver routing, escalation, approval state, evidence retention, reporting, and operational audit belong in AgentProtect CRE and AgentFlow.

That split is deliberate. The open runtime makes the decision boundary visible and interoperable. The enterprise control plane owns policy, approval state, routing, audit, and governance operations.

What is coming this week

The first release is intended to be usable with HookBus as a CLI agent runtime. The immediate goal is not to claim regulatory compliance, production certification, or parity with every coding assistant. It is to give developers and enterprise architects a concrete reference for how an AgentHook-native runtime behaves.

That means:

• a CLI agent that emits AgentHook-shaped runtime events;
• a HookBus integration path from the start;
• clear decision handling for allow, deny, and ask;
• runtime-contract discovery as the AgentHook draft matures;
• a path toward the highest AgentHook assurance profile: native runtime contracts, pre-action decision points, replayable evidence, and tamper-evident audit records.

We are calling it HookBus Agent because the first job is simple: give HookBus users a governed reference agent they can inspect, run, and test against the AgentHook standard.

Why this matters

The agent category is moving quickly toward richer hooks, tool control, and lifecycle events. That is good. But the long-term enterprise question is not whether a single vendor exposes a useful hook this month. It is whether agent runtimes can speak a common evidence and decision language across vendors, models, tools, and control planes.

HookBus Agent is not intended to replace every coding assistant or agent framework. Its first job is to make the governance-native runtime pattern inspectable, runnable, and testable.

Existing runtimes still need adapters. Enterprises still need buses, policy subscribers, approval workflows, and audit surfaces. But a reference runtime matters because it shows the architecture without compromise: evidence first, decisions before execution, replay after the fact.

Agent governance should not be bolted on after the runtime is already finished. For high-assurance agents, governance has to be part of the runtime path.

← Back to blog