Don't give your agent a wallet. Don't make KeeperHub guess what's authorized either.

A research agent sees a paid API endpoint, decides "this is worth $0.05," and reaches for a tool to fire the payment. Two things have to happen between intent and execution:

1. Decide: is this payment authorized? Within budget? Recipient allowlisted? Right chain? Right risk class?
2. Execute: translate the authorized intent into a signed transaction (or a webhook, or an x402 call) and dispatch it.

Most "agent payment" stacks today try to do both in one product. SBO3L doesn't. KeeperHub doesn't. Together they form the cleanest composition we've shipped — a policy boundary that emits a signed receipt, and an execution layer that consumes the receipt and actually fires the call.

1. Why two products beat one monolith

The decision layer is the boundary between "what the agent wants to do" and "what the operator allows the agent to do." Its audience is the operator: a CFO, a compliance officer, an SRE on call. They edit YAML to express budget caps, allowlist providers, set risk thresholds. They want the policy engine auditable, deterministic, slow-moving.

The execution layer is the bridge between "an authorized payment intent" and "the rails it actually settles on." Its audience is the workflow developer wiring KeeperHub up to a Stripe webhook, an x402 endpoint, a Uniswap router, a Discord bot. They want flexibility, fast-evolving, integration-rich.

Bundle them and you compromise both. The decision engine starts shipping integrations to chase the latest payment rail. The execution layer starts adding policy DSLs to chase compliance reviews. Both get worse at their core jobs. Split them and each grows on its own clock — if the contract between them is right.

2. The signed receipt as the contract

When SBO3L decides on an APRP (Agent Payment Request Protocol body), it emits a 14-field PolicyReceipt. Three things make it the right contract:

1. Content-addressable. The request_hash pins the exact APRP bytes that were decided on. KeeperHub can re-derive the hash from the body it receives and refuse to execute on mismatch. No "agent edited the request between decision and execution" attack.
2. Offline-verifiable. Anyone with the policy signer's public key can verify the Ed25519 signature without contacting SBO3L. KH verifies before executing. An auditor reading the audit log months later verifies too. No "trust SBO3L" step.
3. Carries the audit pointer. audit_event_id references a node in SBO3L's hash-chained audit log. KH echoes this ID back on its execution row, giving an auditor a single ID to walk both directions.

This receipt is the only thing the two layers exchange. SBO3L doesn't know what KeeperHub's webhook URL is. KeeperHub doesn't know what policy YAML SBO3L is running. Each side evolves freely as long as the receipt schema holds.

3. Five integration paths (IP-1..IP-5)

Once you have a receipt-as-contract, the next question is: how tight can the composition get? Five paths, each independently shippable:

• IP-1 — sbo3l_* upstream-proof envelope fields. SBO3L's KH adapter posts the receipt's request_hash + policy_hash + policy_version + audit_event_id + signature_hex as five optional sbo3l_* fields alongside the workflow body. KH stores them. Shipped on the SBO3L side; pending KH-side schema adoption.
• IP-2 — Public submission/result envelope JSON Schema. A Draft 2020-12 schema documenting the bidirectional wire shape. Adapter authors stop reverse-engineering responses from curl -v.
• IP-3 — keeperhub.lookup_execution MCP tool. Symmetric MCP tool letting auditors query execution status + run-log + sbo3l_* fields without raw HTTP plumbing. Shipped on the SBO3L side as sbo3l.audit_lookup.
• IP-4 — Standalone sbo3l-keeperhub-adapter Rust crate. Any third-party agent framework can cargo add sbo3l-keeperhub-adapter with no transitive dependency on the SBO3L policy engine. Shipped at v1.2.0 on crates.io.
• IP-5 — SBO3L Passport capsule URI on the execution row. A single optional string column — the URI to a self-contained verifiable bundle (APRP + receipt + audit segment + executor evidence + verification metadata). Capsule schema + verifier shipped; pending KH-side column adoption.

Stacking all five gives end-to-end offline auditability of every KeeperHub execution that flowed through SBO3L. Two different products, one verifiable trail.

4. End-to-end demo

Five lines in TypeScript:

import { SBO3LClient } from "@sbo3l/sdk";
import { sbo3lKeeperHubTool } from "@sbo3l/langchain-keeperhub";

const client = new SBO3LClient({ endpoint: "http://localhost:8730" });
const tool = sbo3lKeeperHubTool({ client });
// pass `tool` (or wrap as DynamicTool) into your LangChain agent's tool list

What happens when the agent calls tool.func(JSON.stringify(aprp)):

1. POST to SBO3L daemon at /v1/payment-requests with the APRP body
2. SBO3L decides allow / deny / requires_human against the policy + budget + nonce + provider trust list
3. On allow: SBO3L's executor_callback hands the signed receipt to the daemon-side KeeperHub adapter
4. KH adapter POSTs the IP-1 envelope to the workflow webhook, captures executionId
5. Tool returns {decision, kh_workflow_id_advisory, kh_execution_ref, audit_event_id, request_hash, policy_hash, deny_code}

5. The 15 issues we filed on KeeperHub/cli

Building the composition end-to-end surfaced 15 concrete, actionable asks. We filed them all on KeeperHub/cli:

• Round 1 (#47–#51) — couldn't-get-it-working frictions: token-prefix split, envelope schema, executionId lookup, sbo3l_* fields adoption, idempotency-key dedup.
• Round 2 (#52–#56) — post-integration concerns: HTTP error code catalog, public mock fixture suite, webhook timeout SLO, schema versioning headers, max payload size.
• Round 3 (#58–#62) — production-grade reliability: HMAC-SHA256 signature, workflow versioning + back-compat, response envelope JSON Schema, rate-limiting headers, delivery guarantees doc.

Each issue carries a worked reproduction, a citation to the exact line in our adapter where the friction surfaces, and a proposed shape for the fix. Five have companion draft PRs on our repo showing the consumer-side adapter change ready to ship the day KH lands the upstream contract.

6. Looking forward — joint roadmap

• Phase 1: IP-1 + IP-2 land on KeeperHub. A workflow author opts into sbo3l_* envelope fields with one checkbox. The submission/result schema is published. Adapters across the ecosystem standardise.
• Phase 2: IP-3 + IP-5 ship. Vendor-neutral MCP tool surface for execution lookup. Capsule URI column on the execution row makes "show me the proof" a one-click download.
• Phase 3: Multi-tenant trust DNS. Every agent gets its own ENS name; trust commitments behind each name (policy hash, signing key, deployer attestation) resolve from a single DNS-style query.

This isn't a replacement for either product. It's a clean composition where each layer keeps doing what it's best at, and the contract between them carries enough cryptographic proof to satisfy the most paranoid auditor.

If you're shipping an agent today, you already have an unsolved gate-then-execute problem. Start with the composition.

Full long-form version →