A print shop of composable modules
Each module owns one concern behind a strict boundary, usable in-process first and designed to move behind HTTP or gRPC without rewriting business logic. Together they compose into a full agent platform.
Each boundary is usable as an in-process Go API first and designed to move behind a standard service protocol without rewriting the business rule.
Modules set behind explicit ownership boundaries
Module names follow the Jikji printing worldview — each one prepares, authorizes, composes, prints, or distributes knowledge.
Deterministic agent loop — delegation, HITL, Lua hooks, checkpoints, step events.
Adaptive multi-model coordinator — swarm debate, verify-revise, evolved routing.
Session orchestration, queues, flow composition, and collaboration memory.
Tenant/provider/model scheduling, bounded queues, retry with backoff, circuit breakers.
Inference providers across OpenAI/Anthropic/Ollama/GLM-compatible backends, OAuth, context-window aware.
Tool execution, MCP integration, runners, sandbox, and remote tool nodes.
HTTP ingress — OpenAI-compatible API, SSE streaming, signed webhooks, idempotency.
Cognitive memory — fact extraction, dreaming, hybrid recall, compaction.
Knowledge graph and ontology — SPARQL, semantic re-ranking, contradiction detection.
Shared SQLite/PostgreSQL/MySQL records and links for collaboration and durable state.
Tenancy, API-key auth, scopes/RBAC, credential ingress, vault, and OAuth.
Authorization decision plane — allow/deny/ask, policy evaluation, audit.
PII and secret detection, reversible redaction, audit-safe text normalization.
Package and agent marketplace — manifests, signing, install, reconciliation.
Deterministic scheduling — cron, interval, batch, and maintenance work.
Bootstrap, configuration, doctor checks, and orchestration control.
Bring any model, route it your way
The typebackbone speaks to many provider families behind one interface, so you mix models freely and switch without touching your agents.
Many provider families
OpenAI-compatible, Anthropic Messages, Ollama Cloud, GLM / Z.AI, xAI Grok, and OpenAI Codex — plus a built-in echo provider for offline work. Chat, embedding, and rerank categories, and any OpenAI-compatible endpoint you point it at.
OAuth or keys, your choice
Credentials come from env vars, the vault, or OAuth device login (Codex, Grok) with automatic token refresh. An oauth:grok-style key resolves at request time, and inline keys are redacted from config export.
Smart routing
Model aliases, ordered provider candidates with failover, multi-key rotation, and cache-aware sticky routing keep provider selection in configuration. Role-specific model-group routing remains outside the advertised runtime contract until its production dispatch path is fully wired.
Provider-aware runtime
Per-provider context-window awareness drives the model-promotion ladder, provider-native prompt caching is used where available, and external usage limits are tracked per provider.
Mix providers and alias them — OAuth, keys, and your own endpoint side by side:
typebackbone: default_provider: ollama-cloud model_aliases: { fast: deepseek-v4-flash:cloud, smart: glm-5.2 } providers: - { name: ollama-cloud, kind: ollama-cloud, model: deepseek-v4-flash:cloud } - { name: zai, kind: zai, model: glm-5.2 } - { name: grok, kind: grok-oauth, model: grok-4.3, api_key: oauth:grok } - { name: openai, kind: openai-compatible, base_url: https://api.openai.com/v1, api_key_env: OPENAI_API_KEY }
Scale-free — laptop to data center, local to remote, one to many
Deployment shape changes by configuration — across scale, location, and instance count. Start the qualified runtime in one process, split planes into services, push tool execution onto remote nodes, then run many instances behind a shared database — all without changing your agents.
One process, local-first
A compact deployment embeds SQLite for durable state. The base Linux runtime boots from one config file on a laptop or edge box; distributed profiles add only the services their topology requires.
Split into services
Run press ingress, the dispatch controller, and tool nodes as separate processes. gRPC connects the controller to remote tool nodes (with optional TLS), while the dispatch controller coordinates workers through the shared database. Tool execution moves to jikji-tool-node workers behind a jikji-relay tunnel.
Multi-node cluster
Point galley at shared PostgreSQL or MySQL for multi-node HA, coordinate dispatch through the shared database with distributed leases, per-node circuit breakers, and failover, and export traces and metrics to your stack.
Multi-node HA is a configuration change, not a rewrite — connect qualified service artifacts to a shared database:
runtime: mode: production ha: enabled: true # durable controller leases elect one leader galley: backend: postgresql # sqlite · postgresql · mysql (shared DB for HA) dsn_env: GALLEY_POSTGRES_DSN typebackbone: model_aliases: balanced: glm-5.2 default_provider: ollama-cloud
- Scale-free — laptop to data center.
- Location-free — local execution out to remote nodes.
- Network-free — a TLS relay tunnel reaches nodes across networks, behind NAT or a firewall, on-prem or in any cloud — so environments that couldn't otherwise see each other join one fabric.
- Six CGO-disabled build targets — The release gate cross-compiles Linux, macOS, and Windows artifacts for amd64 and arm64 with CGO disabled. Linux amd64 is native release-qualified; the other five targets are compile-validated only and require operator testing. Linux sandbox controls do not transfer, and BSD is not a supported build or test target.
- Instance-free — one process or many behind a shared database, with HA leader election.
The same release family and agent contracts span the matrix; configuration and target-host qualification determine the available capabilities.
Galley-first state, five binaries
galley is the shared collaboration workspace — a single schema, with explicit migrations, that backs memory, dispatch records, the marketplace, A2A tasks, credentials, and audit logs. It runs on embedded SQLite by default and on PostgreSQL or MySQL for multi-node deployments, with dialect-aware DDL and a distributed lease manager for task recovery.
| jikji | The main runtime server — agent loop, OpenAI-compatible API, dispatch, channels, and the dashboard, selected by profile. |
|---|---|
| jikjictl | The operator CLI — health, models, credentials and vault, RBAC, policy, filters, provider OAuth, usage, audit, and marketplace. |
| jikjicode | A standalone coding CLI that drives local sandboxed tools against a remote OpenAI-compatible model server. |
| jikji-relay | A TLS tunneling proxy (TLS 1.3) that connects a controller to remote tool nodes across networks. |
| jikji-tool-node | A remote tool executor that registers with the controller, runs tools through governed runners, and heartbeats its health. OS-level isolation follows the target-host support matrix. |
Open protocol surfaces
Jikji is built to fit into what you already run — point existing OpenAI clients at it, bridge MCP tools both ways, or federate agents over A2A.
/v1/chat/completions, /v1/models, /v1/embeddings, plus native agent runs and sessions.
Model Context Protocol server and client over stdio — consume MCP tools or expose Jikji as one.
Agent Communication Protocol over stdio for local process-based agent peers.
Agent-to-agent task dispatch and registry over gRPC, plus a gRPC channel to remote tool nodes. Multi-node work is coordinated through the shared galley database with distributed leases.
| Chat & models | POST /v1/chat/completions · GET /v1/models · POST /v1/embeddings |
|---|---|
| Agent runs | POST /v1/runs · GET /v1/sessions/{id} |
| Health & ops | GET /health · /healthz · /readyz · /metrics · /openapi.json |
| Admin | GET /v1/admin/config · POST /v1/admin/config/reload (operator-scoped) |
Many sessions, frugal footprint
A compiled Go core avoids a per-session language runtime, while bounded queues, caches, and in-process composition reduce coordination overhead. Measure the exact release with your models, tools, and concurrency profile: provider latency and workload shape dominate end-to-end performance.
Concurrency without weight
Go goroutines multiplex bounded concurrent sessions without a per-session interpreter. In-process composition keeps local coordination on function-call boundaries; remote planes remain explicit network hops.
Fast by construction
Cache-aware sticky routing, provider-native prompt caching, and a semantic response cache cut redundant model calls; circuit breakers and bounded queues keep a slow upstream from dragging everything down.
Frugal footprint
CGO-disabled release artifacts, embedded SQLite, and bounded caches keep the base deployment compact. Capacity and host behavior must still be qualified from real context sizes, enabled modules, provider concurrency, and the target operating system.