BYOA — Bring Your Own AI / API / computer / system
Hussh's architectural commitment. The user's keys, the user's models, the user's choice — Hussh provides the consent surface, not the AI vendor lock-in.
TL;DR: BYOA stands for Bring Your Own AI / API / computer / system. It is Hussh's architectural direction: user choice for models, APIs, devices, and systems should stay portable, while PCHP, vault, PKM, and audit authority keep data access scoped. Status as of 2026-05-19: Architectural direction. Specific provider/key/runtime behavior requires checked implementation proof.
Relations
- One — runs against BYOA models.
- Kai, Nav — both are model-agnostic by commitment.
- PCHP — consent at the data layer, not the model layer.
- Three-layer architecture — BYOA is what keeps the Platform layer model-neutral.
- BYOA Architecture — Architecture diagram
- Public vs Private Surface Map — Public vs private surface map
- BYOA — Reference Adapter (TypeScript) — Reference adapter (TypeScript)
- Hermes Agent — the One runtime (Nous Research framework) — the open-source runtime that delivers BYOA in practice
The four "Y"s
- Bring Your Own AI — the user (or their org) picks the model: hosted, open-source, local, on-device, or enterprise-approved. Hussh runs against the model the user authorizes.
- Bring Your Own API — the user holds the key. Hussh holds keys to data; not keys to vendor APIs. If the user rotates their key, the user is in control.
- Bring Your Own Computer — local-first where possible. On-device inference for sensitive context; cloud only when explicitly consented.
- Bring Your Own System — the user's accounts (Gmail, Schwab, Plaid, calendar, photos) stay where they are. Hussh integrates; it does not migrate.
Why this matters strategically
The agentic-product market in 2026 is racing to lock users into a vendor's model. The pitch is convenience; the trap is lock-in. Hussh's bet is that consumers and enterprises both eventually want their data and their model choice to be independently portable. BYOA bakes that assumption into the architecture so it cannot drift.
This commitment is what makes PCHP credibly vendor-neutral consent infrastructure. A consent protocol owned by an AI vendor is just that vendor's TOS in a costume. PCHP can position as "SSL/TLS for the AI agent economy" only because the platform underneath does not care which model is on the other end.
What BYOA is not
- Not "configure your own LLM endpoint." It's a guarantee that the user's choice is honored across every Hussh surface, with consent applied uniformly.
- Not "we don't run any models." Hussh runs whatever the user authorizes; the user is the principal.
- Not a feature flag. It is an architectural constraint applied at design time.
Enterprise architecture status refresh
- Current repo truth: BYOA is future direction unless a checked provider/key/runtime path proves the specific behavior.
- North-star direction: user-chosen models, APIs, or local compute must stay subordinate to Hussh consent, vault, PKM, and audit authority.
- Not shipped / not implied: BYOA is not a second canonical memory store, second trust plane, or direct raw PKM feed to partner/local compute.
Sources
- Three-layer architecture — where BYOA lives in the stack.
- PCHP — consent is at the data layer, not the LLM layer.
- One — platform direction BYOA supports.