Skip to content

Why hgateway

The pain with existing impl

Every ADK's provided interrupt primitive hits the same six walls:

  • Responders get a bare prompt and two buttons — nothing to work with, so they guess, or pick whatever feels most right, never sure it's actually right.
  • A silent responder stalls the HITL indefinitely — nobody's watching what happens if they don't answer.
  • Every HITL change required deployment — wrong person got the ask? Re-routing to someone else means a code change and a deployment, not a click.
  • A responder's reasoning is never captured — even if they explain themselves in the same channel, nothing structured is kept; it's gone once the thread goes quiet.
  • Every HITL is treated like the first time — nothing gets quieter or smarter over time, it's just raised the same way, every time.
  • No lever to enforce a rule, only code to ship — Enterprises can't apply a rule to a specific HITL type, or to a whole team of agents.

These six walls hit a single agent from day one — they just get louder and harder to ignore as more agents pile onto the same hand-rolled plumbing, each reinventing routing, escalation, and resume logic that has nothing to do with what the agent is actually for.

The idea: decouple HITL from the agent

All six walls above point at the same root cause: HITL handling needs a dedicated system of its own, not something bolted onto each agent by hand. And a dedicated system is only feasible once HITL is decoupled from the agent raising it — otherwise every agent is still the one holding the lifecycle.

Decouple it, and that dedicated system can own the complete lifecycle of a HITL end to end: who gets notified, on what channel, what happens if they don't respond, and how the answer gets back to the agent. That decoupled system is hgateway — or rather, Ved, the hgateway agent that owns that lifecycle. The agent's job shrinks to "ask a typed question, get a typed answer."

What decoupling unlocks

Once HITL is centralized in Ved instead of re-implemented per agent, here's what that buys you — mapped against the pain points teams hit hand-rolling this themselves.

Available today (current release)

Features

  • Interactive UX — the responder can interact with a raised HITL:
    • Request an impact analysis to estimate the blast radius of choosing an option.
    • Get a system recommendation.
    • Forward it through a native forwarding layer.
    • Ask a question on-thread and get replies before deciding.
    • See the full context of the raise, so they have everything they need to understand it before responding.
  • Proactive staleness handling — Ved lets you set up auto-re-routing or auto-responding based on Ttl, so a HITL still gets a response even if the first responder goes silent.
  • On-the-fly changes without a deploy — nudge or remind a responder, fork a HITL, or route it to someone else, all without touching agent code or shipping a deployment.
  • Reasoning capturing — asynchronously captures the responder's reasoning behind a resolution, completing the decision trace for the raised HITL.
  • Governance controls — configure routing rules and feature controls at the HITL, agent, or tenant level, and manage how expired HITLs are handled.

Dashboard

Decoupling HITL from the agent doesn't just fix the six walls above — it opens up an entire operational layer on top of the gateway that couldn't exist while HITL lived inside each agent. A dedicated dashboard, dashboard, gives you:

  • A complete HITL timeline and trace view.
  • Live triaging of what's currently in flight.
  • Insights into who's a potential single point of failure, p95 time-to-respond, and other interaction metrics.
  • A dedicated config layer per tenant/agent/HITL call site, so on-the-fly changes happen with no deployment needed on the agent's side.

Coming in a future release

  • A learning stack — reduces noisy and recurring HITLs over time, and gives responders their historical resolution outcomes plus recommendations for the current one, based on their past interactions.
  • Strong/advanced governance controls — org-level policy enforcement across HITL types and agent teams.

Where the SDK fits

hgateway-sdk enables builders to register their HITLs with Ved, and the agent resumes with the response. It doesn't own anything past that handoff itself — it's the on-ramp. Everything above is Ved's job; the SDK's job is making that handoff a single, well-typed call.

Next: see how this flows end-to-end in Architecture, or skip straight to the Integration Guide to integrate.