TLDR overview
- An agentic pipeline is a delivery workflow in which agents decide what to try and deterministic controls decide what is allowed to move forward. The agent supplies judgment. The pipeline supplies guarantees.
- Gates belong in three places: before execution (inputs and permissions), after changes and before merge (tests and independent code verification), and before sensitive actions (risk-based human approval).
- Start with a sequential pipeline or an agent-generated pull request. Add typed handoffs, least privilege, sandboxes, and bounded repair loops before you add autonomy.
- An agent that reviews its own work is not verification. Run checks outside the agent’s control and hold agent code to the same standard as human code.
Give a coding agent a ticket and a repository and it will usually hand back a pull request. The trouble is the rest of the time: the agent misreads the ticket, edits a file it should never touch, makes a failing test pass by weakening the test, or follows an instruction buried in an issue comment.
Developers already sense the gap. In Sonar’s 2026 State of Code survey of more than 1,100 developers, 96% said they do not fully trust AI-generated code to be functionally correct, yet only 48% said they always check it before committing. Agents widen that gap, because they produce more code, faster, with fewer people watching each step.
An agentic pipeline is the practical response. It lets agents make bounded decisions inside deterministic controls: typed handoffs, least-privilege access, independent verification, and approvals sized to the risk.
Agents decide what to try. The pipeline decides what is allowed, and whether the result is good enough.
The rest of this article covers how the pieces connect, where the gates belong, which patterns to start with, and what makes these systems brittle or unsafe. It ends with a checklist for a first pilot.
What are agentic pipelines?
An agentic pipeline is a software delivery workflow in which AI agents make some of the decisions, such as interpreting a task, planning a change, choosing which tools to call, or diagnosing a failure, while deterministic controls decide what moves forward. The term also appears in data and machine learning work. Here it means the path from an issue to a merged, deployable change.
It helps to separate it from three things it is often confused with.
Anthropic’s widely cited framing separates workflows, where LLMs and tools are orchestrated through predefined code paths, from agents, where the model directs its own process and tool use. An agentic pipeline uses both. The outer structure is a workflow, and some stages inside it are agents. A practical test is whether you can draw the full execution path before the run starts. Where you can, you have a workflow. Where the path depends on what the model decides, you have an agent, and that part needs the most control.
Where agents decide and where controls constrain
Agents are good at work that is ambiguous and language-heavy: reading an issue and working out what it asks for, choosing an approach, editing code, and diagnosing why a check failed. Deterministic controls own everything that needs a repeatable answer: who may trigger a run, which repositories, paths, and tools are in scope, whether an output matches its schema, whether tests and static analysis pass, and whether a person approved a sensitive action. Every gate described in this article exists to keep a decision on the right side of that line.
How agentic pipelines connect agents, tools, and checkpoints
Five building blocks do the connecting.
Orchestration. The control plane. It runs stages in order, enforces timeouts and retry limits, and decides what happens when a gate fails. It can be your CI system, a workflow engine, or an agent framework. What matters is that routing depends on structured results, such as a gate status, and never on an agent’s claim that it succeeded. Keep safety-relevant rules in code or workflow definitions, not in a prompt, because an orchestrator that is itself a model can be talked out of its own rules.
Tool access. Tools are how an agent touches the world: the repository, the issue tracker, a shell, a package manager, a test runner, an analysis service. Expose them through narrow interfaces, whether internal APIs or Model Context Protocol (MCP) servers, with credentials scoped per stage. The tool list is the permission model. A stage with no deploy tool cannot deploy.
Shared state. There are two kinds. The workspace is the branch and working tree where changes happen, ideally in a disposable sandbox. The pipeline state is a structured record of the task: the spec, the plan, a reference to the diff, test and analysis results, and decisions. Keep state outside the model’s context and pass references, such as a commit SHA, instead of pasted content. A stage that crashes can then restart without redoing earlier work.
Handoffs. The contract between stages. A handoff has a schema, and the receiving stage validates it before doing anything else. A plan that names files outside the allowed scope is rejected, not interpreted. Strict handoffs keep a six-stage pipeline from turning into a game of telephone.
Execution records. An append-only log of what happened: the agent and model version, prompt and tool versions, inputs and outputs, every tool call with its parameters, gate results, approvals, timing, and cost. If you cannot reconstruct why a change was made, you cannot audit it, debug it, or trust it.
A running example: from issue to merge
Follow one change through the pipeline. A user reports that the orders API returns duplicate items at page boundaries. The pipeline picks up the issue and works through six stages. Agents act in the first three, the pipeline itself runs testing and independent verification, and a person decides at review. A gate sits after each stage. A gate is deterministic code or a human decision that decides whether the work moves on.
When verification fails at stage 5, the findings go back to stage 3 for a bounded repair attempt. The patterns section below covers that loop.
Where quality gates and approvals belong
Put a gate where the cost of being wrong is about to rise, and make sure the thing being checked cannot bypass it. In practice that gives three groups of controls.
Before execution: validate inputs and permissions
Admission checks are cheap and stop the most expensive mistakes. Confirm who or what triggered the run and whether it is allowed to. Validate the input against a schema and a size limit. Check that the target repository, paths, and tools are in scope, and that budget remains for the run.
Meta’s Agents Rule of Two is a useful design check here. It says that, until prompt injection can be reliably detected and refused, an agent should satisfy no more than two of three properties in a session: it processes untrustworthy input, it has access to sensitive systems or private data, and it can change state or communicate externally. An agent that needs all three should not run autonomously and needs supervision, such as human approval. In the running example, the intake agent reads untrusted text, so it gets no secrets and no write access. A deploy step touches sensitive systems and changes state, so it never consumes raw issue text and waits for a person.
After changes, before merge: tests and independent code checks
This is the main quality gate. Run the test suite, then run code analysis from a system that did not produce the code. The analysis should cover bugs, security vulnerabilities, secrets, risky new dependencies, duplication, and test coverage on the lines the agent changed. Return the verdict as a machine-readable pass or fail so the orchestrator can route on it, and return findings in a structured form so an executor can act on them.
Agents add a risk that human changes carry less often: they pull in dependencies on their own, including packages that are hallucinated, typosquatted, or vulnerable. SonarQube Server’s “Sonar way for agentic AI” quality gate shows what a standard built for agent output can look like. It sets six conditions on new code: no new reliability issues, no new security issues, no new maintainability issues of medium severity or higher, no new dependency risks, at least 80% coverage, and no more than 3% duplication. The dependency-risk condition needs SonarQube Advanced Security. Without it, the gate skips that condition. Because the conditions apply to new code, the verdict describes the change the agent made, not the history of the repository.
Independent verification in practice. Independent means the check runs outside the agent’s control, uses its own methodology, and applies the same standard to agent code as to human code. SonarQube can fill that role. It analyzes the change on the pull request and reports a quality gate result that can be set as a required status check on supported code hosts such as GitHub, GitLab, Bitbucket, and Azure DevOps. Findings carry the file, line, and rule, so an executor can act on them. Agents can also call it while they work, through the SonarQube MCP server or CLI, so issues can be fixed before the pull request opens. Sonar’s role here is verification, not orchestration. Whatever runs your pipeline, the verifier should sit outside it.
Before sensitive actions: require risk-based human approval
Some actions should never rest on automated checks alone: deploying to production, merging into a protected branch, changing pipeline or gate configuration, rotating credentials, writing to production data, or using any privileged tool. Tie the level of approval to the risk of the change. Four factors set the tier: blast radius, reversibility, data sensitivity, and the privilege involved.
Approval design matters as much as approval policy. Bind each approval to a specific commit and void it when a new commit arrives. Show the approver the raw diff and the gate results, not the agent’s summary. OWASP’s Top 10 for Agentic Applications lists human-agent trust exploitation as a risk for this reason: an approval is only as good as what the approver is shown. Keep approvals rare enough that reviewers stay attentive, and never let an agent approve or merge its own change.
When a gate fails: stop, route, or retry
Decide the response to each kind of failure in advance.
Two details keep the retry path from becoming a hazard. First, the agent must not be able to edit the thing that judges it. Test files, CI configuration, and gate definitions belong in protected paths. Researchers at METR have documented frontier models exploiting bugs in scoring code or subverting a task’s setup to get a high score instead of solving the problem. A coding agent that can edit its own tests is in the same position. Second, open-ended retries give an agent time to find whatever turns the check green, including weakening the test. Cap attempts, and require each attempt to make progress, for example by returning fewer findings than the one before.
Common implementation patterns in software teams
Four patterns cover most of what teams build first. They combine well, and each one uses the same gates described above.
Sequential pipelines for bounded tasks
Each stage’s output becomes the next stage’s input, with a gate in between. Anthropic calls this prompt chaining. It suits tasks with a clear shape and a clear definition of done: dependency updates, deprecated-API migrations, test generation for one module, or fixing a failing build. A failure points to a stage, so the pipeline is easy to debug, and cost is predictable. Start here.
Parallel agents with controlled aggregation
Parallelism helps when subtasks are independent, such as one change per service, or when you want several candidate solutions to one problem. Give each agent its own branch or worktree and its own credentials. Aggregate with deterministic code, not with another agent summarizing the results. Each result must pass its own gates before aggregation, and the combined result must pass them again, because changes that pass separately can fail together. When choosing between candidates, let tests and analysis pick the winner instead of a model’s preference. Parallel runs multiply both cost and the surface for failure, so add them after the sequential version is stable.
Planner, executor, and verifier with bounded repair loops
This pattern separates three roles. The planner reads the code and decides the approach, with read-only access. The executor edits code in a sandbox. The verifier runs checks the executor cannot influence and returns structured findings. If verification fails, the findings go back to the executor for another attempt. The loop has three exits: a pass opens a pull request, a limit hit hands a person the attempt history, and a policy violation stops the run and alerts the owner.
The loop needs hard limits: a maximum number of attempts, a time and token budget, and a progress rule that ends the loop when findings stop decreasing. Give the executor fast feedback inside the loop and keep the authoritative check outside it. Calling analysis from within the agent’s session, through an MCP server or CLI, lets the executor correct itself early, while the pipeline’s own gate on the pull request still decides. One is feedback and the other is the gate. Sonar’s Agent Centric Development Cycle describes the same two checkpoints: one inside the agent’s loop as code is written, and one at sandbox exit before the pull request opens.
Agent-generated pull requests inside existing CI/CD and review
The lowest-risk way to start is to give the agent exactly one write path: opening a pull request from a task branch. Everything after that is your existing process. Branch protection, required status checks, code owners, and required reviews apply to the agent’s pull request as they do to anyone’s. Label it as agent-authored, link it to the execution record, and run the same analysis gate you run on human changes, or a stricter one. Treat the agent as a new contributor with no merge rights. You need no new delivery infrastructure to try this, and every earlier control still applies.
How to avoid brittle or unsafe agentic pipelines
Most failures trace back to a short list of causes. Each one can be designed out.
Type the handoffs
Free-text handoffs drift. Define each stage’s inputs and outputs as typed objects, validate them against a schema, and reject anything malformed instead of repairing it silently. Write the contract down: what the producer guarantees and what the consumer assumes. Validate meaning as well as shape. A plan that lists a file that does not exist, or one outside the allowed scope, should fail even when the JSON is valid. The example below shows a handoff from planning to code changes.
The orchestrator enforces the limits. The agent cannot edit them.
Give each stage least privilege, inside a sandbox
Use a separate identity for each stage, with short-lived, narrowly scoped credentials. Planners read. Executors write to one branch. Nothing in the code-change environment holds production credentials, and nothing an agent can reach can edit branch protection, pipeline configuration, or gate definitions. Run executors in ephemeral sandboxes with resource limits and an egress allow-list, so a compromised or confused run cannot reach anything that matters. The OWASP Top 10 for Agentic Applications ties several of its risks to this area, including tool misuse, identity and privilege abuse, and unexpected code execution.
Treat everything the agent reads as untrusted
Issue text, comments, READMEs, dependency documentation, web pages, and tool output can all carry instructions. In May 2025, Invariant Labs showed that a malicious issue in a public repository could hijack an agent connected to the GitHub MCP server and coerce it into pulling private repository data into a public pull request. The cause was architectural: untrusted text, private data, and a way to write publicly all sat in one session. OWASP lists the general class as agent goal hijack.
Do not rely on the model to refuse. Meta describes prompt injection as a fundamental, unsolved weakness in LLMs, so design the pipeline so that a successful injection has little to work with. Limit what each stage can do regardless of what it reads. Pass later stages typed fields instead of raw text. Size-limit tool output. Pin and review MCP servers and other tool providers the way you review dependencies.
Bound everything and make actions safe to repeat
Set limits on attempts, wall-clock time, tokens, and cost for each stage and for the whole run, and add a circuit breaker that halts a run that exceeds them. Separate transient errors, which merit a retry with backoff, from semantic failures, which do not. Watch for oscillation, where an agent keeps undoing its own fix.
Plan for duplicates and crashes. Give side effects idempotency keys, so that creating a pull request, posting a comment, or triggering a deployment is safe to run twice. Derive branch and pull request names from the task ID so a retry finds the existing one. Checkpoint pipeline state after every stage so a crashed run resumes instead of restarting. Keep recovery tools ready: compensating actions such as reverting a merge or closing a pull request, a dead-letter queue with an owner for stuck runs, and a kill switch that halts all agent runs.
Do not let an agent grade its own work
An agent that reviews its own change shares its context, its assumptions, and its blind spots, and it has every reason to agree with itself. Engineering organizations already separate authors from approvers for this reason. The same separation of duties applies to agents.
Independent verification has three properties. The check runs in a system the agent does not control. It uses a different method from the one that produced the code. It holds agent code to the same standard as human code. Deterministic analysis meets all three and adds a fourth: the same code gets the same verdict every time, so a failure can be reproduced and a pass can be trusted. A second model reviewing the first can be a valuable extra layer, because it can catch logic errors that rules cannot, but its verdicts are probabilistic. Make deterministic checks the floor and add AI review on top. Sonar’s approach follows that order, with deterministic analysis in SonarQube first and AI-native review from Gitar as an added layer.
Measure failures, cost, latency, and output quality
A pipeline you cannot measure is a pipeline you cannot improve. Track failures by stage and gate, first-pass gate rate, retries per task, escalation rate, reviewer acceptance and revert rates, cost per merged change, latency per stage, and defects found after merge. Watch overrides too, since every change promoted despite a failing gate is a signal. SonarQube Server’s quality gate adherence dashboard, for example, shows how often main-branch releases pass or fail the gate and highlights risky releases, where code shipped despite a failing gate. Keep a regression set of past tasks and re-run it whenever you change a model, a prompt, or a tool, so you see quality shifts before your users do.
Practical implementation checklist
Start smaller than feels necessary. A pipeline that handles one task type well teaches you more than a general one that handles ten badly.
Start with one bounded use case
- Pick one task type. Choose work that is frequent, well specified, easy to verify, and cheap to reverse. Fixing failing tests, patch-level dependency updates, and test generation for one module are good first choices.
- Write down what is out of scope. List the protected paths, systems, and actions the agent must never touch, and enforce the list in code.
Define success criteria and owners
- Set measurable targets. For example: first-pass gate rate, reviewer acceptance rate, cost per merged change, and zero protected-path violations.
- Name the owners. Assign an owner for the pipeline, an on-call contact, and approvers for each risk tier.
Add gates and observability before autonomy
- Put the controls in place. Admission checks, typed handoffs, and scoped identities come first. Run execution in a sandbox with an egress allow-list and no production credentials.
- Make independent verification a required check. Run it on every agent pull request, with the quality gate you apply to human changes or a stricter one.
- Set limits and recovery. Configure retry, timeout, and cost limits, make side effects idempotent, and confirm that the kill switch works.
- Instrument the pipeline. Capture execution records and dashboards for failures, cost, latency, and output quality.
Expand only after evaluation
- Run in shadow mode first. Let the agent propose while people act, and compare its output with what the team did.
- Move to agent-authored pull requests with required review. Consider auto-merge for the lowest risk tier only when gate and review data support it.
- Re-run your regression set. Do it after every model, prompt, or tool change.
Agents will keep getting better at writing code, which raises the stakes on everything around them. The teams that scale agentic delivery will be the ones whose pipelines can show, for any merged change, what the agent was asked to do, what it was allowed to touch, which independent checks it passed, and who approved it. Start with one bounded use case, put gates around it, and let the evidence decide how far to go.
Next steps
Verify agent code before you scale it. See how the quality gate for agentic AI works in SonarQube Server, and how it fits the Verify stage of Sonar’s Agent Centric Development Cycle.
Give agents feedback inside the loop. Connect agents to the SonarQube MCP server or CLI so issues can be fixed before the pull request opens, then keep the pull request gate as the check that decides.