AI Agent Platforms for Engineering Teams: Infrastructure Over Hype

The conversation we keep having with engineering leaders goes roughly like this: they evaluated three or four coding agents, picked one, and now want to know why adoption is flat three months in. The model was fine. The platform was an afterthought.

An AI agent platform is the coordination layer that sits between the model API and the developer's actual workflow: tool definitions, file-system access, context routing, session state, cost controls, and the policies that decide what the agent is allowed to do. Get that layer wrong and even a strong model underperforms. Get it right and a mid-tier model often beats the expensive one because the context it receives is clean.

The Model Is Not the Product

Terminal-native agents like Plandex and OpenCode have made this distinction concrete. Both delegate model selection to configuration; the platform is the differentiator. Plandex, for instance, builds a plan graph before touching files, which means it can handle a large refactor without blowing the context window on irrelevant tokens. That is a platform decision, not a model decision.

What this means practically: when your team is evaluating which AI coding agent to use, the comparison criteria should weight the platform layer heavily. How does the agent decide what files to include in context? Does it maintain conversation state across sessions? What is the maximum task scope it can hold without degrading? These questions matter more than the benchmark scorecard.

Deployment Topology Changes Everything

There are three broad deployment patterns we see in the field, and they carry very different operational profiles.

Terminal-native, developer-local. The agent runs on the developer's machine, reads the repo directly, and calls a remote model API. Setup is fast. The blast radius of a bad completion is bounded to that developer's working tree. Cost is pay-per-token with no infrastructure to maintain. The trade-off: you cannot enforce organizational policies on tool use, you cannot audit what context was sent to the model, and onboarding a new developer means re-solving configuration from scratch.

IDE-integrated, cloud-backed. The agent runs inside the editor and may route context through a cloud intermediary. This gets you audit logs and centralized billing, but introduces a new class of latency and a dependency on the vendor's availability.

Self-hosted orchestrator. The team runs an orchestration layer, typically a containerized agent server, that proxies to one or more model backends. This is the pattern we recommend for teams where data residency matters or where the codebase contains information that cannot leave the corporate network. The setup cost is lower than it looks.

Context Routing Is the Hard Part

The single biggest reason coding agents produce bad output is not model quality. It is context pollution. The agent received too many irrelevant files, the wrong version of a function, or a stale schema.

A well-designed AI agent platform treats context as a first-class resource. File retrieval should be semantic and bounded, not "send the whole repo." The agent needs a way to request more context rather than hallucinating it. Long-running tasks need checkpointed state so a context reset does not lose the thread.

The Model Context Protocol has become the dominant standard for wiring external tools into an agent. An MCP server exposes typed tool definitions; the agent calls them during inference; the platform manages the round-trips. Below is a minimal TypeScript bootstrap for a coding agent that exposes two tools: one to read a file and one to run a shell command in a sandboxed directory.

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const tools: Anthropic.Tool[] = [
  {
    name: "read_file",
    description: "Read the contents of a file at the given repo-relative path.",
    input_schema: {
      type: "object" as const,
      properties: {
        path: { type: "string", description: "Repo-relative file path" },
      },
      required: ["path"],
    },
  },
  {
    name: "run_command",
    description:
      "Run a shell command inside the sandboxed project directory. Output capped at 8 KB.",
    input_schema: {
      type: "object" as const,
      properties: {
        command: { type: "string" },
        workdir: { type: "string", description: "Subdirectory within sandbox" },
      },
      required: ["command"],
    },
  },
];

async function runAgentLoop(userPrompt: string) {
  const messages: Anthropic.MessageParam[] = [
    { role: "user", content: userPrompt },
  ];

  while (true) {
    const response = await client.messages.create({
      model: "claude-sonnet-4-6",
      max_tokens: 8192,
      tools,
      messages,
    });

    if (response.stop_reason === "end_turn") break;

    if (response.stop_reason === "tool_use") {
      const toolResults: Anthropic.ToolResultBlockParam[] = [];
      for (const block of response.content) {
        if (block.type !== "tool_use") continue;
        const result = await dispatchTool(block.name, block.input);
        toolResults.push({
          type: "tool_result",
          tool_use_id: block.id,
          content: result,
        });
      }
      messages.push({ role: "assistant", content: response.content });
      messages.push({ role: "user", content: toolResults });
    }
  }
}

async function dispatchTool(name: string, input: unknown): Promise<string> {
  // Replace with real fs / exec handlers behind your sandbox boundary.
  // This is where path allow-lists, command block-lists, and egress rules live.
  return `[${name} result placeholder]`;
}

The dispatchTool boundary is where platform policy lives. It is not boilerplate.

Cost Modeling Before You Commit

AI coding agents burn tokens quietly. A single "refactor this module" prompt against a mid-sized codebase can send 100K+ tokens in context before the model writes a line. At current API pricing tiers that is manageable for one developer; it scales non-linearly across a team.

We track three numbers per deployment:

1. Median tokens per coding session. Establish this in week one. Anything above 200K per session suggests the context routing strategy needs work.
2. Cache hit rate. If your platform supports prompt caching, a high repeat-context scenario like monorepo work can cut costs 60 to 80 percent. Measure it; do not assume it is working.
3. Agent-initiated versus user-initiated requests. Multi-agent loops where the orchestrator spawns sub-agents are the fastest path to a surprise billing event. Put a hard token cap at the orchestration layer, not just at the API client.

Open Source vs Commercial Platform

The open-source ecosystem has been shipping terminal-native coding agents at a steady pace. OpenCode, Plandex, and similar projects give you full control over the tool surface and no per-seat fee. The cost is operational: you own upgrades, model-version pinning, and the security review when a new version ships.

Commercial platforms offload that maintenance but introduce vendor lock-in on the orchestration layer. We have seen teams migrate off a commercial platform after a pricing change and discover that all their prompt engineering was against proprietary APIs, not portable ones.

The pattern we recommend: use an open-source agent as the developer-facing layer, back it with your own MCP server for organizational tools (internal APIs, your ticketing system, your SIEM if you are doing detection work), and keep the model provider switchable. That gives you the maintenance control of open source without rebuilding the agent UX every time a better model drops.

Governance Before You Scale

Before rolling an AI agent platform out beyond a pilot group, two controls need to be in place: an audit log of what context was sent to external model APIs, and a policy that gates agent access to production credentials. The second one is frequently skipped. An agent that can read your repo can often read your .env file.

For teams on Azure, Entra ID conditional access policies applied to the service principal the agent runs as are the right gate. On AWS, an IAM role with a tight permission boundary and no console access. Either way: the agent gets a scoped identity, and that identity cannot escalate. Wire this before week two of the pilot, not after you discover the agent has been reading your secrets store for a month.

The agents that cut maintenance costs in practice are the ones running inside a defined boundary, with clean context, and observable billing. The ones that create maintenance costs are the ones that were evaluated on demo repos and shipped to production with the same configuration.

When to Call Us

If you are scoping an AI agent platform deployment and want a second opinion on topology, cost modeling, or the governance layer, reach out.