Build
Assemble governed agents from typed SOIT capabilities.
Build is the authoring layer for SOIT. It is where teams assemble agents, workflows, knowledge bases, model bindings, plugins, MCP tools, and secrets into versioned capabilities that can be executed safely.
What Build covers
- Agent definitions and immutable agent versions.
- Workflow graphs with typed nodes and release pointers.
- Knowledge bases and indexed documents for retrieval.
- Model provider configuration and model routing choices.
- Plugin packages that export tools, MCP servers, skills, or workflow nodes.
- Capability bindings that record the exact resource and version an agent or workflow can use.
Typed bindings: one shape for every capability
The central Build idea is the typed binding. Whether a capability comes from a built-in tool, an installed plugin, an MCP server, a model provider, a knowledge base, or another workflow, it enters an agent the same way: a binding carrying the capability id, source kind, and version. This is what makes SOIT capability-source-agnostic — an agent's definition does not care whether a tool is built-in or plugin-provided, and governance policy applies uniformly at the binding level.
The authoring lifecycle
- Draft — create or edit an agent or workflow; each save produces a new immutable version and advances the head pointer.
- Preview — run a draft explicitly for testing; preview never leaks into production traffic.
- Publish — promote a specific version to live; the release is recorded in an append-only ledger.
- Iterate — new drafts never disturb what is live; rollback moves the live pointer back with full provenance.
See Versioning and Release for the exact semantics.
Where Build lives in the product
| Surface | What you author there |
|---|---|
/agents | Agent workbench: instructions, model, knowledge, tool, and workflow bindings |
/workflow | Workflow DAG design surface with typed nodes |
/knowledge | Knowledge bases, documents, and indexing configuration |
/model | ModelHub provider and model catalog configuration |
/plugin | Plugin install, enablement, and capability inspection |
Design principle
SOIT is spec-first. Important primitives are described by versioned JSON Schemas before they become runtime behavior. That makes definitions portable, reviewable, and enforceable at API and storage boundaries — see Specs and Schemas.