Skip to content
Hussh
Connect MCP

One ADK — Agent Development Kit Framework

The architectural framework and runtime standard for building, orchestrating, and executing specialized personal agents under Hussh One.

Concept2 weeks ago

TL;DR: One ADK is Hussh's framework for coordinating specialized personal agents and governed actions under explicit contracts.

Relations

One ADK (Agent Development Kit) is the architectural blueprint and SDK that empowers developers to build safe, specialized agent extensions under the Hussh One ecosystem.

By establishing formal boundaries, standardized communication structures, and a hierarchical coordination tree, One ADK enables specialized agents (such as the finance specialist Kai, the Location specialist, and email orchestrators) to run harmoniously without compromising the user's security, privacy, or conversational context.

Hierarchical Agent Tree

Unlike traditional systems that rely on a single flat LLM prompt, One ADK operates on a structured Agent Tree model:

  1. The Parent Agent (Hussh One): Serves as the primary touchpoint for the user. It manages high-level conversational flow, maintains the active-state context, parses intent, and coordinates which specialized subagents are needed.
  2. Specialist Subagents: Task-focused agents (such as Kai for portfolios, or the Location agent for map check-ins) that plug into the tree. They hold deep domain intelligence but are restricted from accessing cross-domain personal databases or executing raw, unvetted system actions.

The hierarchy is intended to keep specialist context within its domain and route actions through explicit contracts. Each runtime path must enforce those boundaries in its own dispatch and authorization checks.

Governed Action Manifest

App actions exposed through the generated gateway follow its authored action contracts. Product-agent definitions and external MCP tools have separate owning contracts. The gateway does not replace agent manifests or the connector’s discovered tool catalog.

  • Pre-flight Validation: Actions exposed through the generated gateway are checked against their execution policy and availability contract before dispatch.
  • Direct vs. Confirmed Actions: Simple informational actions (allow_direct) can execute in real-time, while critical or sensitive actions (confirm_required or manual_only) are automatically flagged to require explicit user confirmation.
  • Preventing Capability Drift: Hardcoding labels or blindly trusting incoming action IDs is forbidden. All action parameters are validated client-side and server-side against their formal contract schemas.

The source candidate reviewed on September 24, 2026 uses owner-bound discovery and review of the exact proposed external MCP call. A discovered tool does not grant execution authority. Custom remote OAuth and live browser/provider acceptance remain unverified; this source wiring does not establish availability in a deployed environment.

Client-Directive Execution Model

One ADK connects backend agent capabilities to supported client interactions through Client Directives:

  • Agents can emit structured directives for actions that need a client-side interaction.
  • The active client handles supported directives in the current session and presents the appropriate interaction.
  • Ledger-governed actions require explicit client confirmation and a mounted handler; each action follows its own authorization and consent contract.

The tap authorizes, and nothing else does

A model reporting that it heard a yes is not authorization. A confirmation flag supplied in an agent's own tool call is stripped before a governed action dispatches.

That has a direct consequence for how an agent is instructed: it must not collect a spoken confirmation and then hand over to a card that asks again, because being asked twice for the same thing reads as a broken flow rather than a careful one.

A governed action needs an owner on the device

When execution is delegated to the confirmation ledger, an action with no handler mounted in the browser is not a safe no-op. It is a dead end: the agent offers the capability, the person confirms it, and nothing happens, with no error raised to say so.

Any action routed this way therefore needs a test asserting a handler exists for it.

Intelligence Over Rules

One ADK agents carry their constraints in their system instructions, not in deterministic branches downstream of the model call. A rule placed after a model call changes behaviour without changing anything visible in the prompt, which makes the prompt impossible to debug against what the system actually does.

Three crossings are named and forbidden: a rule that decides instead of the model, one that discards what the model returned, and one that skips the model while reporting as though it ran. Two narrow exceptions apply, for a failed model call and for an integrity guard against unrecoverable loss. See Intelligence Over Rules for the full statement and the measured evidence behind it.

Model and runtime choices

One ADK separates agent behavior from provider integration through explicit runtime contracts. The available model and transport depend on the agent path and deployment.

The current text-model catalog offers Gemini 3.8 Flash and Gemini 3.7 Flash. Where a text path supports per-person preferences, a validated choice takes precedence over the lane default; otherwise the configured lane default applies.

Live voice has a separate model and transport contract. The routed One Voice relay uses its own explicit Vertex configuration. The ADK native-audio compatibility path has a separately declared model and transport matrix. See Real-time Voice Transport for the voice contract.

Sources