The AI Engineering Platform

The organizations operating agents at scale did not roll out tools. They built platforms, and the platform is where their published numbers come from. This section describes what those platforms contain, with the caveat that the evidence quality varies enormously by layer—identity and tool exposure are well evidenced, evaluation infrastructure and fleet observability are nearly evidence-free, and this section says so at each layer.

Baseline context: 28 percent of organizations have a dedicated platform engineering team, 41 percent manage platform capabilities through multi-team collaboration, and 35 percent run hybrid platforms extending an existing developer platform with AI tooling rather than standing up a separate stack.¹⁹⁷ Hybrid extension, not greenfield, is the dominant model. For scale context, analyst work in April 2026 put deployment at 17 percent of organizations with more than 60 percent expecting to deploy within two years, and named agent development platforms, agent management platforms, agentic governance and security, FinOps for agentic AI, context graphs, and agent experience as the emerging capability categories.¹⁹⁸

8.1 The Context Substrate #

This is the layer with the largest measured effect and the least attention.

The published enterprise implementations are specific. One organization operates a context graph of roughly 40 million entries across about 150 node and edge types, explicitly built to reduce tokens, turns, and latency for agents, alongside a skills registry of roughly 2,500 managed skills running more than 20,000 executions daily.¹⁰³ Another pairs its agent platform with its Backstage-based internal developer portal to inject component architecture, dependency graphs, ownership topology, and architectural decisions into agent sessions, with session transcripts and metadata flowing back into the portal—making the service catalog both the context source and the audit surface, across more than 36,000 agent sessions.¹⁹⁵ A third fronts its wiki, product management system, data warehouse, CRM and workspace with internal tool-protocol servers that preserve existing user permissions, so agents retrieve only what the invoking human can already see.²⁰⁴

The research evidence is genuinely good and it points away from documents and toward indexes. Interactive agents never accessed the relevant files on 27 to 35 percent of samples across 427 cases in 25 repositories, and the median relevant evidence occupies only 4.7 percent of the file containing it.²⁰³ Exploration quality correlates with downstream repair outcomes, with file-level localization largely solved and line-level coverage and ranking efficiency the differentiating axes.¹¹⁵ Read alongside Section 5.2’s null results on instruction files, the synthesis is clear: semantic indexing plus catalog and graph context is where the measurable wins are; hand-written context markdown is an efficiency lever, not a success-rate lever.

8.2 Agent Runtime and Sandboxing #

The most significant vendor-neutral development is a Kubernetes custom resource and controller for isolated, stateful, singleton agent workloads, defining a sandbox, a template, a claim, and a warm pool of pre-provisioned sandboxes to cut allocation latency, with isolation delegated to gVisor, Kata Containers, or Firecracker microVMs.¹⁹¹ It is pre-1.0—real, governed, and early.

The most detailed published isolation guidance defines a ladder from a sandboxed shell tool, through a whole-process sandbox runtime, dev containers, custom containers, virtual machines, and hosted environments.¹⁹² Three operationally load-bearing details from it belong in any platform design.

• A per-command shell sandbox does not cover tool-protocol servers or hooks, which run unconstrained on the host. Unattended runs require a whole-process boundary.
• The runtime denies writes to git hooks, git config, tool-protocol manifests, agent command and subagent definitions, and shell startup files by default—because a sandboxed session that can write those can persist configuration that runs unsandboxed next launch. This is Section 2.2’s configuration-as-execution-surface finding arriving from the runtime side.
• On at least one platform the deny list is built once at launch and does not cover repositories created mid-session, which is a real gap for agents that clone.

The published operational benefit is one number and it is worth citing: sandboxing reduced permission prompts by 84 percent in internal usage.¹⁹² Sandboxing is not only a security control; it is what makes unattended operation tolerable.

Two enterprise patterns are documented. Pre-provisioned pods with pre-indexed code so agent environments start in seconds.¹⁰³ And a git worktree per agent session, letting dozens of agents work concurrently on the same codebase without interference—lighter than VM isolation and suited to trusted first-party code.¹⁰⁰

8.3 Tool and Capability Exposure #

This is the best-evidenced layer, with converging independent implementations.

The transferable idea is auto-generation rather than curation: tool definitions generated automatically from existing interface definition language—protobuf and Thrift—across more than 10,000 internal services, eliminating manual registration, behind a single governed gateway exposing more than a thousand tools that enforces authorization, redaction, and continuous scanning on every call, and maintains a hard tiered-trust distinction between internal and third-party servers.¹⁰³ The reported effect of response shaping at that gateway is a greater than 40 percent reduction in token usage across the agent fleet—a larger and more reliable lever than model routing, and one almost nobody discusses.

An open-source reference architecture exists and is implementable: a reverse proxy fronting a registry API with vector and lexical hybrid discovery, scope-based access control enforced at both discovery time and invocation time so different users see different asset sets, scanning at registration, audit logging of who called which tool with which parameters, and federation with external registries.¹⁹⁴ Elsewhere, an internal developer portal exposes its catalog, scorecards, and scaffolder as registered actions through a single endpoint, with an OAuth flow removing hardcoded secrets—the concrete answer to what an IDP should expose to agents.¹⁹⁵

The community protocol registry remains in preview with its API frozen, so do not build a dependency on it being generally available.²⁰⁶

8.4 Agent Identity at Platform Scale #

There is a converged, standards-based answer here, and one production implementation with published latency.

The implementation combines an agent registry as the source of truth for agent-to-workload association, a mesh in which agents carry signed tokens, a security token service issuing short-lived, audience-scoped, single-hop tokens for every hop with the actor chain embedded, based on OAuth 2.0 token exchange; a tool gateway as the policy enforcement point, and workload identity documents fetched via SPIFFE/SPIRE before tokens are requested. Reported: token exchange at P99 below 40 milliseconds, in use by thousands of internal agents.¹⁹³

The scale of the underlying problem is documented: non-human identities outnumber human users at ratios between 45:1 and 144:1, only 15 percent of organizations feel confident preventing non-human-identity attacks, 51 percent report no clear ownership of AI identities, 47 percent of such identities are unchanged for over a year, one in twenty carries full administrative privilege, and only 20 percent have a formal key-offboarding process.¹¹⁶ Those figures are aggregated from third-party industry reports rather than a single fielded survey and should be attributed accordingly. Platform-native agent identity is arriving commercially—one major identity provider now offers agent identities with blueprint templates carrying parent-child relationships, lifecycle management, and cross-platform federation—though its documentation states no formal general-availability date and extending existing security features to agents requires an additional license.²⁰⁵

8.5 Evaluation Infrastructure #

Flag this plainly: almost everything published about enterprise evaluation infrastructure is vendor marketing. One substantive enterprise build exists in the public record.

That build is instructive because its golden set is generated continuously from production outcomes rather than hand-curated: an automated acceptance-rate pipeline comparing every agent suggestion against the merged codebase, measured across 5,230 sampled review comments on 1,727 pull requests with 90.1 percent evaluated at high confidence. Overall suggestion acceptance 63.9 percent, decomposed by category—logic errors 80 percent, bug fixes 58.1 percent, refactoring 43.5 percent, security fixes 40.6 percent. Architecturally it runs multiple independent reviewer agents on different models, treats cross-model convergence as strong evidence, and routes unique findings to separate verification.²⁰²

Two design ideas there are worth more than the numbers: derive the golden set from production merge outcomes so it never goes stale, and use cross-model agreement as a confidence signal rather than trusting a single judge.

8.6 Cost, Quota, and Capacity #

Spend is well documented; control is not.

Total per-developer cost for teams mixing inline and agentic tools runs $200 to $600 per month including tokens, against seat list prices of roughly $19 to $60—a four- to ten-fold multiple on the procurement line item—with governance infrastructure a further $50,000 to $250,000 annually.⁴⁰ One organization’s AI-related costs rose sixfold since 2024, and it now caps every employee at $1,500 in monthly token spend per AI coding tool; at two tools that is roughly $36,000 per engineer per year.^102,196 Across a five-hundred-organization panel, median annual AI spend rose from about $1,500 to $44,000.¹⁰⁴

Documented control mechanisms are simple and effective: a central gateway through which all model calls route, with a sub-100-millisecond governance latency budget at roughly 100 million requests a day; per-person daily spend alerts; and a commercial quota system built on request multipliers by model with monthly allowances and metered overage.^103,204,200

8.7 Observability #

The transport is settling and the semantics are not. All generative-AI semantic convention attributes, spans, metrics, and events carry development status with none stable; the conventions were extracted into a dedicated repository in June 2026 and that repository has no tagged release.⁹⁰ Any organization standardizing agent telemetry today is building on a moving spec and should expect to re-instrument. Emit it anyway, and treat attribute names as a versioned contract with your own pipeline.

Published examples of what platform teams actually instrument are fragments: latency, suggestion acceptance rate, completion rate, and provider failures—the last having no analogue in conventional monitoring;²⁰² a governance-latency budget on the model gateway;¹⁰³ and session transcripts flowing back into the service catalog after each agent session, which is architecturally distinct from span-based tracing and gives org-wide visibility into what agents did and for whom.¹⁹⁵

8.8 Who Builds It #

Org design here is essentially unevidenced, and the two real data points are worth knowing precisely because they are so far apart from the speculation.

One organization runs its model gateway and associated AI platform with approximately six engineers against an engineering organization of thousands.²⁰⁴ Another names a platform surface spanning model infrastructure, tool gateway, model gateway, agent builder, agent studio, background agents, automated review, and test generation—and has not published the headcount running it.¹⁰²

The most useful org-design model available is reasoned rather than measured: stream-aligned teams own dynamic context, business intent, and domain guardrails; the platform team owns systemic context, organizational guardrails, and tooling as self-service; enabling teams are explicitly temporary and their shrinkage is the success signal; and a guardrail appearing in three teams graduates from local to platform capability. It sets a viability threshold of three to five parallel application teams before a shared agent platform pays for itself.²¹²

8.9 Controls #

8.10 Evidence to Request #

• An adversarial retrieval test showing the substrate refuses content the invoking human cannot see.
• A demonstration that an agent cannot write to git hooks, tool manifests, or shell startup files.
• A delegation chain trace across an agent-to-agent boundary, reconstructed after the fact.
• Cost per accepted change, attributed to a team.
• The generated-to-analyzed ratio for agent telemetry.
• The platform team’s headcount against the engineering organization, and what it has graduated from local guardrail to platform capability in the last two quarters.

8.11 Failure Modes #

• Buying tools instead of building substrate. The published outcome differences between organizations are platform differences, not tool differences.
• Point integrations instead of a gateway. Every tool-protocol server stood up by a team to make an agent useful is an ungoverned credentialed path into the estate.
• Sandboxing the shell and not the process. Tool servers and hooks run outside the per-command boundary, which is exactly where persistence is established.
• Retrieval scoped by prompt. “Only look at what the user can see” is an instruction. Entitlement enforcement belongs at the data layer.
• Evaluation infrastructure owned per team. Metric definitions diverge, results are not comparable, and nothing trends.
• Cost visible only at the account level. It cannot detect a looping agent, support a chargeback conversation, or inform a tier decision.