Agent Format: A Declarative Standard for AI Agents

Summary

Snap’s engineering team proposes Agent Format, an open, vendor-neutral specification for defining AI agents declaratively via .agf.yaml files. Inspired by Kubernetes (declare desired state, system reconciles), the spec separates agent definitions from implementations. Built on POMDP decision theory, each schema maps identity, I/O contracts, capabilities (tools/MCP/sub-agents), execution strategy, and governance constraints. Six composable execution policies (react, sequential, parallel, loop, batch, conditional) cover most agent patterns. The killer feature: a “tighten-only invariant” where delegated sub-agents can only have stricter constraints, never relaxed ones.

Why This Was Bookmarked

“some thoughts from the Snapchat engineering team on how to structure agents”

Relevant to how we think about agent architecture in SOUL.md — particularly the layered execution model (skills, loops, dedicated instances, agent teams). Agent Format provides a formal specification for what we’re doing informally.

Key Ideas

• Declare WHAT, not HOW — every field must be settable at authoring time without knowing the runtime
• POMDP foundation: action space, observations, policy, reward/cost model
• Six execution policies: react (think-act-observe), sequential, parallel, loop, batch, conditional
• Tighten-only invariant: constraints can only get stricter when delegating to sub-agents
• Two-layer governance: agent owners declare base constraints, organizations define platform-wide policies — stricter always wins
• Human-in-the-loop as first-class: approval gates declared per-tool with conditions
• Portability via adapters: any runtime implements an adapter to parse .agf.yaml into native types — zero SDK dependency
• Snap’s internal stack: Agent Format (definition) + Auton SDK (runtime) + Agentic Console (debugging)

Connections

Our layered execution model in SOUL.md (skills > loops > dedicated instances > agent teams) maps to their execution policies. We’re doing this informally through CLAUDE.md instructions; Agent Format would formalize it.

The tighten-only constraint pattern is relevant to 06-reference/2026-03-31-block-hierarchy-to-intelligence — as you delegate down the hierarchy, constraints should narrow, not widen.

The governance-by-construction approach connects to 04-tooling/2026-03-29-infrastructure-decisions — we should think about whether our agent constraints are auditable and machine-readable.

Open Questions

• Is .agf.yaml worth adopting as a formal spec for our agent definitions?
• How would we express our current SOUL.md operating model in Agent Format?
• Could the tighten-only invariant help with trust boundaries for the channels agent?