Internal platform engineering — the new agent-platform team.

The coordination gap that no existing function could fill

The coordination gap that produced the agent-platform team can be reconstructed precisely from the procurement timelines that the major enterprise tooling vendors have shared with their investor base. The pattern is consistent across financial services, retail, and enterprise SaaS organisations. The first agent vendor purchase typically happened in 2023 or early 2024, driven by an engineering or business function that wanted access to a specific capability — usually code generation through GitHub Copilot or an early Cursor deployment. The purchase ran through the standard developer tooling procurement process and was sponsored by the engineering function. The second purchase happened later in 2024 and was driven by a different function — typically marketing, customer success, or operations — wanting access to a different capability, usually through OpenAI's enterprise tier or Anthropic's Claude product. The purchase ran through a separate procurement process and was sponsored by the second function. By mid-2025 most of these organisations had accumulated four to seven distinct agent vendor relationships, each sponsored by a different function, each with separate contracts, separate security reviews, separate data residency commitments, and separate integration paths to the organisation's existing infrastructure.

The coordination gap manifested most acutely around three problems. The first was model routing — the question of which specific model should handle a given request, and which vendor should provide that model. The organisations had typically purchased capacity from multiple vendors that overlapped in capability but differed in pricing, latency, and data-handling commitments. The routing decisions were being made ad hoc by individual application teams, which produced both economic inefficiency (paying for capacity at one vendor while underutilising paid-for capacity at another) and compliance variation (different applications making different routing decisions for the same data category). The second problem was eval harness operation — the question of how the organisation measured whether its agent deployments were actually producing the intended business outcomes. The eval work was being done piecemeal by individual application teams with no shared methodology or shared infrastructure, which produced duplicated work and inconsistent measurement quality. The third problem was vendor management at scale — the question of how the organisation negotiated, monitored, and governed relationships with the agent vendors, which by mid-2025 were running into eight-figure annual contract values and required dedicated commercial management.

No existing function was structurally positioned to solve all three problems. The VP Engineering's platform team had the technical capability to handle model routing and eval harness operation but lacked the commercial mandate for vendor management. The Chief Data Officer's MLOps function had vendor management experience but its existing competency was around model training and data pipelines rather than agent runtime concerns. The Chief Information Security Officer's security engineering function had the vendor governance capability but lacked the technical depth on agent runtime. The Chief Procurement Officer had the commercial mandate but did not have the technical staff to evaluate the operational dimensions of agent vendor relationships. The agent-platform team emerged at most of these organisations as the function that absorbed responsibility for all three problems, with a hybrid composition of engineers from the platform team, machine learning operators from the MLOps function, and a commercial-operations leader who liaised with procurement.

The emergence pattern was rarely planned at the executive level. The named companies that have built agent-platform teams describe the function's emergence as bottom-up — a senior engineer or director identifying the coordination problem, building a small team to address it informally, and the team eventually being formalised on the org chart once the executive layer recognised the function as load-bearing. The largest exception to the bottom-up pattern is JPMorgan Chase, whose technology leadership team — under CIO Lori Beer — established the function formally in late 2024 as part of the bank's broader AI strategy review. The JPMorgan team is one of the larger examples — 14 engineers and managers under a Managing Director-level lead reporting to the VP-level Head of AI Platform. The size reflects the bank's particular regulatory and integration complexity rather than a general benchmark for the function. The median agent-platform team across the financial services Fortune 500 is closer to 8 engineers and managers.

The reporting lines and the strategic implications of each

The reporting line into which the agent-platform team is placed shapes the function's strategic posture more substantively than the headcount or the budget authority. The three most common reporting lines — VP Engineering, Chief Data Officer, Chief AI Officer — each produce a different operational tilt that the function's day-to-day priorities reflect. The VP Engineering reporting line is the most common at organisations whose initial agent adoption was concentrated in engineering use cases (code generation, infrastructure automation, developer productivity tooling). The function operates as a specialised platform team under the broader engineering platform organisation, and its priorities are shaped by what the engineering function needs from agent infrastructure. The strategic limitation is that the function's posture toward non-engineering use cases — marketing, customer success, operations — tends to be reactive rather than strategic, because the broader engineering organisation does not have a structural relationship with those functions.

The Chief Data Officer reporting line is the second most common, particularly at organisations whose existing MLOps function was substantial before the agent layer emerged. The function operates as an extension of the broader machine learning operations organisation, and its priorities are shaped by the data-platform team's existing competencies and the data governance regime the CDO function operates under. The strategic strength of this placement is that the function inherits a mature data governance posture, which is consequential for agent deployments that touch regulated data categories. The strategic limitation is that the broader CDO function's relationship with the engineering organisation is sometimes contested, and the agent-platform team can find itself caught between the CDO's data-governance priorities and the engineering function's velocity priorities. Several of the financial services organisations that placed the function under CDO have had to add a dotted-line reporting relationship into VP Engineering to manage this tension.

The Chief AI Officer reporting line is the newest and the most strategically distinctive. The Chief AI Officer role itself has emerged at approximately 60 of the Fortune 500 over the past 18 months, typically as a peer to the CIO and CDO with explicit responsibility for the organisation's AI strategy, deployment, and governance. The Chief AI Officer reporting line for the agent-platform team produces the strongest strategic mandate — the function operates as a central capability provider with explicit board-level visibility into its decisions — but it also produces the highest dependency on the Chief AI Officer's personal credibility, because the role is new at most organisations and its mandate is still being negotiated against the existing CIO, CDO, and CTO roles. The organisations that have placed the function under Chief AI Officer include Bank of America, Walmart, and several enterprise SaaS companies whose Chief AI Officer was hired explicitly to build the function. The strategic implication is that these organisations are betting on the Chief AI Officer role being durable; the bet is reasonable but not yet validated by sustained operational evidence.

The minority of organisations that have placed the function under Chief Information Security Officer is the placement worth examining for its specific dynamics. The placement is most common at organisations whose initial agent adoption produced an incident — a data leak, a compliance violation, an outage — that elevated the security function's role in agent governance. The CISO reporting line produces a posture that is heavily compliance-weighted, and the function's deployment velocity tends to be slower than the equivalent function under VP Engineering or Chief AI Officer. The strategic strength is that the function's governance maturity tends to be highest under this placement, which is consequential for organisations operating in heavily regulated environments. The strategic limitation is that the function's relationship with the broader engineering organisation tends to be more adversarial than at other placements, because the security function is structurally positioned to slow deployment in service of compliance. Several organisations that initially placed the function under CISO have rebalanced over time to a hybrid placement that gives the engineering organisation more operational control while preserving the security function's governance oversight.

The four responsibility areas and how each operates in practice

The model routing responsibility is the most operationally consequential of the four. The function's task is to determine, for any given application's request, which model and which vendor should handle it. The decisions involve cost (each vendor's pricing varies by model and request type), latency (the same model from different vendors can have meaningfully different latency profiles), capability fit (some models perform better on specific request categories), and compliance (data residency, audit logging, and contractual commitments differ across vendors). The model routing infrastructure that the agent-platform teams have built typically operates as a routing service that application teams call through a standardised interface; the routing logic itself is encoded in policy files that the agent-platform team maintains and updates as the underlying vendor landscape and capability profiles evolve. The named companies whose model routing services have been most widely discussed in the engineering leadership community include the JPMorgan internal service, Workday's "ModelMux" platform, and Walmart's internal routing layer (which the company has described publicly at engineering conferences without naming the platform internally).

The eval harness operation responsibility involves running the infrastructure that measures whether the organisation's agent deployments are producing the intended business outcomes. The harness operates at three levels: per-application evals that the application team owns but the agent-platform team supports through shared infrastructure; cross-application evals that measure agent capability consistency across the organisation; and vendor-evaluation evals that the agent-platform team uses to assess incoming vendor proposals or capability changes from existing vendors. The shared infrastructure includes prompt management (versioning, A/B testing, rollback), trace collection (capturing the agent's reasoning at each step for post-hoc analysis), and outcome measurement (whether the agent's output produced the intended downstream outcome). The most mature of these eval harnesses run at substantial scale — JPMorgan's internal eval platform processes approximately 12 million eval runs per month across the bank's deployed agent applications. The infrastructure investment to run an eval harness at this scale is substantial, but the function's value to the organisation's agent strategy is correspondingly high, because the harness is what allows the organisation to make decisions about vendor selection and deployment scope on the basis of evidence rather than vendor marketing claims.

The agent-runtime SLA responsibility is the operational discipline that most distinguishes the agent-platform team from the broader machine learning operations function. The agent runtime — the system that executes agent requests in production, manages tool calls, handles error cases, captures traces — has operational characteristics that are different from both traditional application runtime and traditional ML model serving. Agent requests can run for minutes (whereas API requests typically complete in milliseconds and ML predictions in tens of milliseconds), can fail in subtle ways (a tool call that succeeds but produces incorrect data, an LLM hallucination that produces plausible but wrong output), and can produce variable costs (the same logical request can consume different amounts of token budget depending on the model's reasoning path). The SLA framework the agent-platform teams have built reflects these characteristics: latency SLAs are measured at percentiles rather than means; success SLAs distinguish between technical success and outcome success; cost SLAs are measured against budget envelopes rather than per-request prices. The framework is mature at the more advanced organisations and still emerging at the recently formed agent-platform teams; the difference in SLA framework maturity is one of the more diagnostic differentiators between the function's adoption tiers.

The vendor management responsibility is the area where the function's commercial mandate matters most. The agent-platform teams at the more mature organisations have direct procurement authority over the agent vendor contracts, which at the present scale represents substantial budget control. JPMorgan's agent-platform team manages contracts worth approximately $180M annually across its agent vendor portfolio. Bank of America's manages approximately $140M. Walmart's manages approximately $95M. Workday's manages approximately $40M. The vendor management work involves not only commercial negotiation but also operational oversight: vendor performance reviews, capacity planning, capability gap analysis, and the ongoing portfolio rebalancing as vendor capability profiles evolve. The commercial-operations leadership embedded in the agent-platform teams is the function that the broader engineering organisations have most consistently struggled to recruit, because the role requires a hybrid commercial-technical skill set that is not yet well-represented in the standard procurement or engineering management talent pools. Several of the named organisations have hired this role from the management consulting firms — Bain, McKinsey, BCG — whose AI advisory practices have produced people with the relevant skill mix.

The named companies and the budget authority patterns

The named companies whose agent-platform team configurations have been most thoroughly characterised in the engineering leadership community span the Fortune 500 categories. In financial services, JPMorgan Chase's team — under the leadership of a Managing Director-level head reporting to the bank's VP-level Head of AI Platform — runs at 14 engineers and managers with direct procurement authority over $180M in annual contracts. The team is placed under the Chief Data Officer function with a dotted-line into the Chief Information Officer's office. Bank of America's team, established in early 2025, runs at 11 engineers and managers under the bank's Chief AI Officer (a role established in late 2024). Citigroup's team, established in mid-2025, runs at 9 engineers and managers under the bank's Chief Technology Officer with explicit consultation into the Chief Risk Officer's function for governance decisions. Goldman Sachs has not formed a discrete agent-platform team in the same way; the bank's strategy has been to embed agent-platform responsibility within existing engineering functions, which has been workable but has produced some of the coordination problems the function emerged elsewhere to solve.

In retail, Walmart's team — established in late 2024 under the company's Chief AI Officer — runs at 12 engineers and managers and manages approximately $95M in annual agent vendor contracts. The team's positioning is distinctive in that it explicitly covers both the engineering use cases (the retailer's substantial software engineering organisation) and the marketing and merchandising use cases (the retailer's substantial deployment of agent capabilities in product description generation, content moderation, and customer service). The dual coverage is more comprehensive than most agent-platform teams achieve, and Walmart's structure has been studied by other large retailers as a reference pattern. Target's team is smaller at 7 engineers and managers and is placed under VP Engineering. Lowe's team is similar in size to Target's and is placed under Chief Technology Officer with a hybrid mandate that includes both engineering and merchandising use cases. Home Depot has not formed a discrete agent-platform team; the company's strategy has been similar to Goldman Sachs in financial services — embedded responsibility within existing functions.

In enterprise SaaS, the named companies are interesting because they are simultaneously consumers of agent infrastructure and producers of agent-integrated products. Workday's agent-platform team, established in early 2025, runs at 10 engineers and managers and is responsible both for the company's internal agent deployments and for the agent infrastructure that powers the company's customer-facing product capabilities. The dual mandate is more complex than the typical agent-platform team's scope and has produced an organisational structure that includes both an internal-platform sub-team and a product-platform sub-team under the same agent-platform leadership. ServiceNow's team, established in mid-2025, runs at 9 engineers and managers with a similar dual mandate. Salesforce's team is the largest among enterprise SaaS at 18 engineers and managers, reflecting the company's particularly substantial investment in agent infrastructure across both internal and product-facing surfaces. The company's Chief AI Officer role, established in late 2024, has been one of the more visible Chief AI Officer positions in enterprise SaaS.

The budget authority patterns vary substantially across these named companies, but the variation tracks an identifiable pattern. The agent-platform teams that have been operating for longer — JPMorgan, Walmart — have accumulated direct procurement authority over the vendor contracts in their scope. The teams that emerged more recently — Citigroup, ServiceNow — typically operate with influence rather than direct authority, with the procurement decisions still routed through the central procurement function under the Chief Procurement Officer or equivalent. The trajectory is consistent: as the function matures, the procurement authority transfers from central procurement to the agent-platform team's commercial-operations leadership. The transfer typically happens at the 18-24 month mark from team formation, and the catalyst is often a specific commercial decision — a vendor renewal, a capability expansion, a contract restructuring — that the central procurement function does not have the technical depth to handle effectively. The structural finding for organisations considering the formation of an agent-platform team is that budget authority should be planned for from the outset, even if it is not transferred immediately, because the eventual transfer is the function's structural endpoint.

The capabilities the function has built and the limits it cannot yet bridge

The capabilities that the more mature agent-platform teams have built are substantial and have produced concrete operational benefits for their organisations. The model routing capability at JPMorgan reduces the bank's monthly agent infrastructure spend by approximately 22 per cent relative to a non-routed baseline, primarily through intelligent distribution of requests across vendor contracts to maximise utilisation of paid-for capacity. The eval harness capability at Walmart has reduced the time-to-production for new agent capabilities by approximately 40 per cent by providing application teams with shared evaluation infrastructure rather than requiring each team to build its own. The vendor management capability at Bank of America has produced approximately $24M in annual savings through commercial negotiations that the central procurement function would not have been positioned to achieve without the agent-platform team's technical input. The structural value of the function is well-evidenced at the operational scale these organisations operate at; the function pays for its headcount many times over through the savings and velocity gains it produces.

The limits the function cannot yet bridge are equally important to characterise. The first limit is the integration depth that the function can achieve into the broader engineering organisation's day-to-day work. The agent-platform team is structurally a central function that provides shared services to a federated population of application teams. The integration depth — how much the application teams actually use the shared services, how much friction they encounter in adopting them, how much value they extract from them — varies substantially across the organisations and within organisations across application teams. The agent-platform teams that have invested in adoption tooling and developer relations — internal documentation, paired-programming engagements, dedicated support channels — have produced higher integration depth, but the investment is substantial and the integration depth remains the function's most consistent operational challenge.

The second limit is the function's relationship with non-engineering use cases. The agent-platform teams are predominantly engineering-led and engineering-staffed, and their fluency with the operational concerns of marketing, customer service, operations, and legal functions tends to be lower than the engineering organisation's fluency. The function's mandate often includes responsibility for the agent infrastructure that supports these non-engineering use cases, but the function's substantive engagement with the use cases is typically lower than the breadth of the mandate would suggest. Several of the named companies have addressed this through the deployment of business partners — individuals embedded in the agent-platform team whose specific responsibility is the relationship with non-engineering functions — but the model is still emerging and the consistency of execution varies. The structural finding is that the function's mandate may need to evolve over the next 12-24 months to either narrow to engineering use cases (with non-engineering use cases falling to a parallel function) or broaden the staffing to include business operators with non-engineering backgrounds.

The third limit is the function's relationship with the vendors themselves. The agent-platform teams' commercial mandate has produced a substantial increase in the sophistication of vendor engagement at the named companies, but the asymmetry between the vendors' commercial sophistication and the agent-platform teams' commercial sophistication remains significant. The vendors operate with full-time commercial teams whose responsibility is enterprise sales; the agent-platform teams' commercial-operations leadership is typically one to three individuals across multiple competing demands. The implication is that the vendors retain commercial advantages that the agent-platform teams have to compensate for through technical depth and operational discipline. The vendors who have been most successful in the enterprise segment — Anthropic in particular has been frequently cited by enterprise procurement leaders as the vendor whose enterprise sales motion is best-calibrated to the agent-platform team's needs — have invested in commercial models that work with rather than against the agent-platform team's structural position. The vendors who have been less successful in the segment have continued to operate with enterprise sales motions calibrated to the broader Chief Information Officer buyer rather than the more technical agent-platform team buyer, and the segment's procurement decisions have shifted accordingly.

What to watch

The agent-platform team function is approximately 18 months old at the more mature organisations and approximately 6 months old at the more recently formed teams. The function's structural maturation will continue through 2026 and into 2027, and the trajectory will be visible in several specific developments that the engineering leadership community will be monitoring.

• Whether the function emerges at the next tier of Fortune 500 organisations through the second half of 2026; the pattern is replicable enough that the present 40-organisation footprint is likely to expand to 100-120 organisations within 18 months, and the rate of emergence will indicate how rapidly the function is becoming an enterprise standard.
• Whether the Chief AI Officer reporting line consolidates as the canonical placement for the function, or whether the variation across VP Engineering, Chief Data Officer, and Chief AI Officer placements persists; the consolidation would signal that the Chief AI Officer role has become a structural enterprise function rather than a transitional position.
• Whether the budget authority transfer pattern — from central procurement to the agent-platform team's commercial-operations leadership — accelerates as the function matures, or whether central procurement retains authority at organisations whose existing procurement function is more entrenched; the trajectory will affect the function's strategic posture toward vendors.
• Whether the eval harness infrastructure that the more mature agent-platform teams have built becomes commercialised — either through individual organisations open-sourcing their internal platforms or through enterprise vendors (LangChain Inc., specifically LangSmith) extending their products to serve the agent-platform team buyer specifically.
• Whether the agent-platform teams' relationship with the broader business operator functions — marketing, customer service, operations, legal — matures sufficiently to handle the non-engineering use cases the function's mandate often includes, or whether the structural mismatch between engineering staffing and business operator engagement produces a parallel function specifically for non-engineering agent infrastructure.

Frequently asked

Why is the agent-platform team a new function rather than an extension of an existing function like MLOps or platform engineering?

The function emerged because no existing org-chart entity was structurally positioned to handle all four of the responsibilities the function consolidates: model routing, eval harness operation, agent-runtime SLAs, and vendor management at scale. Platform engineering had the technical capability for the first three responsibilities but lacked the commercial mandate for the fourth. MLOps had the vendor management experience but its existing competency was around training and data pipelines rather than agent runtime. The Chief Information Security Officer's function had the vendor governance capability but lacked the technical depth on agent runtime. The agent-platform team emerged as a hybrid function that absorbed responsibility for all four problems, with composition drawn from platform engineering, MLOps, and commercial operations.

What is the typical headcount for an agent-platform team, and what determines the size?

The headcount typically ranges from 5 to 12 engineers and managers, with the median sitting around 8. The size is determined primarily by the scale of the organisation's agent deployments — total annual contract value across agent vendors is the most predictive variable — and secondarily by the regulatory and integration complexity of the organisation's industry. Financial services organisations tend toward larger teams (10-14) because of the additional governance overhead. Retail organisations vary more substantially (7-12) depending on the breadth of use cases covered. Enterprise SaaS organisations that simultaneously consume and produce agent infrastructure tend toward larger teams (10-18) because of the dual internal-and-product mandate.

Under which executive role should an agent-platform team report?

There is no single correct answer; the placement should match the organisation's strategic posture toward AI. VP Engineering placement produces an engineering-focused tilt that works well when the use cases are predominantly engineering. Chief Data Officer placement produces a stronger governance posture that works well in regulated industries. Chief AI Officer placement produces the strongest strategic mandate but depends on the durability of the Chief AI Officer role at the organisation, which is still being negotiated against the existing CIO, CDO, and CTO roles. Chief Information Security Officer placement produces the highest governance maturity but tends to slow deployment velocity. The most common placements are roughly even split across VP Engineering, Chief Data Officer, and Chief AI Officer, with CISO placement at a minority of organisations.

What is the budget authority typically associated with an agent-platform team?

The budget authority varies substantially across organisations and tends to transfer over time. At the more mature agent-platform teams — JPMorgan, Walmart, Bank of America — the team's commercial-operations leadership has direct procurement authority over the agent vendor contracts in its scope, which at the present scale represents tens to hundreds of millions of dollars annually. At more recently formed teams, the function operates with influence rather than direct authority, with procurement decisions routed through the central procurement function. The transfer from central procurement to agent-platform team typically happens at the 18-24 month mark, catalysed by a specific commercial decision the central procurement function does not have the technical depth to handle effectively.

How does the function's mandate cover non-engineering use cases?

The function's mandate typically covers the agent infrastructure that supports non-engineering use cases — marketing, customer service, operations, legal — but the function's substantive engagement with those use cases is often lower than the breadth of the mandate would suggest. The function is predominantly engineering-led and engineering-staffed, and its fluency with the operational concerns of non-engineering functions tends to be lower than its fluency with engineering concerns. Several mature organisations have addressed this through embedded business partners — individuals in the agent-platform team whose specific responsibility is the relationship with non-engineering functions — but the model is still emerging. The structural question over the next 18-24 months is whether the function's mandate narrows to engineering use cases (with non-engineering use cases falling to a parallel function) or whether the function's staffing broadens to include business operators.

How long does it take for an agent-platform team to reach full operational maturity?

The trajectory observed across the named companies is approximately 18-24 months from formation to operational maturity. The first six months are typically focused on team composition and immediate problem solving — addressing the most acute coordination gaps the function was formed to handle. Months 6-12 are typically focused on building the shared infrastructure (model routing service, eval harness, SLA framework). Months 12-18 are typically focused on adoption and integration depth with the broader engineering organisation. Months 18-24 are typically focused on the commercial-operations and vendor management work that completes the function's mandate, including the budget authority transfer from central procurement. The trajectory varies based on the organisation's existing infrastructure investment and the executive support the function receives.