DEV Community

Cover image for Your best AI agent lives in a console you don't own. I moved mine into Git.
张洲诚（Zack.ZHANG）
张洲诚（Zack.ZHANG）

Posted on

Your best AI agent lives in a console you don't own. I moved mine into Git.

#devops #ai #opensource #productivity

Quick show and tell. Last month I realized something uncomfortable about my most-used AI agent: I couldn't take it anywhere.

It's a research agent I'd tuned for weeks — a dozen prompt iterations, two skills, an MCP data source, knowledge files, hand-picked tool permissions. All of that lives as scattered console pages on one cloud platform, under one account. If I switch accounts or platforms, I walk away with screenshots.

We'd never accept this for code (Git), dependencies (lockfiles), or infra (Terraform). So why accept it for agents?

Config scattered across consoles vs one declaration managed in Git

What I tried

OpenAgentPack — open source (Apache-2.0, beta). One agents.yaml declares the whole agent stack; a Terraform-style workflow pushes it to the cloud.

npm install -g @openagentpack/cli   # Node.js 22+

mkdir my-agents && cd my-agents
agents init          # wizard writes a starter agents.yaml
agents validate      # offline check, zero API calls
agents plan          # preview create / update / delete
agents apply -y      # execute in dependency order
Enter fullscreen mode Exit fullscreen mode

Here's a full run:

agents plan to apply, terminal recording

The declaration covers model, instructions, tools, skills, MCP servers, environments, and credential references — secrets stay in .env as ${VAR_NAME}, never in the file. So the YAML commits cleanly to Git.

agents:
  assistant:
    description: "General-purpose coding assistant"
    model: qwen3.7-max
    instructions: |
      You are a coding assistant.
    environment: dev
    tools:
      builtin: [bash, read, glob, grep]
Enter fullscreen mode Exit fullscreen mode

Three things that sold me

1. plan is a real three-way diff. It reconciles your declared config, a local state file (remote IDs + content hashes), and what actually exists remotely. Change one field → one update in the plan. Someone hand-edits the console → flagged as drift.

2. My first mistake got caught offline. validate stopped an indentation slip before a single API call went out. Fail-fast where it's cheap.

3. Acceptance testing is built in. agents playground spins up a local WebUI and runs real sessions from the same declaration. I re-ran my standard research task after migrating and compared outputs against the old setup. Same structure, same rigor. You can also flip --provider (bailian / qoder / ark / claude) and benchmark the same scenario across backends.

Honest caveats

  • It's beta — the schema may change before 1.0. I've only moved test agents so far.
  • Provider parity is explicitly not promised: every capability is labeled native / emulated / unsupported per provider. Read that matrix before you migrate anything real.
  • State is a local file today; team-level state sharing is on you (early-Terraform vibes).

Why I think this matters

"Agents as code" feels like where "infrastructure as code" was a decade ago: obvious in hindsight, awkward to live without once you've tried it. Your prompts, workflows, and judgment deserve a form you actually own.

Repo: github.com/modelstudioai/OpenAgentPack

Trying the Bailian provider? You'll need a DASHSCOPE_API_KEY — free to create on Alibaba Cloud Model Studio.

Curious if anyone else is versioning their agents — what's your setup?

Top comments (0)