X-HubThe user-owned AI control plane.

Governed execution for agents, terminals, local runtimes, and remote channels without making the client, plugin bundle, or cloud vendor the trust root.

Read the architecture

Why not just an agent?

See the security model

Hub-owned trust boundary

Routing, memory truth, grants, policy, audit, and kill authority stay in the Hub instead of leaking into every client surface.

Governed autonomy

Execution power, supervision depth, review cadence, and intervention behavior are treated as separate controls, not one vague auto mode.

Local-first multisurface runtime

Local models, paid models, voice surfaces, and remote channels can sit under one governed control plane with user-controlled release timing.

Public technical preview

Build agents that can actually run projects, while keeping execution governable, inspectable, and locally owned.

X-Hub is for teams that have already realized raw agent capability is not the hard part. The hard part is trust geometry: where memory truth lives, who owns grants, where audit belongs, how supervision works, and which surface gets final authority. X-Hub moves those responsibilities into the Hub, so clients can stay fast without silently becoming the trust root.

Hub-first trust modelGoverned autonomy tiersVoice and channel supervisionLocal-first provider packs

Memory, grants, and audit stay centralized.Execution surfaces can change without rewriting the trust boundary.

High autonomy does not mean root without oversight.Supervision, intervention, and system safety controls still apply.

Remote channels enter through one governed ingress.External channels and paired interaction surfaces stay attached to the same control plane.

User-owned local runtime remains a first-class path.Models, keys, privacy posture, and release timing stay in the user's hands.

Control Plane SnapshotHub synchronized

Trust RootHub-owned

Policy, grants, audit, memory truth, and kill authority stay in one place.

Execution ModelGoverned autonomy

Execution rights stay separate from supervision depth and review cadence.

SurfacesPaired surfaces + remote channels

Voice surfaces, generic clients, operator channels, and delegated runners stay attached to the Hub.

RuntimeLocal-first by design

Local models, provider packs, and optional paid models route through one control plane.

Operating BriefCurrent thesis

Do not let the UI, plugin bundle, or cloud vendor become the hidden control plane.

Separate execution rights, supervision depth, review cadence, and intervention path.

Treat skills, channels, and voice actions as governed capability paths, not loose scripts.

Built for serious operators

For teams that want agents to execute without surrendering the trust boundary.

X-Hub is not another terminal wrapper. It is a system architecture for governed AI execution: one Hub for memory truth, constitutional policy, grants, audit, runtime truth, and execution safety; one paired X-Terminal for rich operator interaction; thinner generic clients that can consume governed capabilities without silently becoming the trust root.

Hub-ownedPolicy, grants, audit, routing, kill authority, and memory truth stay centralized.

Fail-closedMissing readiness, ambiguous grants, or broken trust state should stop execution rather than fake safety.

Local-firstRun local models, multimodal runtimes, and user-owned infrastructure without giving up governance.

Why it feels different

Not terminal-first The terminal can be fast, replaceable, and productized without inheriting final trust authority.
Not prompt-only safety Memory-backed constitutional guidance, grants, audit, and runtime clamps reinforce each other.
Not black-box autonomy Higher execution range does not erase supervision, correction, or kill-switch posture.
Not cloud-default control Permissions, keys, release timing, privacy posture, and remote-provider usage remain user decisions.

Core system signature

One architecture, four reinforcing planes.

The strength of X-Hub is not one isolated feature. It is the combination of trust-plane redesign, governed autonomy, governed skills, memory truth, and multimodal supervision under one user-owned control plane.

Trust plane

Move the trust anchor out of the terminal, plugin bundle, and vendor cloud default into the Hub.

Governance plane

Separate execution rights, review depth, intervention mode, and cadence so autonomy remains governable.

Execution plane

Treat skills, tools, automation, and channel actions as governed capability paths, not loose script power.

Memory and evidence plane

Keep memory truth, audit, runtime truth, and review evidence attached to the system of record.

How the system is shaped

Product surface on top. Trusted control plane underneath.

Trust and control plane X-Terminal follows the full governed path. Generic terminals can still use Hub capabilities without becoming equivalent trust roots.

X-Hub deployment and runtime topology diagram

Deployment and runtime topology The user-owned Hub host stays central while local runtimes, channel workers, and optional external services remain governed boundaries.

Source-aware voice authorization

Remote-channel pending grants can be announced, repeated, targeted, and approved through a Hub-governed voice challenge loop.

Safe operator-channel onboarding

Slack, Telegram, and Feishu ingress can enter discovery, require local admin approval once, auto-bind, and run a first smoke under Hub control.

Provider-pack truth for local runtime

Embeddings, speech, vision, and OCR are moving under one local-runtime product surface with compatibility policy, quick bench, and fail-closed provider truth.

Why not just another agent stack

Capability matters. Trust geometry matters more.

Typical terminal-first agent

X-Hub

Prompts, tools, memory, secrets, and execution often collapse into one runtime trust zone.

Trust anchor moves into the Hub so terminals can stay replaceable execution surfaces.

Higher autonomy often means blurrier supervision and weaker runtime truth.

Autonomy, review, intervention, and clamps are separated into explicit controls.

Plugins and skills often expand privilege by default once installed.

Skills are moving through a governed trust chain with manifests, pinning, review, and revocation.

Cloud defaults often become the hidden control plane.

User-owned Hub keeps permissions, policy, keys, audit, and release timing under local control.

Want the fuller argument? Read why X-Hub is not just another agent stack.

Who this is for

Teams that need real execution, but cannot afford soft trust boundaries.

X-Hub is especially well suited for security-conscious software teams, operator-led automation programs, public-sector and regulated environments, and serious individual builders who want a safer local-first posture than terminal-only AI tools usually provide.

What to expect now

Public tech preview, not a polished mass-market product.

The architecture thesis is already concrete. Core runtime paths are real. Product polish, onboarding, deployment UX, and some capability surfaces are still moving fast. This site is meant to make the system legible before every surrounding edge is finished.

Start from the right layer

Start with the public architecture story. Deeper implementation detail will expand as the product surface stabilizes.

This site is the selective public narrative layer for the repository. The pages here are meant to make the system legible without turning every still-moving implementation path into front-page product copy.

Architecture Security Governed Autonomy Channels and Voice Local First Skills Documentation Map