Strip any production agent down and you find the same anatomy: a loop that calls a model, a set of tools the model may invoke, state that survives across turns, and — the part that separates production from demo — the enforcement points where your rules override whatever the model wants to do. That surrounding machinery is the harness, and in 2026 it has become its own engineering discipline. The question every team building agents now faces: how much of the harness do you build, and how much do you rent from your cloud?

Both hyperscalers spent the last year answering aggressively. AWS shipped Bedrock AgentCore — a managed harness where you define the agent in configuration (model, tools, instructions) and the platform runs the loop. Google's answer is the open-source Agent Development Kit (code-first, Python/Go/Java/TypeScript) deployed onto Agent Engine, a managed runtime handling autoscaling, sessions, and long-running execution. I've built harnesses from scratch and evaluated both managed stacks; here's how they compare on the four pillars that actually decide production-readiness — identity, guardrails, cost, and knowledge — and what I'd recommend.

# the four pillars — managed offerings, july 2026
                    AWS                             Google Cloud
orchestration       AgentCore harness (config)      ADK (code-first) + Agent Engine
identity & access   AgentCore Identity + Gateway    IAM + per-agent service accounts
guardrails          Bedrock Guardrails @ gateway    Model Armor
cost control        gateway spend caps + caching    quotas + context caching
knowledge           Bedrock Knowledge Bases         Knowledge Catalog (OKF-aware)

Identity: agents get their own credentials, scoped per tool

The first production question is not "what can the model do?" but "as whom is it doing it?" The anti-pattern is an agent inheriting a blanket service credential — one over-broad role attached to everything the loop touches. Both clouds now push the right pattern: the agent is a first-class identity. On AWS, AgentCore Identity handles the agent's authentication and per-tool authorization, enforced at the AgentCore Gateway with full audit logs via AgentCore Observability. On Google Cloud, each agent runs as its own IAM service account, with per-tool permissions and Cloud Audit Logs doing the same job in IAM's vocabulary.

The principle to hold onto whichever you choose: authorization decisions happen per tool call, not per session, and the audit trail must record which identity invoked which tool with which arguments. If you build your own harness, this is middleware in front of every tool dispatch — the same place I put per-tenant permissions in my own multi-agent platform, because a tool contract without an identity check is an open door with good documentation.

Guardrails: enforce outside the context window

The most architecturally interesting release of the year is quiet but profound: Bedrock Guardrails now runs inside AgentCore's policy layer, at the gateway — checks for prompt injection, harmful content, and sensitive-data exposure execute outside the agent's context window. The agent can't see the guardrail, so it can't reason around it, and no amount of injected text can convince it the rule doesn't apply. Google's Model Armor plays the same role on the GCP side, screening prompts and responses for injection and data leakage as a service in front of the model.

This is the pattern to copy even if you rent nothing else: guardrails are infrastructure, not prompt engineering. A rule written into the system prompt is a suggestion the model has been asked to remember; a rule enforced at the gateway is a property of the system. Filter both directions — inbound for injection, outbound for leakage — and keep the enforcement code somewhere the model's text can never reach.

Cost: hard caps at the gateway, cache discipline in the loop

Agent cost failure is rarely one expensive call — it's a loop that retries enthusiastically, a tool that returns 40k tokens of JSON, a tenant whose usage quietly triples. The managed stacks now give you two levers. First, deterministic spend caps enforced at the gateway (AgentCore's policy layer; quotas and budget alerts on GCP) — hard limits that don't depend on the agent behaving. Second, cache discipline: Bedrock prompt caching and Gemini context caching both cut per-call cost dramatically, but only if you structure for it — the practical guidance is to place the cache breakpoint after the stable prefix (system prompt plus tool definitions) and before the dynamic conversation history, so the expensive tokens are paid for once.

What neither cloud gives you is the judgement layer: model tiering (cheap models for classification and routing, capable ones only where reasoning earns its cost) and per-tenant unit economics. Those stay yours to build, and they matter — cost per task varies enormously between naive and disciplined harnesses doing identical work.

Knowledge: this is where the clouds genuinely differ

Identity, guardrails, and cost are converging on the same patterns with different names. Knowledge is where the strategies split. AWS gives you Bedrock Knowledge Bases — solid managed RAG: ingest, chunk, embed, retrieve. Google is playing a different game: Dataplex was renamed Knowledge Catalog this spring and repositioned as the grounding layer for agents — serving governed, versioned enterprise metadata and business meaning to agent reasoning, and it understands the Open Knowledge Format. That makes GCP the first hyperscaler whose catalog natively consumes the compiled knowledge layer I've argued every organisation needs: your OKF bundles become directly consumable context, with lineage and governance inherited from the catalog rather than bolted on.

If your agents' differentiation is what they know — and in the enterprise it almost always is — this pillar should weigh heaviest in your evaluation.

Recommendations

The harness wars are good news: a year ago all of this was artisanal. But don't mistake the managed loop for the moat. The moat is what you put through it.