Multi-Agent Coordination Without Vendor Lock-in

Multi-agent coordination is the practice of running multiple autonomous AI agents against a shared codebase or workflow, with each agent handling a distinct function and all of them staying aligned without manual intervention. The challenge doubles when those agents run on different providers: Claude Code, OpenAI Codex, Google Gemini CLI, or whatever ships next quarter. Armada Works runs an eight-agent fleet in production and has designed every coordination mechanism to be provider-agnostic from the start. This post explains the three architectural decisions that make that possible: state in the repository, agent definitions in plain files, and governance at the OS layer.

The Lock-in Problem Most Teams Do Not See Coming

Vendor lock-in for AI agents is subtler than traditional software lock-in. You are not locked in by an API contract or a proprietary data format. You are locked in by where your coordination state lives.

Every major agent provider offers some version of persistent memory, session context, or project knowledge. Claude Code has CLAUDE.md files and conversation history. Codex has its sandbox state. Gemini CLI has its grounding context. These features are convenient. They are also traps.

When your agent's understanding of "what happened last time" lives inside a provider's session model, three things break:

• You cannot switch providers without losing context. An agent that remembers its last ten runs through Claude's session history loses all of that if you move it to Codex. You are not migrating code. You are migrating institutional memory, and there is no export button.
• You cannot run agents from different providers in the same fleet. If Agent A's output is trapped in Provider X's session context and Agent B runs on Provider Y, there is no shared bus. The agents cannot read each other's work.
• You cannot audit coordination history. Provider session state is opaque. You cannot git log it. You cannot diff it. You cannot revert it. When something goes wrong, you are debugging with incomplete information.

The fix is architectural, not operational. You do not solve this by asking your vendor for a better export tool. You solve it by never putting coordination state in the vendor's hands in the first place.

State Belongs in Your Repository, Not a Provider's Session

The core principle: any information an agent needs to carry between runs should live in a plain file committed to the repository the agent works in. Not in a provider's memory system. Not in a database the provider manages. In a markdown file, a YAML file, or a JSON file that you own, version, and can read with cat.

This means:

• Agent state files that record what happened last run, what is in progress, and what questions are open. At Armada Works, every agent writes its own state file (e.g., docs/agents/state/content-agent-state.md). The file is structured markdown: current drafts in flight, recently shipped items, queue snapshot, open questions, and notes for the next session. Any agent from any provider can read it.
• Work queues that track assignments, priorities, and completion. The content queue at docs/agents/state/content-queue.md is a markdown file with sections for Pending, In Progress, and Completed. The CMO agent writes to it. The Content agent reads from it. Neither needs to know what provider the other runs on.
• Decision logs that capture why something was done, not just what. When the SEO agent recommends a keyword shift, it writes the recommendation to its state file with the supporting data. The Content agent reads that recommendation on its next run. The reasoning is in the file, not in a conversation thread that evaporates when the session ends.

The practical benefit is that every agent starts every session by reading files from the repository. It does not matter whether the agent runs on Claude Code, Codex, or a provider that does not exist yet. If the new provider can read a markdown file and write to git, it can join the fleet. For the full technical walkthrough of how state files, cron cadences, and the synthesizer pattern work together, see How the Agent Fleet Actually Coordinates.

Provider-Agnostic Agent Definitions

An agent's behavior is defined by its prompt file. At Armada Works, each agent's prompt lives at a path like docs/agents/content-agent-prompt.md. The file specifies:

• What the agent does (role and responsibilities)
• Which files it reads (state files, queue files, reference documents)
• Which files it writes (output locations, state file, daily briefs)
• Which files it must never touch (other agents' prompts, environment files, source code)
• What voice and formatting rules apply

This is a portable specification. It does not reference Claude-specific features, Codex sandbox capabilities, or Gemini grounding APIs. It describes behavior in terms of files, directories, and git operations that any provider's agent runtime can execute.

The alternative is embedding agent behavior in provider-specific configuration. Claude Code's CLAUDE.md, Codex's project settings, Gemini's system instructions: each has its own format, its own inheritance rules, and its own limitations. If you define your agent's behavior in these provider-specific locations, you are writing the agent's brain in a dialect only one vendor speaks.

A portable prompt file gives you three things:

1. Migration without rewriting. If you move an agent from Claude Code to another provider, you hand the new runtime the same prompt file. The behavior specification transfers because it is written in English and file paths, not in API-specific configuration.
2. Multi-provider fleets. Different agents can run on different providers. Your SEO agent might run on Claude Code (strong at structured analysis) while your Content agent runs on a provider better suited to long-form writing. As long as both read and write to the same repository, they coordinate through shared files.
3. Human readability. Anyone on the team can open the prompt file, read what the agent does, and understand why. No provider dashboard required. No special tooling. A text editor and git blame.

Governance at the OS Layer, Not the Provider Layer

Every agent provider ships its own permission model. Claude Code has hooks and permission prompts. Codex runs in a sandboxed environment. Gemini CLI has tool restrictions. These are useful safety nets, but they are not governance.

Governance means controls that work regardless of which provider runs the agent. The Black Hat 2026 findings proved that every major provider's built-in permission model had exploitable gaps. The agents that survived were the ones with enforcement outside the provider's runtime.

Provider-agnostic governance layers include:

• Git hooks (pre-commit, pre-push). A pre-commit hook that rejects commits containing API keys works whether the committing agent runs on Claude Code, Codex, or a shell script. The hook is a bash script in .git/hooks/. It does not know or care which AI provider generated the commit.
• CI checks. A GitHub Actions workflow that runs linting, type checking, and security scanning on every push applies equally to human commits and agent commits. The agent pushes. CI validates. If the check fails, the push is blocked. No provider-specific configuration required.
• File-system permissions. An agent running as a specific OS user inherits that user's file-system permissions. If the agent's user cannot write to /etc/ or read .env.production, no prompt injection can change that. This is operating-system security, not AI security.
• Network controls. Firewall rules that block outbound connections to unknown hosts prevent credential exfiltration regardless of the attack vector. The Elastic Security Labs finding (a Claude Code process opening a reverse tunnel via Cloudflare) would have been caught by an outbound allowlist at the network layer.

The pattern is consistent: move enforcement from the provider's runtime to infrastructure you control. The provider's built-in permissions are a useful first layer. They should not be your only layer.

Control	Provider-specific	Provider-agnostic
Blocking dangerous commands	Claude Code hooks, Codex sandbox	Pre-commit hooks, CI checks
Credential protection	Provider's env var handling	OS-level permissions, secret managers
Network restrictions	Provider's sandbox rules	Firewall allowlists, egress policies
File access control	Provider's permission prompts	OS file permissions, chroot/containers
Audit trail	Provider's session logs	Git history, CI logs

For a detailed checklist of the governance controls Armada Works configures on every engagement, see How to Audit an AI Agent's Permissions.

What This Looks Like in Practice

Armada Works runs eight agents on Claude Code today. The coordination architecture does not depend on Claude Code.

Every agent reads its prompt from a plain markdown file in the repository. Every agent writes its state to a plain markdown file. Every agent communicates with every other agent through git commits, not through a provider's session context. The CMO synthesizer reads all sub-agent state files and writes a single brief for the founder. The content queue is a markdown file with sections for pending, in progress, and completed items. Governance is enforced through git hooks, CI pipelines, and file-system scoping rules in each agent's prompt.

If Claude Code disappeared tomorrow, the migration path would be:

1. Point the new provider's agent runtime at the same repository.
2. Hand each agent its existing prompt file.
3. Configure cron schedules to match the existing cadences.
4. Verify that git hooks and CI checks still trigger on the new provider's commits.

The state files, queue files, decision logs, and governance infrastructure would not change. The prompts would not change. The coordination model would not change. The only thing that changes is which runtime executes the prompt.

This is not a theoretical benefit. The agent landscape is moving fast. Providers ship breaking changes, discontinue features, and adjust pricing on quarterly cycles. If your fleet's coordination layer is coupled to one provider's runtime, every one of those changes is a fire drill. If your coordination layer is files in a git repository, every one of those changes is a configuration swap.

When Provider-Specific Features Are Worth the Coupling

Not all provider features should be avoided. Some are genuinely useful and worth the coupling cost:

• Model-specific strengths. If Claude is measurably better at structured analysis for your SEO agent and a different model is better at long-form writing for your Content agent, optimizing model selection per agent is reasonable. The key is that the agent's behavior definition (its prompt file) stays portable even if the runtime is provider-specific.
• Provider-specific safety features. Claude Code's hooks, Codex's sandbox, Gemini's tool restrictions are all useful first layers of defense. Use them. Just do not rely on them as your only layer. Stack them under your provider-agnostic controls.
• Performance optimizations. Prompt caching, context window management, and token-efficient features are provider-specific and often worth using. These affect cost and speed, not coordination architecture.

The rule of thumb: use provider-specific features for execution. Use provider-agnostic patterns for coordination. The agent's runtime can be provider-specific. The agent's memory, communication, and governance must not be. If you want help evaluating which patterns fit your team's stack, see What to Look for in an AI Agent Implementation Partner.

Frequently Asked Questions

What is multi-agent coordination in AI?

Multi-agent coordination is the set of patterns and infrastructure that let multiple autonomous AI agents work on the same codebase or workflow without conflicting with each other. It covers how agents share state, hand off work, avoid collisions, and stay aligned toward a common goal. At Armada Works, coordination runs through git commits and shared state files rather than real-time messaging between agents.

Can you run AI agents from different providers in the same fleet?

Yes, if your coordination layer is provider-agnostic. Agents from different providers can share a fleet as long as they all read and write to a common repository using standard tools (git, file I/O). The coordination state (queues, agent state files, decision logs) must live in the repository, not in any provider's session context or memory system.

How do you avoid vendor lock-in with AI coding agents?

Keep three things out of the provider's control: agent state (write it to files in your repository), agent definitions (write prompts as portable markdown files, not in provider-specific configuration), and governance (enforce rules through git hooks, CI checks, and OS-level permissions rather than provider-specific permission models). These patterns let you switch providers or mix providers without losing coordination history.

What is the difference between agent governance and agent permissions?

Permissions are the provider's built-in controls: what the agent is allowed to do within that provider's runtime. Governance is the broader set of technical controls (git hooks, CI pipelines, file-system permissions, network policies) that enforce safety rules regardless of which provider runs the agent. Governance survives prompt injection attacks and provider-specific vulnerabilities. Permissions alone do not.

How does Armada Works handle agent coordination across clients?

Each client engagement gets its own repository with its own set of agent prompt files, state files, and governance infrastructure. Agents run inside the client's codebase, not in a shared SaaS platform. When the engagement ends, the client owns everything: the prompts, the state files, the coordination patterns, and the governance hooks. Nothing lives on Armada's infrastructure. For the full engagement model, see how we engage.

---

If you are running agents in production (or planning to) and want to see how provider-agnostic coordination works on a live system, book a discovery call. We will walk through the real architecture, not a slide deck.