One ADK — Agent Development Kit Framework

TL;DR: One ADK is Hussh's Agent Development Kit — the core architectural framework for specialized personal agents to execute actions safely and cooperatively under the parent-level Hussh One agent.

Status as of 2026-07-08: see body.

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:

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.
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.

By routing through a structured tree rather than a flat pool of APIs, One ADK ensures that a specialist only receives context relevant to its domain and can never bypass user-configured boundaries.

Governed Action Manifest

Every action, capability, or tool that a specialized agent can execute is governed by a central Gateway Manifest. This manifest serves as the single source of truth for the entire ecosystem:

Pre-flight Validation: Before any tool is invoked or any chat surface is rendered, the system validates the action's execution policy and availability parameters against the manifest.
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.

Client-Directive Execution Model

One ADK bridges backend agent intelligence with frontend interactive UI components via Client Directives:

Instead of agents performing sensitive actions (such as financial transactions, editing consent grants, or sharing live location streams) silently in the background, they emit structured directive frames (e.g., needsConfirmation: true or kind: action).
The user's device intercepts these directives in the active session (such as the Agent Bar or chat workspace) and translates them into secure, interactive cards, panels, or confirmation overlays.
This "human-in-the-loop" model guarantees that sensitive data transactions are only sealed and delivered upon the user's physical, authenticated approval.

Provider-Neutral BYOA Commitment

Consistent with Hussh's Bring Your Own AI (BYOA) commitment, One ADK is entirely model-agnostic. Rather than being bound to a single model provider or cloud runtime, it decouples the reasoning engine from the underlying infrastructure:

Runtimes are defined via generic configuration files and requests map across unified request/response adapters.
Light local models can handle cheap parallel tasks (e.g., text summarization or simple checklist checks), while heavy reasoning models handle complex analyses (e.g., investment debates) or high-fidelity full-duplex voice streams.

Sources

Hushh Research Repository