Your Agent Stack Is a Config File

Deploying an agent today looks a lot like deploying a server in 2012. You SSH into a machine, install dependencies by hand, write a startup script, cross your fingers, and call it production. If two agents need to talk, you write a connector. If three need to coordinate, you write an orchestrator. If you want to move your stack from one provider to another, you rewrite half your code.

We are doing to agents exactly what we did to servers before Docker-Compose came along. Every deployment is a bespoke snowflake. Every team reinvents the same patterns. The duct tape holds, but barely, and nobody would call it reproducible.

The agent stack is about to go through the same transformation servers went through a decade ago. The move from imperative scripts to declarative config. From "run these steps in order" to "here is everything I need, make it work." And the first signs are already here.

What Docker-Compose Did to Servers

Before Docker-Compose, deploying a multi-service application meant writing a deployment script. If you were organized, you had a bash script. If you were disorganized, you had a text file called `STEPS_TO_DEPLOY.txt` that you updated whenever something broke. Every environment was slightly different. Every deploy was a prayer.

Docker-Compose changed that. One file. `docker-compose.yml`. You described every service, its image, its ports, its volumes, its environment variables, its dependencies on other services. The file was declarative, meaning you told the system what you wanted, not how to make it happen. Any developer on the team could read that file and understand the entire stack. Any machine could run that file and produce the same result. Reproducibility was no longer aspirational - it was a side effect of the format.

The shift was not just about convenience. It changed what was possible. Suddenly you could version-control your infrastructure. Code review a deployment. Spin up a full environment on a laptop, then push the same file to production. The abstraction unlocked a whole layer of tooling - health checks, scaling, rollbacks - because the config file was a single source of truth the tools could read.

Agents are about to have their Docker-Compose moment.

Model-Compose Is the First Hint

The project that makes this real is [model-compose](https://github.com/hanyeol/model-compose). Its tagline says it all: "Compose any AI, deploy anywhere." One YAML file. Any model. Any protocol. Any runtime.

Let me show you what that looks like:

controller:
  adapter:
    type: http-server
    port: 8080

workflow:
  job:
    component: chatgpt
    input:
      prompt: ${input.prompt}

component:
  id: chatgpt
  type: http-client
  base_url: https://api.openai.com/v1
  action:
    path: /chat/completions
    method: POST
    headers:
      Authorization: Bearer ${env.OPENAI_API_KEY}
    body:
      model: gpt-4o
      messages:
        - role: user
          content: ${input.prompt}

That is a production-ready API serving GPT-4o. No application code. No framework boilerplate. You run `model-compose up` and it works. Switch the model provider by changing a few lines in the YAML - not by rewriting integration code.

The agent examples go further. Here is a ReAct agent with tools, defined entirely in YAML:

components:
  - id: code-reviewer
    type: agent
    instructions: You are a code review assistant.
    model:
      component: gpt-4o
    tools:
      - read-file
      - list-directory
      - search-code
    max_iteration_count: 15

Seventy-six stars on GitHub, and it already supports agents, RAG pipelines, MCP servers, streaming workflows, multi-modal pipelines, Docker deployment, and horizontal scaling via Redis queues. That is more functionality than Docker-Compose had in its first year.

The pattern is unmistakable. Model-compose separates concerns the same way Docker-Compose did: the *what* (your components and their relationships) lives in the config file, and the *how* (running, scaling, connecting) lives in the runtime. You describe your agent stack. The tool makes it go.

What an Agent Compose File Looks Like

I have been thinking about what the standard agent compose file should look like. Not just for a single agent, but for an entire fleet. Because that is the real prize - not "my one agent can be configured from YAML," but "my 10-agent fleet is a single file I can review in a pull request."

Something like this:

version: "1"
name: "production-fleet"

agents:
  support-agent:
    profile: customer-support
    model: anthropic/claude-sonnet-4
    skills:
      - ticket-classification
      - knowledge-base-search
      - escalation-routing
    memory: support-history
    peers:
      - escalation-agent
    runtime:
      type: fly-machine
      size: shared-cpu-2x
      region: us-east

  escalation-agent:
    profile: senior-engineer
    model: openai/gpt-5
    skills:
      - system-debugging
      - incident-response
    memory: shared-incident-db
    runtime:
      type: fly-machine
      size: performance-4x
      region: us-east

  cron-agent:
    profile: scheduler
    schedule: "*/15 * * * *"
    skills:
      - health-check
      - report-generation
    runtime:
      type: fly-machine
      size: shared-cpu-1x
      region: us-east

secrets:
  OPENAI_API_KEY: ${env.OPENAI_API_KEY}
  ANTHROPIC_API_KEY: ${env.ANTHROPIC_API_KEY}

registry:
  skills: s3://my-bucket/skills/
  profiles: s3://my-bucket/profiles/

I made that up. Nobody ships this yet. But it is clearly where we are heading. Every piece is already being built independently - profiles, skill registries, persistent memory backends, peer-to-peer agent communication, declarative runtime configs. The missing piece is the file format that ties them together.

The file does three things. First, it declares the agents - what they are, what they can do, what model powers them. Second, it declares their relationships - who talks to whom, what data they share. Third, it declares the infrastructure - where they run, how they scale, what secrets they need.

That third part is the one everyone forgets. Agent frameworks are great at describing agent logic. They are terrible at describing agent operations. How much memory does this agent need? What region should it run in? What happens when it crashes? The compose file answers those questions too.

Our Pod Architecture Is Already Heading This Way

I run about a dozen Hermes pods on Fly.io. Each one is configured through a `fly.toml` file that declares the app name, the Dockerfile to build, the ports to expose, the VM size, the region, the volume mount. The agent itself is configured through its profile - a set of skills, a model provider, a set of secrets from Fly's encrypted store.

The pattern is already partially declarative. I just have two files where the future will have one. My `fly.toml` describes the infrastructure:

app = "my-agent"
primary_region = "iad"

[build]
  dockerfile = "Dockerfile"

[[services]]
  protocol = "tcp"
  internal_port = 8080
  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]

[[vm]]
  size = "shared-cpu-4x"
  memory = "8gb"

And my Hermes profile defines the agent behavior - skills, memory, tools, model. The two are separate concerns that should be one file. When I update the agent, I update the profile. When I update the infrastructure, I update the Fly config. They are the same thing, really. A change to the agent that adds a new skill might need more memory. A change to the infrastructure that moves regions might need a new peer configuration. The coupling between agent and infrastructure is real, and splitting them across two config files is an artifact of tooling immaturity, not design.

The pod architecture already proves the concept works. Each pod is self-contained. It carries its own identity, its own skills, its own secrets. It can be deployed, destroyed, and replaced without affecting the rest of the fleet. That is exactly the property a declarative config file needs - idempotent deployment. The missing layer is the file format that describes the whole fleet in one place.

The Team That Standardizes This Wins the Next Five Years

I have been building agents long enough to recognize an inflection point. The field is still so early that there is no standard way to describe what an agent is, what it needs, or how it connects to other agents. Every framework has its own answer. LangChain has YAML configs for chains. CrewAI has config files for crews. Model-compose has a unified format for components and workflows. Hermes has profiles and skills. None of them talk to each other.

This is exactly where servers were in 2012. Docker did not invent containers. It standardized the interface. And that standardization is what made everything else possible - Compose, Swarm, Kubernetes, the entire cloud-native ecosystem.

The team that defines the agent compose file - the common format that any agent runtime can read - will have the same impact. They do not have to build the best agent runtime. They just have to build the best interface between the developer and the runtime. That is what Docker did. That is what Docker-Compose did. That is what the `docker-compose.yml` file did for an entire industry.

The opportunity is sitting right in front of us. The building blocks are already here - profiles, skills, memory, peers, secrets, runtime configs. What is missing is the file that ties them together. The file that says "this is my agent fleet" and lets the computer make it real.

I do not know who will build it. But I know it is coming. And I know the team that gets there first will define how we build agent systems for the next five years.

Your agent stack is a config file. Start designing the format.