Harness
How the nenjo repo is organized: SDK, manifests, crates, worker runtime, and worker config.
Harness
The Harness section covers the nenjo repo: the Rust SDK, manifest model, crate layout, worker runtime, and local worker configuration.
Nenjo uses the same runtime concepts in two ways. You can embed the SDK directly in Rust code, or you can run the worker with nenjo run so the platform can route chat, tasks, schedules, repository sync, and manifest updates to a local machine.
Repo Shape
| Area | What it owns |
|---|---|
| SDK | Provider construction, manifest loading, agent runners, routine runners, prompt context, memory, knowledge packs, and turn loop events |
| Manifests | Typed resource definitions for agents, models, routines, projects, councils, domains, MCP servers, abilities, and context blocks |
| Crates | Separate packages for tool contracts, knowledge, models, events, event bus, encrypted envelopes, platform contracts, harness runtime, worker, and CLI |
| Worker | The long-running harness behind nenjo run that connects local execution to the platform |
| Worker config | The .nenjo directory, API key, model keys, tool settings, reliability, capabilities, and local state paths |
Runtime Relationship
Dashboard and API
-> encrypted platform commands
-> worker transport
-> Harness
-> Provider
-> AgentRunner or RoutineRunner
-> models, tools, memory, project filesThe platform stores and edits the resources. The worker fetches those resources into a local manifest cache, builds a Provider, then uses the SDK to execute the requested work.
What to Read
| Page | Start here when you want to understand |
|---|---|
| SDK API | How application code builds providers, agents, routines, and streaming handles |
| Manifests | What resource data the worker receives and how it is cached locally |
| Crates | Why the repo is split into multiple crates and what each crate owns |
| Worker | What nenjo run does after startup and which command families it handles |
| Worker Config | Which local files, environment variables, and config sections affect the worker |
The short version: manifests describe the world, Provider turns that world into executable runners, and the worker keeps that runtime connected to the platform.