A deeper, teachable reference for the field: where your app, API, or agent sits relative to Agent One, PCHP, and the open rails; the consent handshake in practice; patterns for apps, APIs, and agents done the consent-first way; personalization on the 🤫 One Human Agents Network and the roadmap Verified Network; and the values, safety, and law that keep it principled. Read the field-guide overview first at /build.
Your solution never becomes the owner of the human's data. Agent One is the private layer on hardware the human owns; it holds the context and answers requests. You build outside that boundary and ask across it - never around it.
Every crossing runs the same four phases: identity, consent, scoped exchange, receipt. PCHP is not a wall you route around; it is the gate you build through. If your design touches personal data anywhere else, the design is wrong.
MCP reaches tools and data; A2A talks to other agents (and other Ones); AP2 settles payments; UCP transacts commerce. PCHP wraps each so the reach is consented and every act writes a receipt to the owner's ledger.
The same four phases every time, grounded in the live hushh MCP and REST surfaces on /developers. This is the gate you build through, not a wall you route around.
Establish who is on each side without exposing the secrets behind it - the way SSH proves a machine. In practice your solution presents itself and resolves the human's One; nothing private is handed over just to say hello.
Discover the scopes actually available for this human (they come from their own indexed context, not a global menu), then request exactly one with a transparent reason, a purpose, an expiry, and a timeout. The owner approves with a biometric unlock, or denies.
On approval you receive a signed, time-limited consent token and the encrypted scoped export - ciphertext plus wrapped-key metadata your connector decrypts client-side. You get the field you asked for, scoped to the moment, and nothing more.
Both sides sign a receipt and both keep a copy on a ledger the owner can read and revoke. Validate the token (signature, expiry, revocation, expected scope) before you use it, and treat a revoked or expired token as a hard stop.
An app or experience the customer's ICP interacts with directly - a dashboard, a booking flow, an advisor surface. It renders something personal, so it needs personal context.
Reach for the app pattern when a person is in the loop, tapping and deciding in real time. The human's presence is what makes the consent prompt natural and honest.
Request the scope right when the screen needs it, with a reason the human can read, then render only what came back. Do not pre-fetch a profile "just in case." Let the receipt be visible, and let the human revoke from inside the experience.
In words: a summary card asks One for attr.financial.* with the reason "show this advisor your portfolio snapshot for this session," scoped session-only. The owner approves; the card renders the snapshot; a receipt lands on their ledger; when the session ends, access ends. No copy is kept.
A backend integration - your service talking to One's REST or MCP surfaces, or your API that other systems call. No human is tapping in the moment; the contract carries the consent.
Reach for the API pattern for scheduled work, server-to-server flows, and anything that must run without a person watching. The discipline gets stricter, because there is no human present to sanity-check a scope.
Never hold standing access. Carry a signed, scoped, expiring consent token, validate it on every call, and request a fresh consent when the purpose changes. Log what you accessed and why. Least privilege is not a nicety here; it is the contract.
In pseudocode: for each consented account, validate_token(scope=attr.financial.reconcile); if valid and unexpired, get_encrypted_scoped_export(); decrypt client-side; reconcile; write the receipt. If the token is revoked or expired, skip and notify - never fall back to a broader grant.
An agent or AI that plans, uses tools, and gets a job done for the human - the highest-leverage pattern, and the one that most needs guardrails. It reaches tools over MCP and other agents over A2A.
Reach for the agent pattern when the job is multi-step and worth delegating: research, coordination, settlement. It shines when it works with the customer's own One rather than around it.
Give the agent the narrowest set of tools for the job, a clear purpose, and a stop condition. Every data read is a scoped PCHP exchange; every payment (AP2) and every purchase (UCP) is gated and receipted. Keep a human in the loop on anything irreversible.
In words: an agent asks One for attr.travel.preferences and a date window, proposes an itinerary, and - only on explicit approval - settles the booking over AP2. Each step is scoped and receipted; the human approves the spend; the agent stops when the trip is booked.
The 🤫 One Human Agents Network is live - humans accepted by default, each with their own private Agent One. The 🤫 Agents Verified Network, with biometric and human-to-human verification, is the roadmap. Design for that world; ship honestly in this one.
A network of humans, each represented by their own private Agent One. Humans are accepted by default - the network is open to people, not gated behind an approval committee. Ones meet over A2A on behalf of their humans, and every exchange between them runs the PCHP handshake.
A planned layer for safety and security: human biometric verification and human-to-human verification, designed to be privacy-preserving. It is the model and the vision, not a shipped feature. Do not build as if verification is live, and do not describe it to a customer as if it is.
Design for the world where verification exists, while shipping honestly in the world that is here. Assume least privilege between agents, make consent legible on both sides, keep receipts, and let humans revoke. Build so that when the Verified Network arrives, your solution simply gets safer - no rework.
Consent, privacy, security, transparency, and staying strictly within the law are not constraints bolted on at the end - they are the design. When we say we transform rigid systems, we mean we operate transparently and lawfully while openly advocating and building for better, more flexible ones. The consent-first system is the better system. We never evade, game, or circumvent laws, regulations, or platform rules. Here is the short list every builder carries.
Ask for one scope at a time, with a reason, a purpose, and an expiry. Make consent legible and revocable. Treat every personal-data access as a PCHP exchange with a receipt.
The human always decides. Keep a person in the loop on anything irreversible - a payment, a purchase, a share. Amplify their agency; never replace their judgment.
Least privilege, scoped access, client-side decryption, no shadow copies. Design so the private thing cannot leak, rather than promising it won't.
Operate transparently and lawfully. Where systems are rigid, advocate openly and build for better ones - in the open, on the record, within the rules.
No bulk copies, no "give us everything," no profile assembled behind the human's back. If you are storing personal data to avoid asking again, stop and ask again.
Never treat PCHP as an obstacle to design around. No standing access, no broader grant used to satisfy a narrower need, no silent data flow. The gate is the design.
Do not describe the Verified Network, biometric, or human-to-human verification as live. Say plainly what ships today (Agent One, PCHP, receipts, the rails) and what is planned.
We win by being transparent and lawful, not by loopholes. No evading, gaming, or circumventing laws, regulations, or platform rules - ever. Transparency is the strategy.
The consent layer in full: identity, consent, scoped exchange, receipt - composable over MCP, A2A, AP2, and UCP. Read it at /pchp.
The live hushh MCP, REST surfaces, consent flow, scopes, HCT tokens, and encrypted scoped exports. Start at /developers.
A semester you build through until you can ship a genuinely useful working agent, with a certification to prove it. Enroll at /academy.
Outside the owner's boundary, asking across it. Agent One is the private layer that holds the human's context on hardware they own. Your solution never becomes the owner of that data; it requests scoped access through PCHP at the boundary, and reaches tools, other agents, payments, and commerce over MCP, A2A, AP2, and UCP - each wrapped in consent and a receipt.
Four phases, every time. Identity: establish who is on each side without exposing secrets. Consent: discover the scopes actually available for this human, then request exactly one with a reason, purpose, and expiry; the owner approves with a biometric unlock. Scoped exchange: receive a signed, time-limited token and the encrypted scoped export, decrypted client-side. Receipt: both sides sign and keep a copy on a ledger the owner can read and revoke. Validate the token before every use.
No. The 🤫 One Human Agents Network is the live model - humans, each with their own private Agent One, accepted by default, meeting over A2A with the PCHP handshake between them. The 🤫 Agents Verified Network - human biometric verification and human-to-human verification, designed to be privacy-preserving - is planned and on the roadmap. Build on what is live; design for what is coming; never describe the Verified Network as if it already ships.
As lawful, transparent advocacy - not as evasion. The consent-first system, with the human at the center and privacy by construction, is itself the better system. Where existing systems are rigid, we operate strictly within the law while openly building and advocating for more flexible, more humane ones. We do not evade, game, or circumvent laws, regulations, or platform rules. Transparency and lawfulness are how we win, not an obstacle to it.
Put your solution outside the owner's boundary, ask across it with PCHP, scope every tool and action, and keep a human in the loop on anything irreversible. That is how you build something personal, safe, and principled on 🤫 One.
One is a product of Hushh Technologies Corporation (brand: 🤫 “hussh”), an independent company. One runs on third-party silicon, systems, and cloud; all company names are used solely to describe the platforms on which One software runs. Hushh Technologies is not affiliated with, endorsed by, sponsored by, or partnered with any company named.