How it fits together

Manykind has two sides and one connection between them. Everything else in these docs is a detail of one of the three.

  DEVELOPER SIDE                          CUSTOMER SIDE
  Agent Service (your account)
  ┌────────────────────────────┐          ┌──────────────────────────────┐
  │ ┌────────────────────────┐ │          │ Vault                        │
  │ │ Agents                 │ │ connect  │                              │
  │ │  workflows             ├─┼─────────►│  scopes ── events, objects   │
  │ │  LLM agents            │ │ (signed, │  Memory Bank                 │
  │ │  code agents           │ │  scoped, │  connectors (Slack, email…)  │
  │ └────────────────────────┘ │ revocable│  members                     │
  │  cubbies  widgets          │          │                              │
  │  datasets members          │          │                              │
  └────────────────────────────┘          └──────────────────────────────┘
               │                                     │
               └──────────── a run ◄─────────────────┘
          event lands in a scope → Job → steps / handlers
          → models, cubbies, Memory Bank, connector actions
          → results back into the vault

The developer side: your agents

An agent is what you build, what a customer connects, and what runs on their data. It comes in three kinds, on the same level: workflows (a typed graph of steps), LLM agents (instructions, a model, tools, and connections), and code agents (TypeScript). A workflow can use an LLM agent or a code agent as a step; LLM agents and code agents are peers.

Your agents live in your Agent Service: your account on Manykind, the way a cloud account is. You create it once in ROC, the Manykind web console, and next to your agents it holds what they share:

Cubby schemas. SQLite databases every agent of the service shares, one copy per vault.
Widgets. UI the service publishes.
Models. Aliases bound to models from the platform’s catalogue, called by workflows and code agents alike.
Datasets for evaluations, and the members who work in the service.

Every agent you publish is identified as <agentServicePubkey>:<alias>: the service’s public key, then the agent’s name.

The customer side: the vault

A vault belongs to a customer: one person, or an organization with members. It holds:

Scopes. Named partitions of the vault. Events and objects live in a scope, and every connection is granted per scope.
Memory Bank. The vault’s durable, privacy-classified record of what its agents and workflows learned.
Connectors. Connections to outside systems (Slack, email, Telegram, MCP servers) whose credentials are sealed in the vault.

The connection

An agent reaches a vault only after the vault owner connects it. Connecting signs an agreement with the owner’s wallet that names the agent service, the vault, and the scopes. The vault checks the agreement, provisions what the agent declares, and pins the exact bundle the owner consented to run. Revoke the agreement and the access ends.

How a run happens

Build. You build a workflow in the ROC Workflow Builder, or write an agent or workflow in code with @cef-ai/agent-sdk.
Ship. You publish it to your Agent Service and deploy a version. See Push and deploy.
Connect. The vault owner connects it to one or more scopes and signs the agreement. See Connect to a vault.
Trigger. An event lands in a connected scope: a person runs the workflow, your app publishes, a schedule fires, a webhook is called, a Slack message arrives through a connector, or another agent publishes.
Run. The platform finds or opens a Job for that agent and stream, and each event becomes a Task in it. A workflow walks its steps; a code agent runs the matching handler in a sandbox. See Runs and events.
Work. The run calls models by alias, reads and writes cubbies, files records into the Memory Bank, and takes connector actions, all under the connection’s grant.
Results. Output lands back in the vault: events in the scope, cubby rows, Memory Bank records. People see it in ROC, in your widgets, or in your own app through the Vault SDK.

Where each part of these docs fits

Everything belongs to one owner, and the docs follow the owners.

Part	Covers	Side
Get started	This map, your Agent Service and its team, installing the CLI and SDKs, and the Quickstart.	Both
Agents	How runs happen and everything your Agent Service runs: workflows (with testing, evaluation, and monitoring), LLM agents, code agents, the building blocks they use, and how to ship them to a vault.	Developer
Vaults	What a customer owns: the vault, its connections, Memory Bank, connectors, and members, and how your own apps build on a vault with the Vault SDK.	Customer
Reference	Every CLI command, SDK export, limit, and error code, and the glossary.	Both

Where the tools fit

Tool	What you do with it
ROC	Create an Agent Service; build and run workflows in the Workflow Builder; try agents against a vault in the Sandbox; browse Agents, Cubbies, Widgets, Connectors, Models, and the Memory Bank; manage Members; run Evaluations.
`cef` CLI (`@cef-ai/cli`)	Scaffold, build, push, and deploy code agents and workflows; register A2A agents you run elsewhere; push service cubbies and widgets; run evaluations. See CLI reference.
Agent SDK (`@cef-ai/agent-sdk`)	Write code agents (`@Engagement`, `@OnEvent`, `ctx`) and workflows in code (`defineWorkflow`). See Agent SDK reference.
Vault SDK (`@cef-ai/vault-sdk`)	Talk to a vault from your own app or server: publish events, upload objects, connect agents, read cubbies and the Memory Bank. See Vault SDK reference.
Widget runtime (`@cef-ai/widget-runtime`)	The browser half of a widget. See Widget runtime reference.
Testing and eval (`@cef-ai/testing`, `@cef-ai/eval`)	Test agents offline; build datasets and experiments for workflows.