Autonomous Worker Agents: AI Agents in Your Pipelines

| Harness Blog

AI is writing more of the code. Software delivery, the work between writing code and running it in production, is where most of the day still goes. Building, testing, scanning, deploying, remediating, and operating still require the same, if not more, effort as before AI. 

Today, we're introducing Autonomous Worker Agents for software delivery: the platform for enterprises to build and safely run AI agents that handle the work between writing code and shipping it to production. 

Autonomous Worker Agents execute as pipeline steps and produce auditable outputs. Their memory is the organization: services, pipelines, deployments, incidents, policies, all connected through the Harness Knowledge Graph, and their capability is powered by the Harness MCP. They operate in production and support the deployment, security, remediation, and validation of your code.

They join Harness Expert Agents, which have been available to customers for some time, to form a complete AI layer across the platform.

Each agent runs as a step inside a Harness pipeline, on customer-controlled infrastructure, with full governance: scoped credentials, OPA policy enforcement, approval gates, and complete audit trails.

Safe to Run in Production

Autonomous Worker Agents are invoked as pipeline steps or independently. They inherit the governance Harness pipelines already provide. Instead of trying to teach an AI agent a massive list of corporate rules, the agent operates entirely within the constraints of your existing software delivery pipelines.

• OPA Policies that gate production deployments gate the agents.
• RBAC that controls who can push to production controls who can trigger an agent.
• Approval Gates apply before an agent's fix ships, just as they do before any release.

Safety is architected in as well. Workloads execute on Harness Delegates, lightweight runtimes installed inside the customer's own Kubernetes cluster or VPC. An agent that "shouldn't be able to merge to main" cannot merge to main, even if its prompt asks it to. The architecture enforces it.

‍

We built RiskSentinel, a Harness Autonomous Worker Agent, to demonstrate that governed AI can move beyond identifying security issues to safely remediate them while maintaining enterprise controls, auditability, and compliance. When building with Harness, what stood out most was how intuitive the experience was — it enabled our team to move from an initial idea to a production-ready agent in just four days, allowing us to focus on solving a real enterprise challenge rather than the underlying platform. That combination of developer experience and enterprise-ready capabilities is what will enable organizations to confidently scale AI across software delivery.
Ratna Devarapalli, Director IT, United Airlines

Six additional controls make Autonomous Worker Agents production-safe.

1. Sandboxing

Agents are run containerized, with non-root execution (UID 65534, "nobody"). Their filesystem is read-only except for the workspace. Network access is configurable per agent: unrestricted, restricted to allowed MCP servers, or fully disabled.

An agent that produces a malicious bash command has nowhere to send the data.

2. Scoped Credentials

When a pipeline triggers, Harness mints an ephemeral scoped token. Its scope is the intersection of the agent's permissions and the triggering user's RBAC.

Token deletes on completion. TTL as a failsafe. MongoDB TTL index as final backstop.

3. Policy Enforcement

OPA policies, the same framework Harness customers use to govern deployments, apply to agents. Policies govern the agent at runtime and during configuration. 

4. Audit Trails

Every execution is captured in the Harness Audit Trail. This includes a full provenance chain: who or what triggered the agent, template version, every action taken, and final outcome.

Prompts and reasoning chains are sanitized before persistence: secrets stripped, and PII is stripped.

5. Cost Tracking

Token consumption and costs are surfaced per execution, per agent, and per pipeline. Running totals are shown live in the step header.

6. Chaining

Agents are architected to run within pipelines and can be naturally composed into multi-step workflows.

• Sequential: Agent B consumes Agent A's output.
• Parallel: agents run simultaneously.
• Conditional: an agent runs only if a previous step meets a condition.
• Matrix: same agent across repos, environments, or services.

Output handoff happens via pipeline expressions and shared workspace files.

Three ways to create an agent

Using YAML

A Worker Agent is defined in a single file. Here's a complete agent that reviews every pull request for security issues:

gent:
   group:
     steps:
       - name: Run Code Coverage Agent
         id: runCodeCoverageAgent
         if: <+Always>
         run:
           container:
             image: pkg.harness.io/vrvdt5ius7uwygso8s0bia/harness-agents/harness-ai-agent:latest
           env:yam
             ANTHROPIC_MODEL: ${{inputs.model_name}}
             PLUGIN_HARNESS_CONNECTOR: ${{inputs.llm_connector.id}}
             PLUGIN_MAX_TURNS: "150"
             PLUGIN_MCP_FORMAT: harness
             PLUGIN_MCP_SERVERS: <+connectorInputs.resolveList(<+inputs.mcp_connectors>)>
             PLUGIN_TASK: |
               Autonomous Harness Code Coverage Agent; no prompts. Resolve branch/repo/clone_url/account/org/project/execution strictly: input -> env -> MCP, never guess; branch must exist via SCM MCP or fail.
               Use /harness first, else $HARNESS_WORKSPACE; if repo missing, clone (SCM MCP preferred, git fallback) and checkout resolved branch.
               Detect language/test/coverage stack, run baseline coverage (overall + per-file), and target >=90% overall and >=80% per-file.
               Add meaningful tests for critical uncovered paths (happy/edge/error/boundary); allow only minimal production testability tweaks.
               Re-run full tests + coverage + lint + build; all must pass before continuing.
               Review full diff (SCM MCP preferred, git diff fallback); allow only tests + minimal testability tweaks (+ COVERAGE.md only if it already exists; never create it).
               Build report with overall before->after, per-file before/after for touched files, and key improvements.
               Stage files one-by-one only; never use git add -A or git add .; verify staged diff is clean and in-scope.
               Create exactly one commit: "Code coverage: automated test additions by Harness AI"; push plain to origin <branch> (no pull/rebase/merge/force).
               If push fails, print rejection, git reset --hard HEAD~1, exit non-zero; never commit unrelated changes, never weaken existing tests, never log secrets.

YAML frontmatter on top. Natural language below ---. The same convention Jekyll, Hugo, and AI agent definitions across the industry use.

Save the file, commit it to the repo, and the agent is live, governed, and in the catalog. Every PR triggers it. Every run is audited. Every action is scoped by RBAC. From a blank file to a live governed agent in minutes.

The Harness pipeline engine handles container runtime, scoped credentials, MCP server integration, audit logging, and cost tracking.

Using the UI

The Harness Agent Builder is a simple form for configuring your Agents. Define your prompts in plain English, referencing Harness constructs through common expressions. This experience makes it easy to see what you need to provide and set up your agent in minutes.

All agent definitions are stored in Harness. Their reference in pipelines can be managed in Git. Approval gates apply. Pipeline Branch-based versions let teams test new agent behavior in feature branches before merging to main.

"We built an agent that handles log analysis directly inside Harness. No tool switching, no context loss. The ability to stay on one platform and have the agent surface what's happening and review it for us was the biggest immediate win. We're planning to use it in production."
Mandy Pearce, Senior Engineer, Cloud Automation, Verint

‍

Create with MCP

Using your favorite coding agent, you can connect to Harness over the MCP. The MCP bridges the AI Coding agents’ inner-loop context and the outer-loop context and the constructs in Harness. 

‍

Agents as Pipeline Steps

Most software delivery workflows have more than one step. Autonomous Worker Agents compose with shell scripts, plugins, approval gates, and other agents to make full pipelines.

Referencing an Agent in a Pipeline

pipeline:
 stages:
   - steps:
       - name: Feature Agent
         template:
           uses: ca_feature_triage_agent@1.0.2
       - name: Plan Agent
         template:
           uses: ca_work_planning_agent@1.0.2
       - name: Build Feature Agent
         template:
           uses: ca_builder_agent@1.0.2

uses: references a Worker Agent template by name and version. The agent runs as one step alongside everything else a Harness pipeline can run.

Sequential: Output Handoff

Agent B consumes Agent A's output. The pipeline expression ${{ steps.<agent_id>.output }} carries the result forward.

pipeline:
 stages:
   - steps:
       - name: spec design
         parallel:
           steps:
             - name: Feature Agent
               template:
               uses: ca_feature_triage_agent@1.0.2
             - name: PR Body
               template:
                 uses: pr_body_writer
                 with:
                   artifactPath: ${{featureagent.output.artifact}}
                   issueKey: cds-1234

Parallel

Multiple agents run simultaneously:

 parallel:
           steps:
             - name: Feature Agent
               template:
                 uses: ca_feature_triage_agent@1.0.2
             - name: PR Body
               template:
                 uses: pr_body_writer
                 with:
                   artifactPath: ${{featureagent.output.artifact}}
                   issueKey: cds-1234

Step Groups

A Step Group bundles agents and deterministic steps into a single reusable unit:

         group:
           steps:
             - name: feature anaylzer
               template:
                 uses: feature_ingester_agent@1.0.2
             - name: work planner
               template:
                 uses: ca_work_planning_agent@1.0.4

Save the group as a template. Reference it from any pipeline. The PR Autofix workflow ships as a Step Group template.

Conditional and Matrix

An agent runs only when a condition is met:

  - steps:
         group:
           steps:
             - name: feature ingest
               template:
                 uses: feature_ingester_agent
             - name: work planner
               template:
                 uses: ca_work_planning_agent
     name: Spec Driven Development
     if: <+OnPipelineSuccess>

The same agent runs across multiple targets:

             - name: work planner
               template:
                 uses: ca_work_planning_agent
               strategy:
                 fail-fast: true
                 for:
                   iterations: 3

Approval gates, failure strategies, retry policies, and rollback work the same way they do for any other pipeline step.

‍

Introducing the Harness Agent Marketplace

The Harness Agent Marketplace is where teams discover, install, fork, customize, and publish Autonomous Worker Agents.

Three publisher tiers anchor it:

• Harness Managed: Built and maintained by Harness. SLA-backed. Versioned. Pinnable (e.g., harness.autofix@1.2).
• Harness Certified: Partner-built. Reviewed and certified by Harness engineering and security. Examples: dependency vendors with their own scanning agents, cloud providers with cloud-specific deployment agents.
• Community: Published by the broader Harness community. Validated for schema, no secrets in prompt. Enterprise accounts can restrict via OPA policy. Allow only Managed and Certified in production, for instance.

Harness Managed Agents

With today’s launch, Harness has pre-built agents for the most requested use cases. Here are some examples of what’s currently available: 

CI Autofix

Reads build logs from a failed PR build, identifies the root cause, commits a fix to the PR branch, re-triggers the build, and repeats until the build passes or the configured max-turns limit is reached.

Manifest Remediator

Analyzes failed Kubernetes deployments. Identifies whether the issue is the manifest, the cluster, or the workload. Fixes manifest issues. Used by teams managing dozens of services across multiple clusters.

Code Review

Reviews PR diffs across security, quality, and test coverage. Outputs structured findings with severity ratings and concrete remediation. Grounded in the Harness Knowledge Graph, the agent knows which services are production-critical, which have had recent incidents, and which historical anti-patterns have caused outages.

Feature Flag Cleanup

Reads code, config, and flag-system state to identify feature flags that are fully rolled out or fully off. Once it validates removal is safe, the agent generates a cleanup PR. With this agent, the status of your experiments automatically informs you when flags are cleaned up, reducing flag debt and the drudgery of cleaning up old flags.

Code Coverage

Reads coverage reports, identifies untested lines, branches, and functions, and generates tests to close gaps. Used when a team has inherited a codebase with weak coverage and needs to lift it before a release.

IaCM Remediation

Fixes configuration drift, security findings, and cloud cost issues by editing infrastructure configurations.

‍

Bring Your Own Model

Autonomous Worker Agents are model-agnostic. Connect LLM providers through Harness connectors:

• OpenAI: Direct to Provider
• Anthropic: AWS Bedrock, Direct to Provider 

The model can be specified at three levels: in the agent template, at the pipeline step level (overriding the template), or at the account level via environment variable defaults. Switch models per agent, per environment, or per pipeline without changing agent logic.

Three reasons this matters:

1. Cost. Different models have different price points. Routing high-volume work through cheaper models is a common pattern.
2. Compliance. Some teams require AWS-routed Bedrock for billing consolidation, VPC routing, or Bedrock-specific compliance attestations.
3. Future-proofing. Model leaders change. The enterprise decides which model today, which model tomorrow.

Getting Started

Autonomous Worker Agents are available today for all Harness customers. Learn more about Harness Autonomous Worker Agents or request a demo to see them in production.

Visit the in-app Harness Marketplace in app to try out any of the Worker Agents. Add it to your pipeline and watch it run.