Rust Runtime + Workspacefor Agent Systems
CALIBER is more than memory storage: a nine-crate Rust core, policy-gated mutation pipeline, event DAG forensics, and a workspace that runs BUILD, LIVE, and LAUNCH flows. Self-host the core runtime, or use caliber.run for managed builder and deployment ops.
Agent platforms still split build, runtime, and ops
Memory is only one layer. Real systems also need config compilation, policy gates, live validation loops, and deployment controls in one coherent flow.
Fragmented Tooling
Teams still stitch together config files, runtime controls, and deployment dashboards across multiple systems. Build, test, and launch drift apart fast.
Weak Traceability
Without a causal event graph and gate analytics, it is hard to answer what changed, why a mutation was rejected, or which deployment introduced drift.
No Mode-based Workflow
Most stacks skip an explicit BUILD -> LIVE -> LAUNCH lifecycle, so teams cannot reliably move from configuration to live testing to operations.
The platform surface that exists in this repo
Open-source core for runtime + APIs, plus workspace flows that map directly to implemented BUILD, LIVE, and LAUNCH concepts.
Rust Runtime + Entity Model
The OSS core models state as Tenant -> Trajectory -> Scope -> Turn, with Artifacts and Notes as durable outputs. The API and SDK expose this model directly.
- Nine Rust workspace crates + typed SDK managers
- Trajectories, scopes, turns, artifacts, notes
- Scope lifecycle with durable extraction surfaces
Mutation Pipeline + Gate Analytics
Writes run through Assemble -> Gates -> Commit -> Receipt. Gate definitions and stats are queryable, so policy behavior is inspectable, not implicit.
- Pure gate stage with deterministic checks
- Atomic commit + receipt generation
- Tenant-scoped gate stats and rejection analytics
BUILD Workspace
The workspace shell combines Pack Editor, Equipment Bay, Agent Wizard, and Intent Engineering into one composition flow backed by the same SDK/API contracts.
- Config parsing + capability-based component install
- Preset loadouts and exportable agent configs
- Deploy modal with compile, diff, activate, confirm phases
LIVE and LAUNCH Modes
BuilderJourney drives BUILD -> LIVE -> LAUNCH transitions. LIVE focuses on chat + sandbox verification; LAUNCH handles promotion and ops controls.
- ModeBar with journey sub-states
- LiveShell with chat + sandbox artifact panes
- Launchpad + ops dashboard with redeploy and rollback controls
Forensics + Deployment Surfaces
The TypeScript SDK exports 34 managers covering event DAG, deployments, gates, intents, multi-agent lock/delegation/handoff, execution environments, and a SimpleMemory zero-config entry point. The workspace UI calls those same primitives directly.
- Event DAG ancestors, descendants, siblings, LCA
- A2A protocol: agent card, task lifecycle, SSE streaming
- SimpleMemory: one-call add/recall/context with Blake3 receipts
Nine Rust crates. One runtime surface.
Open-source core owns runtime + APIs + SDK contracts. Hosted caliber.run layers managed builder/deploy operations on top of the same primitives.
Memory Hierarchy Flow
How runtime state moves through Trajectory, Scope, Turn, and Artifact
Key Design Decisions
SQL-first, not ORM-first
The API routes compile mutations into explicit pipeline stages and commit through PostgreSQL-backed data services.
Events as DAG, not log
Event DAG traversal endpoints support ancestors, descendants, siblings, and common-ancestor forensics.
Effects, not exceptions
State transitions are explicit in BUILD/LIVE/LAUNCH journeys and in deployment lifecycles (activate, rollout, rollback).
Open-core delivery model
Self-host the Rust/API core, then opt into hosted builder/deployment workflows when you want managed operations.
Runtime + Workspace, not just storage
The same domain model powers Rust services and the workspace UI: Pack Editor and wizard feed
dsl.compile/deploy, LIVE mode consumes WebSocket events, and LAUNCH mode drives
deployments plus gate/intent telemetry.
Workspace flows mapped to real API surfaces
The Pack Editor Experience
Build configuration in one shell, verify in LIVE mode, and promote through LAUNCH controls.
SDK calls used by the app itself
The dashboard and workspace use the same TypeScript SDK managers shown below: DSL, event DAG traversal, deployments, gates, and intent drift.
import { BrowserCalibrClient } from '@caliber-run/sdk';
const sdk = new BrowserCalibrClient({
baseUrl: 'https://api.caliber.run',
tokenProvider: () => localStorage.getItem('auth_token'),
tenantId: () => localStorage.getItem('tenant_id'),
});
const compile = await sdk.dsl.compile(manifest);
if (!compile.success) {
throw new Error(compile.errors.map((e) => e.message).join('\n'));
}
const deployed = await sdk.dsl.deploy({
name: 'workspace-pack',
source: '',
pack: { manifest, markdowns },
activate: true,
notes: 'Deployed from BUILD mode',
});
console.log(deployed.config_id, deployed.version);One codebase, two operating paths
CALIBER is open-source at the core. The hosted service adds managed builder and deployment operations on top of the same runtime and SDK primitives.
Build against the OSS runtime contracts first, then decide whether to self-host end-to-end or use hosted builder/deployment workflows as your operational layer.
Build with the OSS core, launch with the model you need
Everything shown on this page maps to concrete code in the Rust crates, SDK managers, and workspace shell. Use SimpleMemory for a one-call drop-in entry point, self-host the full runtime, or use hosted builder/deploy workflows on caliber.run.