Skip to content

Runtime manifests (mas-runtime)

Execution manifests consumed by mas-runtime and mas-ctl. Authoritative JSON Schemas: docs/schemas/runtime/.

Validated by mas-ctl validate (agents, MAS, overlays) and mas-lab validate (experiments, pipelines, lab configs).

Manifest index

Manifest Schema file Reference page
Agent agent.schema.yaml agent.md · plugin-bindings.md · context-assembly.md
MAS mas.schema.yaml mas.md
Overlay overlay.schema.yaml overlay.md
Workflow topology workflow.schema.yaml mas.md — Standalone workflow manifest
Flavour flavour.schema.yaml flavour.md
Infrastructure infra.schema.yaml infra.md
RuntimeEngine runtime-engine.schema.yaml runtime-engine.md
Tool tool.schema.yaml tool.md
ToolBundle tool_bundle.schema.yaml tool.md
PromptBundle prompt_bundle.schema.yaml PromptBundle
Workspace workspace.py + docs user-config.md

API id (controller): agent, mas, overlay, workflow, flavour, tool, tool-bundle, prompt-bundle.

Tool family

Kind Purpose
Tool Single tool definition (parameters, implementation ref)
ToolBundle Bundle of tool entries
PromptBundle Named prompts for context.* {ref: ...} / @lib#key

Agents reference tools by semantic name or tools[].ref to a kind: Tool manifest (tool.md). Infra ToolServerRegistry maps remote endpoints (infra.md). Invocation is ToolContract.call_tool.

PromptBundle

kind: PromptBundle uses prompt_bundle.schema.yaml. It requires metadata.name and spec.entries; each entry requires type (system, few-shot, or intent) and may contain text, items, or tags. The schema does not conditionally require text or items based on type.

ToolBundle

kind: ToolBundle uses tool_bundle.schema.yaml. It requires metadata.name and spec.tools. Each entry requires description; optional fields include module_path, class_name, input_schema, output_schema, idempotent, and timeout_seconds.

Separation rules (config hygiene)

Enforced by mas-lab check-config and flavour separation validators:

These rules define semantic ownership, not a required file layout. Where a field's schema allows it, the same resource can be declared inline, referenced by a filesystem/library path, or selected by a catalog id; these forms resolve to the same kind-specific data without moving the concern to another owner. For example, MAS.spec.agency.agents[] accepts inline Agent documents or refs, Agent.spec.tools[] accepts semantic names, Tool/ToolBundle refs, or inline implementations, and experiment.application accepts a manifest path or a registered app id. They are equivalent in ownership and resolved intent, not interchangeable in syntax; see writing-manifests.md for the forms accepted by each field.

Concern Belongs in
Model id, temperature Agent.spec.models
API base, API keys infra/v1 LLMProxy (via workspace infra_refs or CLI --infra-ref)
Remote tool URL / headers / pagination infra/v1 ToolServerRegistry
Tool advertise contract (description, parameters, protocol hints) kind: Tool or ToolBundle entry; agents bind it through spec.tools[]
Topology, delegation graph MAS.spec.workflow
Protocol / OTel defaults Flavour
Scenario-specific behaviour Overlay

Contracts and plugins

Formal contracts (tool invocation, delegation, governance) are implemented in mas-runtime. In manifests, agent and MAS behavior is declared via:

  • spec.design_pattern — intra-agent Mealy step selection (DesignPatternPlugin via registry); peer delegation (delegate_to_* tool calls) runs through this same contract — there is no separate delegation-transport plugin binding on the agent
  • spec.governance[], spec.observability[], spec.control and spec.context_sources — schema-declared governance, observation, control, and context-source bindings (governance.md, reliability.md)
  • MAS.spec.workflow — topology (entry, nodes, delegates_to, dispatch); standalone kind: Workflow has a separate workflow/v1 schema with edges

There is no spec.plugins[], spec.workflow.type, or spec.workflow.plugin field in the current Agent/MAS schemas. See the topology, workflow, and routing section in mas.md.

Authoring detail: agent.md · mas.md.

Further reading