Agent Principal Identity
First-class agent identity with activity history
Assigns persistent identities to agents with full activity audit trails.
Read the full card →The binary
Crux Daemon
CoreCrux and the Crux Engine, shipped as one binary that runs on your machine, with its own console and a receipt for everything your agents do, from the first minute.
One binary, three planes
What actually ships when you install it
The daemon is not a client for a cloud: it is the whole machine. Memory (facts, sessions, handoffs), retrieval (lexical and graph fusion under token budgets) and receipts (CROWN signing with offline verification) run in one process on an append-only spine, reachable over MCP, HTTP and gRPC. Everything on this page works with the network cable pulled.
Releases are as inspectable as the runtime: cosign keyless signatures, CycloneDX SBOMs and SLSA3 provenance on every build, and the export, offline-verify, tamper-reject cycle is a release-blocking CI gate.
your agent
MCP · HTTP · gRPC
corecruxd one binary, port 14800
- memoryfacts · sessions · handoffs · engrams
- retrievalBM25 + graph fusion · token budgets · code maps
- receiptsCROWN · Ed25519 · offline verify
append-only spine · BLAKE3-chained sealed segments
No cloud in this picture. That is the point.
What's inside
One process, the whole stack. CoreCrux: the append-only, receipted substrate that holds knowledge and decisions. The Crux Engine: the read side that turns that substrate into evidence-backed answers. An MCP tool surface your agents call directly (over a hundred tools for memory, retrieval, sessions, coordination, and receipts), plus a plain HTTP API for everything else. And a local console at localhost:14800/console so you can watch all of it: what your agents stored, what they retrieved, what it cost, and the receipt for each step.
Runs local, proves everything
No account. No egress. The daemon signs a receipt for every write from the first minute, and verification never needs us: export your context and verify the receipt chain offline, on your own machine. The exit test is part of the product: everything required to audit us, or to leave, ships in the free binary.
From laptop to fleet
The binary does not change shape when you scale. The questions do. One daemon on one machine answers "what did my agent do?" A fleet of them across many machines raises the team-lead questions: what did all of them do, what did it cost, who authorized it. That aggregation layer is the hosted CueCrux control plane, and the same local daemon links to it. Nothing about local operation is withheld to make the hosted plane look better.
Agent & ops capabilities
Frontend Telemetry
Privacy-safe consent-aware event tracking
Client-side telemetry respecting user consent with anonymised interaction metrics.
Read the full card →
Performance Metrics
Prometheus-exposed service health with metadata
Service health metrics exposed via Prometheus with structured metadata labels.
Read the full card →Infra Agents
Guide
CueCrux’s evidence-driven upgrade system for autonomous agents.
Read the full card →Build on it
Developer guide
Extending the daemon: packs, HTTPS tools, sandboxed WASM modules, connectors, and the signed rail you publish them on. Thirteen chapters, every claim carrying a file:line reference into the Crux repository.
- Developer guideIndex and entry points for building on the Crux Daemon: who each chapter is for, the three principles the whole extension surface follows, and three copy-paste quickstarts.
- ArchitectureWhat you build against: one binary with HTTP, MCP and gRPC listeners, the data-dir layout, the auth modes and scopes, and the error shape every route returns.
- Integration packsThe crux.integration.v1 manifest field by field, all nine entry kinds, and the single validate() gate that every install path runs.
- Capabilities and grantsThe 14 declarable capabilities, the two grant models that share vocabulary but no storage, and the operator posture that decides what installed code may actually do.
- Signing and trustEd25519 signing end to end: the signature envelope, the operator keyring, trust tiers, the curator-signed community index, and the development bypasses.
- External toolsThe HTTPS extension path: the wire contract for your own service and the full enforcement pipeline the daemon runs on the way out and back.
- WASM extensionsRunning sandboxed code inside the daemon process: the wasmtime sandbox, the host ABI, hash pinning re-verified on every dispatch, and the fuel, memory and wall-clock limits.
- Connectors and syncPush-based work: the shared scheduler, the status facts a job writes, the vault watcher, and the GitHub and OpenAI connectors that ship today.
- Studio packs and workspacesShipping dashboards other people install: the crux.studio.v1 payload, canonical JSON, build and verify, the underlying fact schemas, and the curator-signed template library.
- Registry and publishingBoth distribution rails end to end, from authoring and signing through curation, sync and install, plus the full corecruxctl command reference.
- MCP surfaceHow an installed, granted extension tool reaches an agent tool list beside the built-in tools, and what happens when the passport is missing.
- Security modelA plain statement of the extension trust boundaries and which controls are enforced, which are advisory, and which are declared but not yet wired.
- TroubleshootingReal error strings quoted from the code that emits them, what each one means, and the silent-failure modes that produce no error at all.