YAML

Tools and agent classes as data

Agent Swarm rests on one idea of mine, that tools are the platform, and I wanted adding a tool or an agent class to be a declaration with no new code. The tools are YAML documents of four kinds, each with a Rust dispatcher.

Every tool must ship with golden fixtures that pin its behaviour and attack fixtures that try to break it, such as an injection attempt against a shell template, and the build fails for a tool without them. See Tools are the platform.

Shell template

HTTP template

Composition

Peer-agent call

golden fixture

attack fixture

Personas validated at load

Personas are YAML too: each names a tool subset, a policy, a workspace and a container or execution profile, and a schema validates every one at load time. Grants of tools to roles live in one tool-class manifest, and the persona launcher reads it to decide what each seat may call.

AgentOS launches governed seats from the same persona and team definitions. I moved its managed grounding, the standing context each seat receives, out of code into YAML, so policy text changes by edit with no rebuild.

tool subset

policy

workspace

container or execution profile

Schemas that generate dispatch

FAFO Core and Function Forge exposes its control surface as multi-action MCP tools whose schemas are declarative YAML, about five thousand lines. The server's dispatch code is generated from those files at build time. Function Forge registers newly generated functions through the same files, which is how the toolset extends itself; see Tools that build tools, under governance.

YAML is the notation; the schemas, dispatchers, fixtures and generators give it meaning.

I use declarative configuration to make platforms extensible and keep them strict: every declaration is validated, tested or compiled before it takes effect.