Workflow and Quality Agents
Quality Agents are the controlled stages MergeLoom uses to keep AI coding repeatable before a PR or MR reaches human review.
The goal is simple: stop vague tickets and weak AI output from becoming review work for your engineers.
This Is Configured in Workflow
Open https://controller.mergeloom.ai and go to Workflow.
Quality Agent settings live with intake and workflow rules because they
control what is allowed to move from ticket to implementation to review.
The Agent Workflow
Section titled “The Agent Workflow”MergeLoom does more than generate code. A typical run moves through these stages:
| Stage | What it does | Type |
|---|---|---|
| Ticket intake | Pulls approved work from the configured tracker. | Workflow gate |
| Clarity Agent | Scores whether the ticket is clear enough to run. | Agentic stage |
| Context Engine | Assembles repository rules, organization context, linked docs, related service evidence, and ticket input. | Platform capability |
| Investigation Agent | Runs a focused read-only investigation and produces an implementation brief. | Agentic stage |
| Implementation Agent | Writes the code change against the ticket brief and context. | Agentic stage |
| Validation Gate | Runs configured setup, test, lint, build, or custom validation commands. | Controlled gate |
| Repair Agent | Attempts bounded fixes when validation fails. | Agentic stage |
| Review Agent | Reviews the diff for bugs, missed requirements, and risky changes. | Agentic stage |
| Review Fix and Confirmation | Applies selected review fixes and confirms the issues were addressed. | Agentic stage |
| Diff Guard | Checks review size and flags risky or oversized changes. | Controlled gate |
| Publish PR/MR | Pushes the branch and opens or updates the review request. | Workflow gate |
| Audit | Records stages, tokens, cost estimate, duration, files, tool calls, and line evidence. | Visibility system |
Clarity Agent
Section titled “Clarity Agent”The Clarity Agent checks whether a ticket has enough scope, acceptance criteria, and target context before a worker starts changing code.
Default behavior:
- enabled by default
- default minimum score is
75 - unclear tickets are blocked before implementation
- MergeLoom can comment with what needs clarification
Cloud Hosted can use a configured cloud scoring model. Self Hosted uses the provider/model available through the worker execution path.
Use the extra scoring requirements field for standards that matter to your team, such as:
- acceptance criteria must be explicit
- expected repository must be clear
- test expectation must be stated
- UI changes must include target page or component
- data changes must describe migration and rollback expectations
Investigation Agent
Section titled “Investigation Agent”The Investigation Agent reads before writing. It uses the ticket, repository guidance, and relevant files to produce a focused implementation brief.
Use it when you want:
- less wandering during implementation
- better use of context budget
- a clearer record of why files were touched
- fewer review surprises
Validation and Repair
Section titled “Validation and Repair”Validation commands are configured at repository level. MergeLoom can run setup, tests, lint, build, or custom commands before review.
When validation fails, the Repair Agent can attempt bounded fixes and rerun validation. Keep repair attempts bounded so runs do not loop forever.
Repository validation setup lives in Repository rules, context, and validation.
Review Agent and Diff Guard
Section titled “Review Agent and Diff Guard”The Review Agent gives the AI a second perspective on its own change before a human reviewer sees it.
Diff Guard checks the size and shape of the change. Use it to warn when a PR or MR is larger than your team wants for automated implementation.
Together, they help reviewers spend less time untangling weak output and more time approving or correcting a focused change.
What to Tune First
Section titled “What to Tune First”For a first production workflow:
- Leave Clarity Agent enabled at
75. - Add two or three team-specific clarity requirements.
- Configure repository validation commands.
- Enable Review Agent.
- Enable Diff Guard with a conservative warning threshold.
- Run one real ticket and inspect the audit.
Where Results Appear
Section titled “Where Results Appear”Cloud Hosted:
- live run state appears in Cloud Runtime
- ticket, code, and controller audit appear in Audit
Self Hosted:
- live run state appears in the local worker UI
- Ticket Audit and Code Audit appear in the local worker UI
- controller intake and routing events appear in the customer controller
See Where to find audits.