Under the hood

Enterprise AI infrastructure. Post-quantum secure. Compliance-native.

This is how Console is built: the runtime that employs your agents, the front door that carries their traffic, and the root of trust that issues every identity in between.

The path a request takes

One product, three planes.

Every request travels the same road. Each section further down this page is a zoom into one stop on it.

  1. Native app · desktop · edge device

    Speaks the wire protocol, holds no master key

    A device signs with a key it derived itself and never transmits. What leaves the handset is a sealed frame, not a bearer token that works for whoever holds it. A constrained edge device joins the same wire with a post-quantum key exchange and a pre-shared key rather than a signing identity.

    ProtocolAWP
    Signs withML-DSA-65 (app, desktop)
    Edge deviceML-KEM-768 + PSK
  2. aethyr-node

    The front door

    Devices do not reach Console directly. aethyr-node proves who is calling, binds the session to one tenant, gates what that caller may send, and carries the traffic the rest of the way.

    Session keyML-KEM-768
    Frame gate137 types
  3. Console

    The runtime, and the authority behind the door

    Console runs the agents, assembles their context, enforces the compliance frameworks, and signs the audit record. It also issued the certificate that let aethyr-node open the door in the first place.

    Audit recordSigned, chained
    Data scopePer organization
Inside the runtime

Six planes, running at once.

These are not steps in a pipeline. They are concurrent layers of one deployable, which is why a request touches all of them and why none of them can be bought separately.

Data foundation

Three databases, each doing the job it is built for, with every query scoped to one organization by construction rather than by convention.

  • PostgreSQL as the system of record, 204 schema migrations behind it
  • A Neo4j knowledge graph for entity and relationship reasoning
  • Redis for session state, tool result caching, and steering queues
  • Credentials sealed at rest under a post-quantum key exchange
System of recordPostgreSQL
Knowledge graphNeo4j
Session and cacheRedis
Migrations204

Agent runtime

A full execution pipeline with cost accounting, approval gates, and constitutional constraints. Not a wrapper around a model SDK.

  • One loop engine serves both supervisor sessions and delegated sub-agents
  • Constitutional constraints enforced by the pipeline, not asked for in a prompt
  • A budget ledger gates spend before the call goes out, not after the invoice arrives
  • Human approval checkpoints on high-stakes actions, with the wait recorded
  • Context compression keeps long sessions inside the window without losing the thread
PlanTask decomposition
ExecuteTool calls and reasoning
ReflectIn-loop self-evaluation
BudgetCost and policy check
StreamResponse delivery

Context assembly

Before any model call, seven providers assemble the working context in parallel. The model sees a curated window, not a database dump.

  • Vector retrieval, graph retrieval, documents, customer records, compliance state, financial context, and corrections the system has already learned
  • Graph reasoning on top of vector retrieval, so relationships survive the lookup
  • Each provider decides whether a query is relevant before it does any work
  • Providers resolve concurrently under a hard timeout, so one slow source cannot stall a turn
  • Results are ranked by priority and fitted to the token budget at assembly time
Providers7
ResolutionParallel
GraphNeo4j
GatingPer provider

Trust and identity

Agents, humans, devices, and nodes are the same kind of thing: a principal with a cryptographic identity, a set of privileges, and an audit record.

  • Privilege-based access control across 102 privileges, checked by capability and never by role name
  • Every organization holds a commissioner key, and every agent, node, and device identity derives from it
  • Agents carry their own DID and signing key, so work is attributable to the agent rather than to a human login it borrowed
  • An agent private key is never stored. It is re-derived on demand and zeroized after use
  • Device enrollment is gated on hardware attestation, or a TPM quote on a server
Privileges102
Agent identityDID + signing key
EnrollmentAttestation-gated
Wire layer137 frame types

Compliance as code

Frameworks modeled as code, with evidence collected while the system runs rather than assembled the week before an audit.

  • 24 frameworks including SOC 2, HIPAA, GDPR, PCI DSS, ISO 27001, CMMC, FedRAMP, StateRAMP, FINRA, SOX, the EU AI Act, and the NIST AI RMF
  • Automated checks and evidence capture where the platform holds the evidence, about 14% of controls today, with structured attestation workflows for the rest
  • Evidence ties back to the agent action that produced it, so a sample can be traced
  • POAM tracking and SPRS scoring for defense supply chain posture
  • Every verification run is itself an audit record an assessor can sample
Frameworks24
CMMC practices110
EU AI ActAI system obligations

Post-quantum cryptography

NIST-standardized algorithms, selectable per deployment. Level 3 by default, Level 5 where the deployment calls for it, and older records stay readable across the change.

  • Level 3 by default: ML-KEM-768 key exchange and ML-DSA-65 signatures
  • Level 5 for high-assurance deployments: ML-KEM-1024 and ML-DSA-87, aligned to CNSA 2.0
  • One setting moves the platform between levels, and a SCIF-tier deployment selects Level 5 on its own
  • Verification dispatches on the algorithm recorded on each artifact, so raising the level never strands anything already written
  • Security audit entries are hash-chained and signed, then re-verified nightly against published keys
ML-KEM-768FIPS 203 · Level 3
ML-DSA-65FIPS 204 · Level 3
ML-KEM-1024FIPS 203 · Level 5
ML-DSA-87FIPS 204 · Level 5
The front door

aethyr-node

Devices do not talk to Console directly. They talk to aethyr-node, which proves who is calling, gates what they may send, and carries their traffic under post-quantum encryption the whole way.

  • The Aethyr Wire Protocol is binary-framed and carries the caller identity and tenant binding in the frame header, with a compact profile for constrained links
  • Every session is bound to a verified device identity and one tenant, with a fresh key exchange per connection and a replay window per peer
  • Console API calls travel inside a sealed frame end to end, rather than as an ordinary HTTPS request
  • Defended against confused-deputy and replay attacks at the authentication boundary
  • TLS 1.3 outside, with a hybrid post-quantum key exchange preferred, and post-quantum AWP inside. The cryptographic modules are not yet FIPS 140 validated
  • The frame codec core is formally verified: 929 of 929 checks discharged at Gold level, none unproved and none justified away

aethyr-node ships as part of a Console deployment. It is the device on-ramp, not a second product to buy.

TransportAWP
Session keysML-KEM-768
IdentityML-DSA-65
Frame gate137 types
Outer layerTLS 1.3, FIPS
Codec proofs929 / 929
The return path

The front door gets its keys from the thing it protects.

A node proves itself to Console with a post-quantum signature and a hardware attestation. Console verifies both, then mints its certificate. Private keys never leave the device and never reach the key store, which means the authority that admits a node to the mesh is the same system whose data that node is guarding. One root of trust, one chain of custody, one place an auditor has to look.

ProofML-DSA signature
HardwareApp Attest · Play Integrity
ServerTPM 2.0 quote
IssuedCertificate, per node
Research track

What comes after the front door

Beside the product sits a research track: agents that carry their full cognitive state between machines, hyperdimensional memory in place of a vector index, and holonic self-organization where squads of agents auction work among themselves. The code is real and actively developed. It is deliberately not on the production path, and nothing on this page depends on it.

See the research

Ready to build?

Read the documentation, or book a technical deep-dive with the engineering team.