Worker Agent examples
Explore Worker Agent examples including PR review, IaC plan safety, spec-driven development, and implementation agents.
Worker Agent examples demonstrate real-world patterns for PR review, infrastructure plan safety, spec-driven development, and code generation. Each example uses agent.uses: harnessAI@1.0.0, with the prompt and connectors under agent.with and reusable parameters under agent.inputs. Use these examples as templates when building your own Worker Agents for CI and CD pipelines.
Set llmConnector and mcpConnectors to connector identifiers available in your account, organization, or project. The examples retain model overrides in with.env.ANTHROPIC_MODEL; omit that override and its modelName input to use the connector default. The base template supplies the container and runtime environment.
What you will learn in this topic
By the end of this topic, you will be able to:
Before you begin
Before you explore these examples, ensure you have the following:
Worker Agents enabled: Harness AI and Worker Agents must be enabled in your account. Go to Enable Harness AI for instructions.
Model Connector configured: At least one Anthropic or OpenAI connector. Go to Model Connectors for setup instructions.
MCP Connector configured: Harness Hosted MCP connector for platform data access. Go to Configure MCP connectors for setup instructions.
Pipeline access: Permission to create and edit pipelines in your Harness project.
Example: Staff Engineer PR Review Agent
This agent acts as a Principal-level Staff Engineer and Security Architect. It performs deep, opinionated review across four domains: Security, Compliance, Schema/Architecture, and Engineering Judgment. Use this agent for high-risk or architecture-sensitive changes that require thorough technical scrutiny.
Example: Diff-scoped PR Reviewer
This agent is trigger-aware and diff-scoped. It retrieves the exact PR and diff identified by the pipeline trigger context, including PR number, source/target branch, and commit SHAs, and reviews only the changed lines. It avoids broad architectural commentary not caused by the diff. Use this agent for high-frequency PR pipelines where precision and low noise matter.
Key differences from the Staff Engineer example:
Trigger-aware targeting: Uses
<+trigger.prNumber>,<+trigger.sourceBranch>,<+trigger.targetBranch>,<+trigger.commitSha>, and<+trigger.baseCommitSha>for precise PR targeting via Harness MCP.Diff-scoped review: Reviews only files and lines changed by the diff, not the entire repository.
Lower cost:
with.max_turns: "40"(compared to"150") for faster, lower-cost execution.Explicit failure mode: Stops and reports if the exact diff cannot be retrieved.
Example: IaC Plan Safety Agent with output variables
This agent inspects a Terraform or OpenTofu JSON plan file and produces a structured risk assessment with a clear APPROVE, REVIEW, or REJECT recommendation. The prompt writes a JSON report and publishes named results to the runtime output files for downstream gating, notifications, or conditional logic.
Key features of this example:
Report file:
with.outputis the path to the JSON report the agent must produce. Named pipeline variables are published by the shell commands in the prompt.Shell-based output publishing: The agent instructions include shell commands that extract values from a JSON report and write
KEY=valuelines to$HARNESS_OUTPUTand$DRONE_OUTPUT.MCP-augmented context: The agent uses Harness MCP to look up pipeline and execution metadata, enriching the assessment with deployment context.
Structured JSON contract: The agent writes a validated JSON assessment file and publishes key fields as output variables for pipeline-level consumption.
Agent definition YAML
Output configuration
agent.with.output names the report file that the template verifies after the run:
The full prompt above publishes RECOMMENDATION, RISK_LEVEL, MAX_RISK_SCORE, VALIDATION_STATUS, RISK_ASSESSMENT_PATH, and SUMMARY as named outputs. with.output is a file path; do not put a name/alias array in this field. Check the agent step's Output tab for the published variable names and expressions.
How output variables flow end-to-end
The agent instructions include shell commands that write
KEY=valuelines to$HARNESS_OUTPUTand$DRONE_OUTPUT(such asprintf 'RECOMMENDATION=%s\n' "$RECOMMENDATION" >> "$OUTPUT_FILE").Confirm that the expected named variables appear in the agent step's Output tab after execution. The
with.outputsetting separately identifies the report file the agent must produce.Downstream pipeline steps reference these outputs using Harness expressions such as
<+steps.assess_plan_safety.steps.iacm_plan_safety_agent_1.output.outputVariables.RECOMMENDATION>.
Go to Example: IaC plan safety gate with agent outputs to see a complete pipeline that consumes these output variables in a downstream gating step.
Example: Spec-driven development with chained agents
This use case demonstrates three Worker Agents chained in a single pipeline to automate a spec-driven development workflow. When a pull request adds or modifies a Features.md file, the pipeline:
Feature Analyzer Agent: reads the features file from the PR diff and generates a
Spec.mdin the same directory, then commits it to the PR source branch.Plan Generator Agent: reads the spec and generates a
Plan.mdwith a task-level work breakdown, then commits it to the PR source branch.Implementation Agent: reads the plan, implements tasks in order, runs tests, and commits code changes to the PR source branch. It tracks progress in a sidecar status file.
Each agent is a standalone Worker Agent definition that can be reused independently. The pipeline chains them sequentially so each agent builds on the artifacts produced by the previous one.
Agent 1: Feature Analyzer (spec generator)
This agent scans the PR diff for Features.md files, generates a structured spec for each one, and commits the spec to the PR source branch.
Agent 2: Plan Generator (spec + coding plan)
This agent extends the spec generator to also produce a Plan.md with a task-level work breakdown, architecture decisions, and test strategy. It reads the spec as its primary input and commits both spec and plan artifacts in a single batched commit.
Agent 3: Implementation Agent
This agent reads the coding plan, implements tasks in order, runs build and test commands, and commits code changes to the PR source branch. It tracks progress in a sidecar status file so subsequent runs resume where the previous run left off.
Pipeline: Spec-driven development
This pipeline chains the three agents sequentially. When a PR adds or modifies a Features.md file, the pipeline generates a spec, generates a coding plan from the spec, and implements the plan tasks, all committed back to the PR source branch.
How the chain works
A developer opens a PR that adds or modifies a
Features.mdfile.A webhook trigger fires the pipeline on the PR event.
Feature Analyzer Agent reads the PR diff, finds the features file, generates
Spec.md, and commits it to the PR source branch.Plan Generator Agent reads the spec (committed by the previous agent or already existing), generates
Plan.mdwith a work breakdown, and commits it to the PR source branch.Implementation Agent reads the plan, implements tasks from the work breakdown in order, runs build and test commands, and commits code changes to the PR source branch. It creates a sidecar status file to track progress across runs.
The developer reviews all generated artifacts (spec, plan, code) in the PR before merging.
Customize this workflow
Run only spec and plan generation: Remove the Implementation Agent step for teams that want AI-generated specs and plans but prefer manual implementation.
Gate between agents: Add an Approval step between the Plan Generator and Implementation agents so a human reviews the plan before code generation starts.
Limit implementation scope: Set the
maxTasksPerRuninput on the Implementation Agent to control how many tasks are implemented per pipeline run.Trigger on labels: Configure the pipeline trigger to fire only when a specific label (such as
agent-implement) is applied to the PR, so implementation runs on demand rather than on every push.
Next steps
Worker Agents overview: Learn how to create and manage Worker Agents.
Worker Agent configuration: Configure instructions, MCP connectors, inputs, and environment variables.
Use Worker Agents in pipelines: Add Worker Agent steps to pipelines and reference agent outputs.
Last updated
Was this helpful?