The industry has spent two years comparing models. Meanwhile, two applications running the same model deliver measurably different outcomes — different success rates, different costs, different failure modes — because of the system wrapped around it. That system now has a name, a discipline, and a market. This is a framework for choosing yours.
Between the application your users see and the model you rent sits a layer most architecture diagrams leave blank. Microsoft now ships a product called an Agent Harness; OpenAI named the discipline harness engineering; Anthropic's Agent SDK is one. Click each layer to place the boundary.
Everything between the application and the raw model: context assembly, tool execution, memory, orchestration, state, permissions, verification, guardrails, observability, recovery, and cost control. This layer is the site's subject — and the decision most enterprises haven't consciously made.
Reasoning, language, code, judgment — rented by the token from a fast-moving market.
Decides what the model sees, what it can do, how work proceeds, what it may never do, and how you know it worked.
The experience or process where converted intelligence meets a business metric.
The model provides intelligence. The harness determines how that intelligence operates. The application determines where it creates value.
A production-grade harness answers eleven questions — from what does the model need to know? to what does a successful task cost? Every team that ships an agent answers all eleven, deliberately or by accident. Explore each layer at your altitude.
Your teams are already answering these eleven questions — one improvised answer per team. Harness choice is deciding which answers become shared infrastructure.
This stopped being a hunch in 2026: benchmarks now score model + harness pairs, and a cluster of research measured what happens when you hold the model constant and swap only the harness. The exhibits below carry their sources and their caveats.
A model benchmark that doesn't disclose its harness is quoting a different test — and a cost-per-token comparison that ignores harness efficiency can be wrong by an order of magnitude.
"Which harness?" is a workload question before it is a vendor question. Coding lives on verification loops; enterprise search lives on identity-aware retrieval; business process agents need nearly everything at full strength. Select a workload to see which capabilities carry it.
Workloads disagree about what matters. A single enterprise harness standard either over-constrains your easy workloads or under-protects your hard ones — standardize the control plane, vary the harness.
The major ecosystems are not interchangeable products with different logos — they occupy different layers and encode different bets. Facts below are sourced; interpretation is labeled as ours. Snapshot: 2026-08-23.
Google is betting that the enterprise control plane — identity, tool governance, observability, data — is the durable layer, and keeps model, framework and runtime swappable around it. Selling Claude in its own model garden and donating A2A are consistent with that bet.
Strong fit if you want managed harness infrastructure without committing the application layer to one vendor's models. The naming churn (Vertex AI → GEAP) is real migration work; pin product names in contracts.
Portability — models: High — 200+ models incl. Anthropic and open weights on the same plane. Harness: Medium — ADK is open source and runs anywhere; Agent Engine services are Google-managed. Tools: High — MCP everywhere; Apigee wraps existing APIs without rewrites.
Don't ask "which vendor wins." Ask which layers each vendor wants to own, and whether that matches the layers you want to keep.
"Should we build our own harness?" is really eleven questions wearing one coat. Four sourcing postures dominate; none is universally right. Compare their trade-offs, then open the full evaluation checklist.
The house view: this is not one decision but eleven. Build the loop only where it differentiates; buy identity, observability and policy everywhere; and let workloads with mature dedicated harnesses (coding) use them — under shared governance.
Build the loop only where it differentiates you. Buy identity, observability and policy everywhere. And when a workload has a world-class dedicated harness — coding — adopt it under shared governance instead of rebuilding it worse.
The frontier is re-fusing model and harness — vendors now train models inside their own harnesses — while the middle of the market goes model-agnostic. Pick your posture on each axis and see what the combination commits you to. Then: the six forms of portability, honestly.
Route cheap steps to fast tiers and hard steps to frontier models, under one identity/policy/observability plane with cost-per-task instrumentation built in. Most large estates land here for the bulk of workloads — with dedicated harnesses carved out where they demonstrably win (coding).
Portability isn't one property — it's six, and they behave very differently. Click each to see where coupling actually occurs.
Evaluate models together with their harnesses — that pair is what you actually deploy. Then engineer your exit paths deliberately: portability is six different properties, and only some of them are cheap.
Requirement first, product second: each of the eleven capabilities, Google's architectural approach to it, and the services involved — including where third-party models, open frameworks and custom harnesses are first-class citizens rather than workarounds.
Managed retrieval as a service (enterprise search + RAG orchestration), grounding on Google Search and Maps, and native context caching so stable prefixes get ~90% cheaper reads.
Memory as a managed runtime service rather than app code: sessions for working state, Memory Bank for topic-extracted long-term memory across sessions.
Treat tools as API products: Apigee converts existing API specs into managed MCP tools with policy attached, and API hub syncs with the Agent Registry so agents discover only cataloged tools. 50+ Google-managed MCP servers cover BigQuery, Maps, databases.
ADK 2.0's graph-based workflow runtime blends deterministic routing (fan-out/fan-in, loops, retries, human-in-the-loop) with LLM-driven agents and sub-agent hierarchies; A2A handles agent-to-agent interop across vendors.
Managed session persistence in the runtime plus sandboxed code execution; long-running work is a platform property, not per-team plumbing.
Agents get first-class IAM identities — not shared service accounts — with mTLS certificates rotating every 24h and tokens cryptographically bound to them; the Agent Gateway enforces access policy on agent traffic; audit logs record agent and on-behalf-of user.
Evaluation as a service: LLM-judge and custom criteria over final responses and full trajectories, agent simulation for pre-production stress-testing, plus ADK's built-in eval harness for CI.
A dedicated screening layer (prompt injection, jailbreak, sensitive data, URLs) applied at the gateway and on MCP traffic, with streaming sanitization — independent of which model runs behind it.
OpenTelemetry GenAI semantic conventions as the native format: Agent Engine auto-exports traces to Cloud Trace, console shows span DAGs with inputs/outputs, dashboards track token usage and error rates.
Workflow-level retries and human-in-the-loop confirmation in ADK's runtime; model fallback via Model Garden breadth; escalation surfaces in Gemini Enterprise inboxes.
Structural levers: batch at flat −50%, context caching at ~−90% on cached reads, provisioned throughput for committed capacity, and a fast/cheap Flash tier for routing — plus per-trajectory token accounting in observability.
The question isn't "does Google have an agent product" — everyone does. It's whether you can adopt the layers you need, keep the layers you have, and swap the layers you'll regret. Open seams are the differentiator.
Procurement compares dollars per million tokens. Production pays for context re-sent every turn, cache misses, extra turns, retries and failures. Move the sliders — the interesting moment is when the cheaper-per-token profile loses on cost per successful task.
Buy outcomes, not tokens: cost per successful task — across turns, retries and cache economics — is the metric that survives contact with production.
Four hypothetical but realistic enterprise patterns. Each flow highlights which harness capabilities do the heavy lifting — the boxes that turn a demo into a system you can audit, afford and trust.
An analyst asks for a competitive briefing. The agent plans, fans out across web and internal sources, verifies claims, and returns a cited brief.
In every one of these diagrams the model is one box. The reliability, the safety and the economics live in the boxes around it.
Eleven questions, four maturity levels each. Score your current architecture honestly — the profile on the right shows where you're engineered and where you're improvising. Nothing you click leaves this page.
You've been deciding which model to standardize on. You should also be deciding what harness architecture you're standardizing around — and this profile is where that conversation starts.