How to Build Real-World Opencode Agents: 5 Working Examples

Opencode agents turn repetitive DevOps chores into autonomous workflows—here’s how you can start building them with five concrete, production‑ready examples.

Why Build Opencode Agents? – The Pain Points Developers Face

Common automation gaps in CI/CD pipelines

When you look at a typical CI/CD pipeline, it appears that most steps—code checkout, unit tests, container build, deployment—are automated. Yet manual work still creeps in, often in the form of quick fixes that could be automated.

Environment drift detection. A nightly build may succeed, but a feature branch that runs on a different VM can fail because a library version was upgraded on the host. The pipeline lacks a hook that compares the actual runtime environment against the declared requirements.txt or pom.xml.
Dynamic secret rotation. Secrets managers rotate database passwords regularly, but the deployment step still reads a static .env file, forcing engineers to pause the pipeline and manually copy the new values.
Post‑deployment validation. After pushing a Docker image to Kubernetes, the service is rarely verified from inside the cluster. A “smoke test” that checks the load balancer from the CI runner does not confirm in‑mesh connectivity.
Resource usage alerts. Builds that spike CPU usage above a threshold generate alerts that are not surfaced in the pipeline, delaying investigation.
Roll‑back safety checks. When a deploy fails, manual inspection of kubectl rollout status is required before deciding to roll back, a step that is error‑prone and often missed.

Each of these gaps is a small, repetitive task that developers treat as “just another script.” Scripts tend to sit in isolation, are hard to version together with the pipeline definition, and lack a consistent way to surface results back to the CI system.

Consider a scenario where a feature branch upgrades rails in the Gemfile. The CI job runs bundle install inside a Docker container that still has an older version of openssl. The build fails with OpenSSL::SSL::Error. A one‑off apt-get install libssl-dev line is added to the Dockerfile, fixing the branch but not the underlying pattern. An Opencode agent could watch the Gemfile.lock diff, compare it against a known‑good OS baseline, and automatically propose or apply the missing apt-get step before the build starts, eliminating the manual loop.

Reduced mean time to recovery – the agent reacts in seconds rather than minutes.
Consistent state across environments – every run starts from the same verified baseline.
Visibility baked into the pipeline – success or failure of the agent is reported as a standard CI job, keeping the signal clear.

Limitations of out‑of‑the‑box scripts and webhooks

Stateless execution. A script triggered by a webhook runs in a fresh container each time. It has no memory of previous runs, so it can’t deduplicate work. For example, a “branch created” webhook that triggers a linting script will re‑lint the same files on every commit, wasting CI minutes.
Hard‑coded credentials. Out‑of‑the‑box scripts often embed API keys directly in the source. When a key rotates, you must hunt through dozens of script files to patch them, increasing the risk of security incidents.
Lack of retry logic. Webhook payloads are unreliable; GitHub may resend a payload if the endpoint returns a non‑2xx response. Most scripts abort on the first failure, leaving pipelines in a half‑finished state.
Opaque error handling. A bash script that runs curl against an internal service prints the raw HTTP response to STDOUT. CI dashboards only see “script exited with code 1,” making triage difficult without digging into logs.
Scattered configuration. When multiple webhook listeners exist for PR comments, tag pushes, and security scans, each carries its own config file. Keeping those files in sync across environments consumes engineering bandwidth.

# webhook_handler.sh
#!/usr/bin/env bash
payload=$(cat -)
branch=$(echo "$payload" | jq -r .ref)
if [[ "$branch" == "refs/heads/main" ]]; then
  curl -X POST -H "Authorization: Bearer $DEPLOY_TOKEN" \
       https://deploy.example.com/start
fi

The script works until the DEPLOY_TOKEN expires. Because the token is read from an environment variable set at container start, the webhook silently fails with a 401 response. The CI job reports only a non‑zero exit code, requiring a log inspection to discover the token rotation issue.

State persistence. Agents can store checkpoints in a lightweight KV store, so they know whether a particular PR has already been linted or whether a secret has already been rotated.