Introducing AI Agent Deployment in Harness Continuous Delivery | Harness Blog

• Agent development today is too risky. Only ~8% of organizations have gotten agentic AI into production. Most of the rest are stuck deploying agents by hand or with one-off CI jobs. This slows teams down and, for those who push forward anyway, leaves no record of who deployed what or how its quality was evaluated.
• Deployment is where that risk actually lives. Building an agent has gotten easy; getting it into production safely hasn't. Fixing that starts with the deployment step itself: predictable, repeatable, and owned by the platform.
• Harness makes agent deployment safe and easy. Agent Deployments in Harness CD brings tested, out-of-the-box pipeline steps for platforms like Google's Agent Runtime and Amazon Bedrock AgentCore, so teams get governed, auditable agent releases without hand-rolled scripts, using the RBAC, policy engine, and audit trail they already trust for the rest of their software delivery.
• Agents don't ship alone. Harness coordinates the agent alongside what it depends on: backend services, database changes, and prompt or model config. There’s one release governed by one tool.

‍

Overview

Teams building agents have converged on something that looks a lot like the software development lifecycle, but reshaped around a system whose output isn't deterministic: prototype an agent against a framework, evaluate it against a dataset of expected behavior, deploy it somewhere real, observe how it behaves against live traffic, and feed what you learn back into the next prototype. Call it the agent development lifecycle (Agent DLC). 

Most of that lifecycle borrows tooling that already existed - a framework like LangGraph or Google's ADK for the prototyping stage, an eval platform for the evaluation stage. This post is about one stage of that lifecycle: deployment, and the decisions behind how we help users deploy their agents reliably with Harness Continuous Delivery.

Because deployment is when an agent shifts from being safely under test to being exposed to production, decision-making and safety are critical. Organizations need to ensure that only good versions of agents are actually released, policies are adhered to, and a dependable audit trail is created. 

Further complicating agent deployments is the fact that agents rarely stand alone and are often updated alongside changes to data, configuration, front ends, and companion services. Deploying an agent is not enough. We have to orchestrate its changes with everything else in a release.

This article covers how agent deployments are different, how to govern them, and what release orchestration with agents looks like. In short, how to make agent deployments both safe and easy.

Where deployment sits in the agent lifecycle

Something genuinely new shows up in the deployment stage of the Agent DLC. Rather than packaging an agent as a generic container and hosting it the way any other service gets hosted, AWS and Google both shipped purpose-built, managed runtimes for agents specifically - Bedrock AgentCore and GCP Agent Runtime. 

Unlike a general compute product with an agent tutorial bolted on, these runtimes are shaped around what an agent actually needs - session and memory primitives, identity scoped to the agent rather than the pod, versioned "runtime revisions" instead of arbitrary deploys.

That's the piece that benefits from dedicated automation support. It's worth spending a minute on what changes when the target is one of these runtimes instead of a Kubernetes cluster, before getting into what we actually decided. The shift to managed runtimes means teams either build this operational muscle themselves or get it from a platform.

Kubernetes vs. Native agent runtime: what actually changes

None of this is an argument that Kubernetes is the wrong place to run an agent - plenty of teams will keep doing exactly that, and it's on our roadmap as a deployment target for this same agent-service model. It's a genuinely different set of trade-offs, not a strictly better or worse one.

This operational surface (session stores, readiness probes, traffic routing) is exactly what a native runtime (and what Harness's deployment step) absorbs for the team. The first two rows are the reason a native runtime exists at all - session and memory management is genuinely hard to get right underneath an agent, and both clouds decided it was worth building once, centrally, rather than leaving every team to rebuild it next to their pod. 

The rows below that are the downstream consequence: once the platform owns session, memory, and isolation, it ends up owning versioning and traffic control too, because those all have to agree with each other underneath.

The trade Kubernetes gives up in exchange for that control is exactly the operational surface a native runtime absorbs for you: you're not sizing replica counts, standing up your own state store, or writing readiness probes for something whose "readiness" is closer to a language-model call than a TCP health check. Whether that trade is worth it depends entirely on how much of that control a given team actually wants to keep exercising, which is the real reason we're not treating native runtimes as the only supported target going forward.

A working example: the Academic Research Agent

Let's take an example of an Academic Research Agent - a LangGraph agent that searches academic papers and journals, synthesizes findings across sources, and drafts a literature-review section for a researcher to approve. It's been working in a notebook. Getting it live means three things: register it as a service, define where it runs, and put a pipeline in front of it that can promote it safely.

Deployable Entity - The Agent Service

Does a customer think about their Academic Research Agent as one thing, or as two different things depending on which cloud it happens to run on? We bet on one thing. An agent's name, its config and secrets, its purpose - those don't change depending on where it's deployed. This eliminates the need to maintain multiple deploy scripts for what is functionally one agent.

What changes is the shape of the cloud underneath it: the image reference and agent framework on Google's side, the execution role on AWS's. So the service definition keeps a single outer identity with the cloud-specific pieces contained inside it, rather than asking someone to maintain what is functionally the same agent as two separate service definitions.

We know this model works well. Our existing Kubernetes deployment type has separate infrastructure kinds per cloud (GCP, Azure, direct) underneath a single deployment type. What's different here is applying that same idea one layer higher, at the service itself, because what defines an agent - its name, purpose, and configuration - doesn't change across clouds, even though the infrastructure underneath it does get changed.

We have registered our Academic Research Agent as an Agent Service on Harness. Now, the question is about the target platform configuration, which involves defining your infrastructure.

Infrastructure: What does the agent need on a specific cloud?

The infrastructure definition is where the cloud-specific configuration lives. For the Academic Research Agent on AWS AgentCore, that means:

• A connector Harness uses to call AWS's deploy APIs
• A region, and the VPC subnets and security groups the agent should run inside
• A reference to an AgentCore Gateway - required only if traffic shifting matters

The Gateway is the one worth pausing on. It isn't automatically part of an AgentCore deployment - it's additional infrastructure the team provisions up front, specifically so traffic shifting has something to act on. If the Academic Research Agent's infrastructure skips it, deployments still work; every promotion is just a direct cutover instead of a gradual one, because there's nothing underneath to hold a partial split.

If the target is Google's Agent Runtime, the infrastructure definition asks for less than AWS's, because traffic shifting doesn't need a separate resource to act on; it's native to how GCP serves revisions.

For the Academic Research Agent here, that means:

• A connector Harness uses to call Google Cloud's deploy APIs
• A project and a region
• A networking type - left at None by default, or set to a private connectivity mode if the agent needs to reach resources inside a VPC rather than over the public internet

Deployment via pipeline: Simplifying deploy, shift, rollback

Underneath, the two clouds don't agree on how traffic splitting actually works. On Google's runtime, a percentage split is native to how revisions are served - the platform already speaks in those terms. AWS has no equivalent primitive on the runtime itself, which is why the Academic Research Agent's pipeline needs that Gateway from the infrastructure section: our traffic-shift step reads the gateway rule's current routing action and rewrites it, switching between a direct route and a weighted split depending on whether the requested split is a clean cutover or a partial one. Two different cloud mechanics, one authored concept on our side - a target revision and a percentage, so the pipeline for the Academic Research Agent reads the same shape it would if it were deployed to Google instead.

Rolling back the Academic Research Agent never creates anything new. It re-points traffic - or, without a Gateway configured, flips the runtime endpoint directly - back to whatever was live before. That target resolves automatically from what the deploy step actually did; nobody authors it by hand.

The rollback step automatically resolves its target to what the deploy step produced.

Orchestrating the Release - Multiple Agents and Backend Service

Key thing to note: Multiple agents can now be deployed together, along with other backend services, in a release.

Governance: Delivering Safely 

Everything so far has been about one agent. In practice, it's never just one - the Academic Research Agent ships, and a few months later, the same research org builds a Grants Compliance Agent, owned by a different team, and to save on infrastructure, the two agree to share the same AWS AgentCore Gateway for traffic shifting. That's a completely reasonable thing to do, and it's exactly the point where governance stops being optional: a careless traffic-shift call from one agent's pipeline shouldn't be able to touch the other's routing rule, and "who deployed what, to which backend, and when" needs one answer across every agent, not a different answer per team.

We didn't build a separate governance layer for agents. An Agent Service and its infrastructure definition are first-class Harness resources, so the same three mechanisms that already govern every other deployment type apply here without modification:

RBAC: Registering an Agent Service, editing its infrastructure, triggering a deploy or rollback - scoped the same way as any other service and environment in Harness. Two agents can share a Gateway while sitting in different projects with different owners, because RBAC lives at the Harness resource level, not the cloud API level, where a shared Gateway would otherwise blur that line.

Policy as Code: Every AI Agent pipeline execution is a plan that Harness can evaluate against OPA policies before it runs, the same as any other deployment type. That's what actually protects a shared Gateway - a policy can require a traffic-shift step only to touch rules the deploying agent owns, block an overly-permissive execution role, or enforce a minimum instance count before a full cutover. Same policy engine, pointed at a new deployment type.

Approvals and audit trail: Production promotions carry the same approval step regardless of cloud target. Every deploy, shift, and rollback across every agent lands in one execution history - so "what changed on the shared Gateway, and who approved it" has one answer, not one per team.

We reused the existing model instead of deferring it, so a team's first agent and their fiftieth are governed the same way - nothing to retrofit once there's more than one.

What's next

This phase covers deployment. Two extensions are already on the roadmap.

Kubernetes as a third, agent aware deployment target:  Alongside Google’s Agent Runtime and Amazon Bedrock AgentCore, we plan to let you deploy the Academic Research Agent directly to your own Kubernetes cluster - define an Agent Service with Kubernetes as the target, create a Kubernetes infrastructure definition, and get the same progressive-delivery shape through deployment strategies like canary and blue-green, rather than a separate set of primitives built just for agents.

Evaluation gates and observability, wired into the same pipeline: The outcome this phase already produces - a revision, an endpoint, a traffic state - is exactly what the next phase needs as input: a quality gate before promoting the Academic Research Agent, a validation check after, and visibility into how it's actually behaving in production. That's next on the roadmap, using eval provider connectors - Harness AI Evals, Braintrust, LangSmith, Arize, Langfuse, and others as the ecosystem grows.

FAQs

Q: What is Harness Agent Deployment?

A: Agent Deployments is a capability in Harness Continuous Delivery that brings tested, out-of-the-box pipeline steps to deploying AI agents. Instead of scripting a deploy by hand, teams register their agent as a first-class Harness service and get governed, repeatable releases.

Q: How do I deploy an AI agent to Amazon Bedrock AgentCore?

A: Register the agent as an Agent Service in Harness, define an AWS AgentCore infrastructure target (region, VPC/security groups, and optionally an AgentCore Gateway if you need traffic shifting), then run it through a Harness CD pipeline, which handles packaging, deployment, and — if a Gateway is configured — progressive traffic rollout.

Q: How do I deploy an AI agent to Google Agent Runtime?

A: Same model as Bedrock, with a lighter infrastructure definition — a connector, project, and region, plus an optional private networking mode. Traffic shifting doesn't need a separate resource the way AgentCore does, because Google Agent Runtime natively supports revision-based traffic splitting.

Q: Can I deploy AI agents to Kubernetes with Harness?

A: Yes. However, as of the writing of this blog, agent-specific support has not been added for Kubernetes, and the deployment is treated as a standard K8s artifact. We intend to add agent-aware Kubernetes support in the near future.

Q: What's the difference between deploying an agent to a managed runtime vs. Kubernetes?

A: Managed runtimes (Bedrock AgentCore, Google Agent Runtime) handle session/memory management and per-session execution isolation natively — something you'd otherwise have to stand up yourself on Kubernetes (a Redis store, custom readiness probes, etc.). It's a genuine tradeoff, not a strictly better option: Kubernetes gives you more control over that operational surface; the managed runtimes take that control away from you in exchange for not having to build it.

Q: Does Harness support canary or blue/green deployments for AI agents?

A: Harness supports progressive traffic shifting for agents — a target revision plus a percentage split, authored the same way regardless of which cloud you're deploying to, even though the two clouds implement traffic splitting differently under the hood (native revision-split on Google's side, a Gateway routing rule on AWS's).

Q: How does rollback work for AI agent deployments?

A: Rollback re-points traffic to whichever revision was live before, rather than creating a new one — the rollback target resolves automatically from what the deploy step produced, so nobody has to author it by hand.

Q: Can I govern and audit AI agent deployments the same way I govern application deployments?

A: Yes. An Agent Service and its infrastructure are ordinary Harness resources, so RBAC, OPA policy-as-code, and audit trails apply without any separate configuration for agents. This is also what lets two teams safely share underlying infrastructure (like an AgentCore Gateway) without one team's deploy affecting the other's.

Q: What frameworks does Harness support for AI agent deployment?

A: All major agent development frameworks eg. CrewAI, LangGraph, Agents SDK, ADK and custom frameworks as well.