Agent-native workspace and artifact store

Durable agent workspaces.

NoKV publishes crash-consistent, versioned Workbench state over immutable S3-compatible artifacts, with shard-local metadata for paths, snapshots, commits, restore, and GC.

Quickstart View on GitHub →

Third-party listings

CNCF Cloud Native Landscape LF AI & Data Landscape Awesome Rust DBDB.io — historical Go profile

Building with NoKV

LoopX 3.8K GitHub stars
Lingtai AI 628 GitHub stars
OpenViking 28.1K GitHub stars
Hermes Agent 228K GitHub stars
heima 72 GitHub stars

The navigation tax

Serverless agent workers still need durable boundaries.

Workers restart, fan out, and share infrastructure. Enterprise workspaces need tenant isolation, authenticated access, and stable, version-pinned reads while other agents write.

Today: pinned snapshot views, shard-local crash-atomic publication, and CoW fork-to-restore.

Next: enforced tenant identity, policy, and live-workspace freeze.

Animated demo: a small robot agent works away, emitting scattered run state — a config.yaml, params.json, two object-store keys, two database rows, and an outputs folder — which then converges into one NoKV Workbench presentation root under /agents/research/wb. The namespace then stays live: run-0143 publishes new artifacts as typed events, a leased snapshot freezes run-0142, and an agent uses workbench_search and workbench_grep.

Scattered

state scatters across folders, JSON files, object-store keys, and database rows

  • yaml ~/experiments/run_0142/config.yaml
  • json params.json {"lr": 3e-4, "batch": 256}
  • s3 s3://ml-artifacts/ckpt/run0142/best_model_1.0_1.pt
  • s3 s3://ml-artifacts/logs/run0142/stdout.txt
  • dbrow runs(id=0142, status='completed', val_loss=0.418)
  • dbrow metrics(run=0142, step=12000, val_loss=0.418)
  • folder outputs/2026-05-30/metrics.csv
One namespace

NoKV gives that state one address

/agents/research/wb/run-0142
├── input/config.yaml
├── metadata/run.json
├── logs/stdout.txt
├── logs/stderr.txt
└── outputs/best_model_1.0_1.pt
Alive

indexed, queryable, watchable, snapshot-able

  • ArtifactPublished run-0143 / outputs/best_model_1.1_0.pt
  • ArtifactPublished run-0143 / metadata/run.json
  • SnapshotMinted run-0142 (snapshot_id: 7)

What NoKV is

A path-shaped Workbench for agents. A metadata control plane underneath.

Agents use the native CLI, direct SDKs, or an optional MCP sidecar — not a mount. Each Workbench gives inputs, scripts, outputs, logs, and metadata stable path-shaped identities. NoKV owns atomic publication, versions, snapshots, commits, restore, references, and GC; the configured object provider owns the physical durability of artifact bytes.

native CLI Python SDK Rust SDK optional MCP NoKV Workbench namespace paths, versions, snapshots, commits (root-routed, shard-local) S3-compatible object store immutable revision-owned blocks (provider owns byte durability)

Place each root. Fence each shard owner.

NoKV persists each root's logical-shard placement and routes it to one epoch-fenced owner. Holt remains the serving local adapter inside each shard, not the product API.

Persisted placement
Each RootId maps to one logical shard
Fenced ownership
One epoch-fenced active owner serves each shard
Checked publication
One bounded metadata transaction per shard
Explore Holt
Root-sharded metadata plane Shard-local workspace publication
CLI / SDK / optional MCP RootId-scoped Workbench requests
NoKV root router persisted placement + owner epoch
RootId 01 → shard 01 Logical shard 01
embedded Holt fenced metadata transaction
RootId 02 → shard 02 Logical shard 02
embedded Holt fenced metadata transaction
RootId 03 → shard 03 Logical shard 03
embedded Holt fenced metadata transaction
revision-owned artifact bodies S3-compatible object storage
Qualification boundary

Placement and owner fencing are current. Guarantees are shard-local; cross-shard transactions, shared metadata durability, and production multi-machine HA or failover are not qualified.

Write-path primitives

Built for how agent work actually writes.

Publication is crash-atomic.

Each shard applies a publication as one durable metadata command. Pin a snapshot when a workflow needs a stable multi-read view.

Snapshots are time travel.

Freeze a committed Workbench at one leased read version and keep reading it while later writes proceed. GC retains every revision the live snapshot protects.

Changes are events, not polls.

Successful publications and lifecycle transitions land as typed, replayable events with cursors.

Quickstart

Build or install the native CLI.

bash 
# Build the native CLI from source and inspect its Workbench schema
cargo build --release -p nokv --bin nokv
./target/release/nokv schema

# Or install the current stable source release from Homebrew
brew install NoKV-Lab/tap/nokv
nokv version --json
nokv schema

Current: root-affine logical shards with one epoch-fenced active owner. Not qualified: shared metadata durability, multi-machine failover, production metadata HA, tenant RBAC, or cross-shard transactions.

Latest from the blog

View all posts
PerspectivesJun 13, 2026

Agents Want Filesystems: Agent-Friendly Interfaces Are a Token-Efficiency Strategy

An archived 2026 interface study compared raw SQL with a seven-verb namespace; it is not the current NoKV Workbench API or release qualification.

Jason (Changhao) Wang
Benchmarks & ComparisonsJun 12, 2026

Holt 0.7.0: a historical metadata-engine design note

A source-pinned look at Holt's path-aware metadata design and its bounded role inside NoKV; this page makes no performance claim.

Eric (Guocheng) Song