BCG Says Strategy Matters More Than Tools — Part 2: From Agent Adoption to Governed Tools and Runtimes

Part 1 read two BCG publications together — the AI at Work 2026 survey (June) and The Agentic Leadership Playbook: A Scaling Strategy for CTOs and CIOs (early July 2026; practitioners Mark Abraham and Neveen Awad) — and mapped selected survey and leadership findings to documented AI Gateway controls. This part takes both documents' agent findings — the survey's adoption-versus-governance statistics and the playbook's practitioner observations about what changes when agents act rather than recommend — and continues the same section-by-section pattern, receiving the hand-off Part 1 made explicit: build agents against a trusted core, inspect their observable execution and measured outcomes, expand as confidence grows. BCG reports agents mainstreaming quickly while governance lags: roughly 30% of respondents say their organizations have integrated AI agents into workflows, about 61% expect agents to do half their job within three years, yet roughly half of respondents say their companies lack clear governance for teams that include people and AI. This part applies the same editorial method to those agent findings, asking how governed tool access (the MCP Gateway) and a managed runtime (the Agent Harness) can address part of the operating-model gap. As in Part 1, BCG figures are paraphrased with primary-source citations, and capabilities are cited inline to TrueFoundry's documentation.

1. Recap: the Pattern, and Where the Agent Findings Sit

Part 1 established the method: BCG names a gap; a documented control maps to one technical portion of it; the operating decisions stay with the organization. Its findings concerned model traffic and aligned to the AI Gateway. BCG's agent findings are different in kind. An agent is not a single model call; it is a loop that plans, calls tools, observes results, and decides whether to continue — and those tool calls reach real systems and require real credentials. Governing an agent therefore means governing two things the AI Gateway alone does not fully cover: the tools the agent calls, and the runtime that drives the loop.

That is why this part introduces two further capabilities rather than reusing the first. The MCP Gateway governs tool access — the Model Context Protocol traffic between agents and the systems they act on. The Agent Harness is the runtime that runs the agent loop with governance built in. The sections below take them in turn: the deficit, tool governance, the runtime, then workflow redesign and deployment.

2. The Finding: Agents Are Mainstreaming Faster Than Their Governance

BCG's agent data carries opportunity and warning in one breath: roughly 30% of respondents say their organizations have integrated AI agents into workflows — up from 13% the prior year — and approximately 61% believe agents could perform at least half of their job responsibilities within three years (bcg.com/press/3june2026). Beside it sits the governance reading: roughly half of respondents say their companies lack clear governance for managing teams that include people and AI, and a majority report limited understanding of what agents are.

Adoption racing ahead of governance is worse for agents than for chat because an agent acts, chains actions across tools, and frequently holds credentials to do so. An ungoverned agent population is therefore a standing exposure — unregistered agents, embedded credentials, unaudited tool access. The playbook, published a month later from the opposite vantage point, reports the same shape: about 5% of companies agent-first, most others below 30% adoption, the difference attributed to leadership and change discipline rather than model choice (the playbook). It also names why the governance gap matters more for agents than for chat: agents act rather than recommend, so a bad input's cost moves from a misleading slide to a misfired action — the practitioners' example, a flawed "lapsed customer" definition sending a campaign awry. The gap BCG measures from the workforce is the same gap an infrastructure team sees from above, and the two sections that follow align it to two documented technical control surfaces that can address part of it: MCP-mediated tool access, then a governed agent runtime.

3. Governing What Agents Call → the MCP Gateway

The first half of agent governance is the tools. Many agents reach external systems through tools, increasingly via the Model Context Protocol — and wherever they do, every security team asks the same question: with whose credentials, under what authorization, with what audit trail? This aligns to the MCP Gateway. Per TrueFoundry's documentation, agent tool authentication lives in the MCP Gateway rather than in the agent: agents call tools by name, and the gateway handles credential injection, token refresh, and per-user delegation (docs/agent-platform/agent-harness/overview). The product surface adds the controls that make this enterprise-grade: routing MCP tool calls through registered servers, applying OAuth2, RBAC, and metadata-based policies to gateway-mediated tool invocations, and tracing and attributing those calls for security and compliance review (MCP servers in the Agent Harness docs).

This addresses what makes ungoverned agents dangerous: centralized, gateway-managed authentication reduces the need to embed credentials in agent definitions — credentials become easier to rotate, scope, and revoke, held centrally rather than pasted into configs. Centralized identity, delegation, per-tool RBAC, and tool restrictions can help reduce confused-deputy and over-permission risk. And because gateway-mediated tool calls are traced and attributed, BCG's implied question — which agent did what, to which system, with what data — has an answer for the traffic the gateway carries. The MCP Gateway extends Part 1's guardrails from model calls to tool calls: the same govern-at-the-gateway principle, applied to the actions an agent takes rather than the text it generates. It is also the concrete form of the playbook's data doctrine. When the practitioners advise building agents against a trusted core of data and expanding the surface as confidence grows, the registry is one access-control mechanism around a trusted core: it constrains which approved servers and tools the agent may use, scoped by RBAC and per-user delegation, and expanding it is a deliberate, auditable registry change. The organization still has to establish the quality, provenance, and semantic correctness of the underlying data.

4. Governing How Agents Run → the Agent Harness

The second half of agent governance is the runtime — the loop itself and its controls. This aligns to the Agent Harness, which TrueFoundry describes as a managed harness built on the AI Gateway and MCP Gateway: you choose a model, connect MCP servers, add skills, and write instructions, while the platform manages orchestration, sandbox lifecycle, tool execution, approvals, governance, and observability (docs/agent-platform/agent-harness/overview). Its defining governance property: no API keys or credentials are ever pasted into agent definitions — models, MCP servers, and skills are referenced by name through a central control plane, with model credentials in the AI Gateway, tool authentication in the MCP Gateway, and skills in a versioned, RBAC-governed Skills Registry.

The harness addresses one technical portion of BCG's governance deficit. Per its documentation it runs an orchestration loop — plan, act, observe, continue or stop — with tool routing and execution, memory and context controls for long-running tasks, security boundaries including sandboxing and permissions, and human-in-the-loop approval gates that pause sensitive tool calls and require explicit approval before they execute (docs/agent-platform/agent-harness/overview). Because the harness runs in the same gateway plane as model and MCP traffic, governance and observability stay in one system rather than three. The result is one technical portion of "governance for human-and-AI teams," expressed as a runtime: agents acting with governed identities, drawing on sanctioned models and tools, and pausing configured sensitive or destructive tool calls for approval. It is also where the playbook's staged discipline becomes operational: build against the trusted core, then use run traces, evaluations, and business outcomes to decide when to expand an agent's data access or authority.

5. Supervising the Agent Wave → Harness Observability and Approvals

Agents raise Part 1's supervision question one level up — directing an agent is harder than directing a single call — and the harness answer is per-step tracing plus approval gates. Per TrueFoundry's writing, observability across model, tool, and agent traffic should be one pane — end-to-end traces per run, with cost, tokens, and latency per step (blog/agent-harness-managed-ai-agents). That per-step trace is what gives a supervisor a legible record of what an agent did, which tool it called, and what each step cost — the agent-scale version of the visibility BCG's managerial-revolution finding requires, and the practical implementation of the playbook's advice to watch how agents perform and make inferences before expanding their authority: run traces make the observable execution path legible — tools called, actions selected, explicit intermediate outputs, approvals, costs — though they do not expose a model's private internal reasoning.

The approval gate is the other half: selected sensitive or high-impact tool calls pause for explicit human authorization — supervision precisely placed, not constant watching. Approval gates and MCP access controls can reduce the blast radius of configured sensitive actions; they do not eliminate the broader governance and operating-model risks BCG's data shows most organizations have not yet addressed.

6. "Redesign Workflows End to End" → the Runtime and Its Deployment

End-to-end workflow redesign needs an execution environment in which agentic workflows can be built, observed, and governed; the Agent Harness is one such managed runtime. It inherits model-access policy, budgets, rate limits, and guardrails from the AI Gateway, while runtime execution controls and approval gates help govern configured behavior (harness docs; on bounding loops generally, see our loop-engineering post) — the same budget-and-policy machinery from Part 1, scoped to the agent loop, which is why the harness is built on the AI Gateway rather than separate from it.

Deployment makes this usable for the regulated enterprises in BCG's 14-market sample: the platform runs as SaaS, self-hosted, or on-prem, with a split-plane architecture in which the compute plane — including the gateway — runs inside the customer's own cloud account, so prompts, completions, and data need not leave it (blog/field-notes-ai-cost-gateway-not-a-switch). For a bank or a hospital, "where does this run" is itself a strategy question, and deployment flexibility lets attribution, guardrails, and MCP governance remain in the gateway plane while the Harness runs in the same customer-controlled environment — including workloads that cannot use multi-tenant SaaS — deployment flexibility that can make governed agent operation feasible for sovereignty-sensitive or regulated workloads. The playbook adds the redesign's accelerant and its boundary: agents compress the slowest input — an eight-week data gathering-and-cleaning cycle into roughly a week, in the practitioners' account — while the intelligence layer — in Abraham's definition, mapping the company's actual business context onto its data so agents understand the drivers of the business — remains human work, the most underappreciated part of agentic deployment in their telling. Awad states the leaders' orientation in this post's one direct quotation from the playbook: "They ask, 'How do we work differently?'" — not how to deploy agents (the playbook). Agents accelerate the redesign; they do not author it.

7. The Division of Labor, Stated Plainly

It would misrepresent both BCG and TrueFoundry to claim the platform closes the value gap by itself; TrueFoundry states the boundary in its own writing: these primitives are what make the operating model possible — they are not the operating model by themselves; the platform gives you the dial and the data, and a capable team still has to set the thresholds and act on the alerts (blog/field-notes-ai-cost-gateway-not-a-switch). That is the same division BCG's strategy-versus-tools contrast implies (+25 points for strategic clarity versus +5 for tool access, in the survey's comparison) — and the playbook states it in its own numbers: success with agentic implementation is about 70% people and change management, with the furthest-along enterprises having trained more than half their workforce. Strategy sets the thresholds, decides what to measure, chooses what to retire, and determines what higher-value work should fill the hours AI returns. The four capabilities this series mapped — AI Gateway, guardrails, MCP Gateway, Agent Harness — can make selected technical policies enforceable and produce the telemetry that helps organizations review them. BCG does not prescribe this architecture; the mapping is TrueFoundry's interpretation of one way to operationalize part of the response.

The Part 1 sequence holds at the agent level: strategy first, then the execution layer that lets it act. A governed runtime without a strategy yields governed agents doing unclear work; an agent strategy without governed execution leaves open the technical portion of the operating-model gap BCG measures. Across both parts the claim has been constant and narrow: strategy remains the higher-leverage variable; a shared control plane can help translate parts of that strategy into governed technical behavior.

8. The Whole Mapping, in One View

Taken together, the two parts align BCG's findings to four capabilities across gateway and runtime layers, each cited to documentation: cost attribution and observability (AI Gateway), guardrails and policy-as-configuration, tool governance (MCP Gateway), and the governed runtime (Agent Harness) — with approval gates, traces, and SaaS/self-hosted/on-prem deployment. The pattern never changed: a BCG finding on one side, a documented capability on the other, and the operating decisions held by the organization throughout.

‍

‍