Animus/ Blog
runtime ↗animus.team ↗github
← All posts
FIELD NOTES · 8 min read · The Animus Team

Plugin-First Agent Infrastructure: No Provider Lock-In

AI automation is moving too fast to bet your whole engineering workflow on one vendor, one tracker, or one runtime. The teams that win will not be the ones that pick the single “right” coding agent forever. They will be the ones that can route work to Claude Code, Codex CLI, Gemini CLI, OpenCode, GitHub Issues, Linear, or a private system without rebuilding their automation stack every time the tool landscape changes.

That is the bet behind Animus: the orchestrator should be the control plane, not another silo.

Providers, subject backends, queues, workflow runners, transports, config sources, journals, and log storage should be replaceable pieces. The core should own coordination: what work is ready, which workflow runs next, what policy applies, what happened, and where the audit trail lives. Everything integration-specific should be an adapter.

That sounds like architecture plumbing until you need it. Then it becomes the difference between changing configuration and doing a migration.

The agent landscape is already plural

There is no single coding agent standardizing the market right now.

Claude Code is an agentic coding tool that can read a codebase, edit files, run commands, and connect with development tools across terminal, IDE, desktop, and browser surfaces. Its docs also emphasize MCP, CLI automation, and multi-agent patterns.

OpenAI Codex CLI is a local coding agent that “runs locally on your computer,” with installation options through a shell script, npm, Homebrew, and release binaries.

Gemini CLI is an open-source terminal AI agent with file operations, shell commands, web fetching, Google Search grounding, MCP support, checkpointing, headless mode, and GitHub workflow automation for PR reviews and issue triage. It supports multiple auth paths, including Google sign-in, a Gemini API key, and Vertex AI.

OpenCode is an open-source coding agent available as a terminal UI, desktop app, or IDE extension. Its provider docs say it uses AI SDK and Models.dev to support 75+ LLM providers and local models, including configurable custom provider entries.

These are not interchangeable wrappers around the same thing. They differ in auth, runtime, UX, permissions, model access, local execution, transcript shape, and integration surface.

If your orchestrator assumes one provider API, every new provider becomes a re-platforming project. If your orchestrator is plugin-first, each provider is an adapter behind a stable workflow contract.

That means one team can use Claude Code for a codebase-heavy refactor, Codex CLI for local OpenAI-backed development, Gemini CLI for a terminal automation flow, and OpenCode when broad provider choice or local models matter. The workflow engine does not need to become Anthropic-shaped, OpenAI-shaped, Google-shaped, or OpenCode-shaped. It stays Animus-shaped.

The backlog is plural too

Provider lock-in is only half the problem. Work intake is just as fragmented.

GitHub Issues are designed for planning, discussing, and tracking work. GitHub says issues can represent bug reports, features, ideas, and anything a team needs to write down or discuss, with metadata such as labels and milestones. GitHub also exposes issue access through the web UI, GitHub Desktop, GitHub CLI, GraphQL and REST APIs, and mobile. Its REST API includes endpoints to list, create, get, and update issues.

Linear has a developer platform built around its GraphQL API and TypeScript SDK, plus authentication, webhooks, and agent-focused developer topics.

Many teams have both. Some have neither. They have an internal incident queue, a customer-success escalation table, a compliance review system, a database-backed content calendar, or a custom product workflow that will never fit cleanly into GitHub or Linear.

A provider-locked orchestrator usually becomes tracker-locked too. It treats “task” as synonymous with whatever system it integrated first.

Animus should not care whether the subject is a GitHub issue, a Linear ticket, a blog card, a requirement, or a row in a private backend. It should care that the subject has an identity, state, metadata, and enough context for a workflow to run.

That is what a subject backend buys you. “Implement this task” can run against GitHub Issues today, Linear tomorrow, and an internal regulated work queue next quarter. The workflow stays recognizable. The adapter changes.

Transport is not an implementation detail

Modern agent infrastructure also has to speak more than one transport.

MCP describes itself as an open-source standard for connecting AI applications to external systems, including data sources, tools, and workflows. Its introduction compares the value to a standardized connection layer, similar to USB-C.

The current MCP transport specification defines stdio and Streamable HTTP. It also says custom transports can be implemented in a pluggable fashion as long as they preserve the JSON-RPC message format and lifecycle requirements.

That matters because transports carry operational decisions.

A local stdio plugin has different lifecycle and logging constraints than a remote HTTP service. MCP’s transport spec calls out details such as keeping stdout reserved for valid MCP messages, validating Origin headers for Streamable HTTP, binding local servers to localhost, and supporting session IDs and resumability for HTTP transports.

Those are not cosmetic differences. They affect security, observability, retries, process supervision, and incident response.

A plugin-first system can harden or replace a transport without rewriting the workflow runner. It can support local stdio plugins where privacy or developer ergonomics matter, HTTP services where centralization makes sense, and future transports when the ecosystem evolves.

The mature pattern is core plus plugins

Plugin-first infrastructure is not a novelty. It is the pattern that shows up when a platform has to integrate with a world that refuses to stop changing.

Terraform is the cleanest analogy. Terraform Core communicates with executable provider plugins over an RPC interface. The point of that common interface is to let users work across many cloud providers, databases, services, and in-house systems without folding every integration into the core.

Backstage makes a similar platform argument. Its plugin ecosystem is explicitly about flexibility, letting teams incorporate a broad spectrum of infrastructure and software development tools.

MCP makes the same ecosystem argument for AI tooling: open protocol support across clients and servers helps developers build once and integrate across systems.

The lesson is simple: when the integration surface is volatile, the core should stay small, stable, and opinionated about contracts. The edges should be replaceable.

For Animus, that means the core owns orchestration concerns:

  • Queueing and scheduling work
  • Workflow state and phase transitions
  • Policy and approvals
  • Journals, decisions, and audit trails
  • Observability contracts
  • Stable interfaces between subjects, providers, transports, and storage

Plugins own the moving parts:

  • Provider calls to Claude, Codex, Gemini, OpenCode, or custom agents
  • Subject backends for GitHub Issues, Linear, internal systems, or content queues
  • Transports such as stdio, Streamable HTTP, or future MCP-compatible options
  • Config sources for how workflows and agents are defined
  • Journal and log storage integrations that fit a team’s compliance and operations model

That split is what prevents today’s tool choice from becoming tomorrow’s migration tax.

What teams get from plugin-first automation

The practical benefits are concrete.

First, teams can swap providers without rewriting workflows. If Claude Code fits one workflow and Gemini CLI fits another, the orchestrator should route accordingly. If OpenCode’s 75+ provider ecosystem or local model support matters for a specific use case, that should not require a second automation platform.

Second, teams can keep the same workflow over different backlogs. A product task in Linear, a bug in GitHub Issues, and an internal incident can all move through similar phases: triage, research, implementation, review, approval, and closeout. The subject backend translates the work item. The workflow remains stable.

Third, local execution stays on the table. Codex CLI says it runs locally. Gemini CLI is terminal-first and open source. OpenCode supports terminal usage and local models. Some code and data workflows should not be forced through a cloud runner just because the orchestrator was built around one provider’s hosted assumptions.

Fourth, the blast radius is smaller. If a provider changes its API, a Linear webhook shape shifts, or a logging backend has to be replaced for compliance, the adapter changes. The queue, workflow state, journal, and policy logic do not have to be rewritten with it.

Fifth, teams can meet their own observability and compliance requirements. Replaceable journals and log storage let an organization keep transcripts, decisions, and audit trails in systems it already trusts. That matters in the same way transport details matter: infrastructure choices become operational and security choices once agents start taking real actions.

The opposite of lock-in is not chaos

Plugin-first does not mean every workflow becomes a pile of interchangeable parts with no standards. It means the standards live in the right place.

Animus should be strict about contracts: what a provider must accept and return, how a subject backend represents work, how queues are leased, how workflow decisions are recorded, how transports are supervised, and how logs and journals are stored.

But it should be flexible about implementations.

That is the balance teams need. Strong contracts in the core. Replaceable adapters at the edge.

Provider-locked automation asks you to believe one vendor, one tracker, one runtime, and one storage path will keep fitting your team as AI tooling changes. Plugin-first automation assumes the opposite. It assumes change is normal, then gives you a control plane that can absorb it.

That is why Animus refuses to be provider-locked.

Do not build your agent infrastructure around the tool you happen to prefer this quarter. Build it around the workflows, policies, queues, subjects, journals, and audit trails your team needs to keep. Then let providers, trackers, transports, and storage systems compete as plugins.

That is how you get choice without losing control.

Sources