Agent Format: Kubernetes-Style Declarative Definitions for AI Agents

#ai #agents #opensource #llm

If you've built AI agents across multiple teams or projects, you've probably hit this: every framework defines agents differently, and switching frameworks means rewriting everything.

I came across Agent Format — an open, vendor-neutral spec for defining AI agents declaratively. The analogy is Kubernetes: before K8s, infrastructure was imperative scripts. K8s made it declarative. Agent Format does the same for agents.

What's in an `.agf.yaml`?

schema_version: "1.0.0"

metadata:
  id: my_agent
  name: My Agent
  version: "1.0.0"

interface:
  input:
    type: object
    properties:
      query:
        type: string
    required: [query]
  output:
    type: string

action_space:
  mcp_servers:
    - alias: my_tools
      server_ref: http://localhost/mcp/tools
      allowed_tools:
        - search
        - summarize

execution_policy:
  id: agf.react
  config:
    model: gemini-2.5-pro
    instructions: |
      You are a helpful assistant.
    max_steps: 10

constraints:
  budget:
    max_token_usage: 50000

Five sections, five concerns:

Section	What It Captures
`metadata`	Identity, versioning
`interface`	I/O contract
`action_space`	Tools, MCP servers, sub-agents
`execution_policy`	How the agent reasons (ReAct, sequential, etc.)
`constraints`	Budgets, limits, governance

The Adapter Model

Any framework can implement an adapter that reads .agf.yaml and converts it to its native agent type. The parser has zero dependency on any runtime SDK. So your LangChain team, your ADK team, and your custom Python team can all work from the same agent definition.

Governance

This is where it gets interesting for production use:

Tighten-only invariant: Child agents can never exceed parent constraints
Two-layer governance: Agent-level + org-level policies, composed at runtime
Human-in-the-loop: Per-tool, conditional approval gates as first-class concepts