One, the private agent platform
Hussh's approved top private-agent direction: One is the relationship layer and your private agent on your own data plane, while Hussh stays the control plane that enables exchange without holding your holdings.
TL;DR: One is Hussh's private-agent platform: the relationship layer for consented use of context and specialist capabilities. Owner-isolated private-agent pods are an approved architectural direction; current runtime, deployment, and information custody claims must be tied to a named path and verified evidence.
Relations
- Kai
- Nav
- Email Agent
- Gmail Agent
- PCHP
- iBrokerage
- BYOA
- Connected Systems
- Source Library
- One Activity Feed
- Three-layer architecture
- Apple frame
- Hermes Agent
- One ADK β Agent Development Kit Framework β Runtime and agent hierarchy
- π€« Private Agent One β mission and purpose β mission and purpose
- Agents agreeing on a time β the most-asked use case β agent scheduling concept
- π€« Yellow Pages β the road to 100% US coverage β coverage proposal
What One is
A private agent platform: your context becomes useful only through consented specialists and clear receipts. One is the relationship layer; PCHP is the consent protocol underneath; specialists such as Kai, Nav, KYC, and Gmail Agent do bounded jobs instead of collapsing into one generic assistant.
The naming discipline is deliberate. As of mid-2026 the agentic-product market is racing to ship "an AI assistant" or "a personal agent." The risk for Hussh is that One becomes a generic noun, the platform name disappears, and the brand collapses into another assistant SKU. The capitalized One plus named specialists gives users, builders, and partners a vocabulary for separate responsibilities.
Control plane and information custody
Hussh provides the consent and product control surfaces. An owner-isolated private-agent pod is an approved architecture for a distinct deployment topology; it does not describe every current runtime. Shared-runtime services may process requests, and the storage and custody boundary depends on the data path and its contract.
The architectural direction separates agent behavior, consent authority, and information storage. Describe where readable information is processed or retained only from evidence for the specific path and environment. Do not infer universal custody guarantees from the target pod architecture.
Consent is explicit and scoped
Every exchange rides PCHP: a single-use, signed, revocable grant scoped to exactly what the moment requires. Consent is not a one-time toggle buried in settings; it is issued per exchange, legible, and revocable. A specialist that needs a slice of context gets that slice for that purpose and no more, and every grant leaves a receipt you can read.
Consent authorization and information custody are separate concerns. A grant can establish that an exchange is permitted; the relevant runtime and storage contracts determine which components process or retain readable information.
Core Interaction Surfaces
- Home & Voice Head: Voice and glanceable cards use the One persona. Voice has its own runtime, model, transport, and deployment contract.
- One Activity Feed: A cross-domain, read/unread-tracked activity surface aggregating events from Consent, Location, Kai, KYC, Connected Systems, and Connections.
- Specialist Hubs: Analysis, Consent Center, and Marketplace surfaces standardized on canonical swipeable-tab primitives and unified card design tokens.
Specialist model
One should feel simple to the user, but the system underneath should stay separated by responsibility.
- Kai: finance and investor specialist. Warm, present, brief. Assembles financial context, portfolio and import state, market questions, and decision receipts. Portfolio Advisor (RIA) and Investor are fully consolidated as nested subagents under Kai (rather than One-level siblings), aligning all finance turns under a single agent.
- Nav: privacy and consent guardian direction. Precise, composed, audit-grade. Makes scope, exposure, revocation, and audit legible. Nav now directly manages the consolidated Consent Center including the relationships graph.
- KYC: identity and verification specialist lane. It should not be erased into Kai or Nav when identity proof is the real job.
- Email Agent: inbox specialist. Quiet, structured, efficient. Automates inbox scanning for priority nudges and inline chat drafts, while inbox triage stays with general email.
- Gmail Agent: receipts and purchase-memory specialist. Binds to the user's email tile, indexing purchase records, flight confirmation receipts, and travel reservations into secure memory (formerly Personal Data), feeding other specialists like Kai without full email exposure.
The split is on purpose:
The specialist that helps you and the guardian that protects you should not be the same unchecked authority.
Product boundaries
- Chat, voice, and glanceable cards are interaction surfaces for One. Specialist work and action receipts follow the same scoped authority boundaries; availability depends on the deployed path.
- Not a provider promise. Supported text paths may expose a person's choice among available models; the lane default and Live voice model are configured separately.
- Not a data lake. Information storage and sharing follow the contract for each runtime and data path.
- Not an SSO. PCHP is a consent protocol, not an identity provider.
- Not one universal deployment. Owner-isolated pods describe an architectural direction; current runtime and custody claims need deployment-specific evidence.
Brand discipline
"One" is always capitalized in Hussh product contexts. The numeral "one" used non-product-wise is the only allowed lowercase.
Direction and boundary
- Current direction: One is the approved top private-agent direction, the relationship layer that summons specialists through scoped consent and policy boundaries.
- Architectural direction: owner-isolated private-agent pods are a target topology. This does not establish the topology or information custody of every current deployment.
- Consistency rule: where an implementation diverges from the private-agent north star, the implementation moves toward it, not the other way around.
Hosting choices
One offers Hussh Shared and an owner-controlled private agent in the owner's cloud. Shared is an explicit choice. An account without a recorded choice returns to the hosting chooser; an existing assignment or setup in progress is preserved. Detaching a private agent does not silently select Shared. New Hussh Pods provisioning remains paused.
The current development direction supports Google Cloud and Azure with direct app-to-private-agent access. Each cloud's deployed capabilities require its own verification. Connecting a model is separate from choosing hosting, and does not provision a private agent for a Shared account.
Evidence boundary, 2026-10-06: these hosting rules reflect the approved product direction and the development implementation under review. This correction does not establish UAT or production readiness.