Cubyts Governance Agents
Cubyts Governance Agents continuously evaluate software delivery and engineering activities against configured rules, context, dependencies, and governance requirements. Each agent is designed for a specific governance scenario and can be configured to run on a schedule or respond automatically to changes in development activity.
This guide provides an overview of the available Governance Agents, their intended users, purpose, trigger conditions, configuration, and outputs. The information below is based on the Cubyts Governance Agents reference document.
1. ADR Drift Auditor
Who should use it?
Engineering leads
What does it do?
The ADR Drift Auditor detects when code changes deviate from architectural decisions documented in Architectural Decision Records (ADRs).
It compares merged code changes with the ADRs associated with the corresponding work items, helping engineering teams identify cases where implementation has drifted from an approved architectural decision.
When does it run?
The agent runs based on the user-configured schedule.
Configuration
The agent requires the following configuration:
Scheduler — Defines when the agent runs.
Target audience — Defines who can view the agent output.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
The agent:
Extracts every PR merged with the configured main/master branch.
Identifies the ADRs mapped to each PR through the associated work items in the planning tool.
Compares the ADRs with the corresponding merged PRs.
Identifies and describes architectural drift.
Produces a comprehensive drift report.
Deep dive
See the ADR Drift Auditor detailed guide.
2. Build Candidate Recommender
Who should use it?
Scrum masters
Engineering managers
Engineering leads
What does it do?
The Build Candidate Recommender evaluates aged backlog items using factors such as age, priority, readiness, and dependency pressure.
It identifies the strongest candidates for consideration in the next sprint and highlights high-value items that may only be blocked because their definition or specification is incomplete.
When does it run?
The agent runs automatically based on the configured Planning Lead Time.
It triggers N days before the next sprint is scheduled to begin, where N is the configured planning lead time.
Configuration
The agent supports the following configuration:
Planning lead time — Defines how many days before the next sprint the agent should run.
Backlog aging threshold — Defines when a work item is considered aged.
Number of candidates — Defines how many recommendations the agent should surface.
Work item types — Defines the types to include or ignore.
Work item labels — Defines the labels to include or ignore.
Specification-to-work-item links — Used to determine whether work items are sufficiently ready for a future sprint.
Target audience — Defines who can view the output.
Planning-tool integrations — Jira or ADO.
What does it produce?
The agent:
Extracts backlog work items according to the configured criteria.
Evaluates whether each work item is ready to be considered for the next sprint.
Considers the configured readiness and prioritization context.
Produces a final list of potential build candidates for the next sprint.
The recommendations can then be used by the Scrum Master or Engineering Lead during sprint planning.
Deep dive
See the Build Candidate Recommender detailed guide.
3. Code Area Impact Analyzer
Who should use it?
Engineering managers
Engineering leads
What does it do?
The Code Area Impact Analyzer periodically analyzes the impact of code changes across workspace artifacts such as Features, Work Items, and PRs.
It identifies mapped code areas and analyzes their dependencies and dependents, providing engineering teams with visibility into the potential downstream impact of code changes.
When does it run?
The agent runs according to a user-defined schedule.
Configuration
The agent supports the following configuration:
Scheduler — Defines when the analysis runs.
Data source — Selects whether to analyze:
Open PRs
Merged PRs
Both
Work item types — Defines the work item types to analyze.
Target audience — Defines who receives or can view the output.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
The agent:
Extracts PRs according to the configured data source.
Uses the Cubyts graph to identify the work items mapped to those PRs.
Uses the graph to identify the domains, code areas, and common code areas associated with the PRs for each work item.
Maps the affected code areas.
Analyzes dependencies and dependents associated with those areas.
Provides an impact view that helps engineering teams understand downstream dependencies of code changes.
This can help teams identify dependencies beyond the immediate feature or work item, including areas such as automation and DevOps.
Deep dive
Detailed documentation is currently coming soon.
4. Code Dependency Risk Checker
Who should use it?
Engineering leads
Engineers
What does it do?
The Code Dependency Risk Checker analyzes code changes in a branch or PR to determine whether those changes could introduce dependency risks.
The agent focuses particularly on interactions between the current changes and changes being developed in other open PRs.
When does it run?
The agent runs automatically based on commits in a PR.
Configuration
The agent requires:
Target audience — Defines who can view the output.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
The agent:
Analyzes the changes introduced by a commit using the commit diff.
Checks whether the changes in the PR could affect changes being made in other open PRs.
Highlights potential impacts when such relationships are identified.
This provides engineers with an additional view of cross-PR dependency risk before changes are merged.
Deep dive
Detailed documentation is currently coming soon.
5. Code Reviewer
Who should use it?
Engineering leads
Engineers
What does it do?
The Code Reviewer continuously evaluates code changes against configured code-quality, security, and coding-standard guardrails.
It supports automated review of changes in PRs or branches and provides actionable findings to engineers during development.
When does it run?
The agent runs automatically when a commit is added to a configured PR or branch.
Configuration
The agent supports detailed review configuration:
Code-quality guardrails — Defines code-quality evaluation criteria.
Code-security guardrails — Defines security evaluation criteria.
Custom guardrails — Allows additional review criteria to be configured.
Relevant work item types — Defines which work items should be considered.
Analysis target — Select PRs, branches, or both.
Agent selection — Defines the agent configuration to use for the PR or branch.
Severity level — Defines the severity level used for analysis.
Analysis depth — Controls how strictly the agent evaluates findings. For example, strict analysis can be used to leave borderline cases unresolved.
Repository integration — Allows findings to be posted as PR comments.
Target audience — Defines who can view the output.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
When a commit is detected:
The agent extracts the changes introduced by the commit.
It analyzes those changes against the configured guardrails.
Findings are made available to the engineer through the Cubyts VS Code plugin for immediate resolution.
Findings are also sent to GitHub, GitLab, or Bitbucket as PR comments.
This allows engineers to identify and resolve issues directly within their development workflow.
Deep dive
See the Code Reviewer detailed guide.
6. Code Vulnerability Checker
Who should use it?
Engineering leads
Engineers
What does it do?
The Code Vulnerability Checker identifies vulnerabilities in open-source dependencies used by projects in configured Git repositories.
The analysis is based on vulnerabilities recorded in the National Vulnerability Database (NVD).
When does it run?
The agent runs according to the configuration in the workspace scheduler.
Configuration
The agent requires:
Target audience — Defines who can view the output.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
The agent:
Extracts the dependencies used by projects in the configured Git repositories.
Uses Trivy, an open-source vulnerability scanner, to check the dependencies for known vulnerabilities.
Evaluates vulnerabilities based on entries in the National Vulnerability Database.
Lists identified vulnerabilities by open-source dependency.
Provides the results for engineering teams to analyze and remediate.
Deep dive
Detailed documentation is currently coming soon.
7. Customer Defect Ranker
Who should use it?
Scrum masters
Engineering managers
Engineering leads
What does it do?
The Customer Defect Ranker helps teams prioritize customer-reported issues for the bug-fixing capacity reserved in each sprint.
It identifies the customer issues that are the best fit for the available bug capacity and can estimate unsized issues to support triage.
When does it run?
The agent runs according to a user-configured schedule.
Configuration
The agent supports the following configuration:
Scheduler — Defines when the agent runs.
Bug-fix budget — Defines the number of hours reserved for bug fixes.
Scoring prompts — Allows additional prompts to influence the agent's judgment.
Target audience — Defines who can view the output.
Customer-support integrations — Freshdesk, Zendesk, Jira Service Management, or Jira.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
The agent:
Extracts open customer defects.
Evaluates the defects using the configured parameters.
Identifies the triaged set of issues that the team should focus on.
Produces the prioritized list for sprint bug capacity planning.
Deep dive
See the Customer Defect Ranker detailed guide.
8. Dev Prompt Builder
Who should use it?
Engineering managers
Engineering leads
Engineers
What does it do?
The Dev Prompt Builder generates a context-grounded development prompt for engineers.
It brings together context from linked specifications, related tickets, previous PRs, and curated code maps to create a development brief that can be used as a starting point with coding tools.
When does it run?
The agent is triggered when a work item in an active sprint changes its status to In Progress.
Configuration
The agent supports:
Brainstorming level — Defines the depth of ideation and analysis.
Relevant work item types — Defines which work items should be analyzed.
Work item comment — Allows the generated brief to be posted as a comment on the work item.
Target audience — Defines who can view the output.
Planning-tool integrations — Jira or ADO.
Coding-tool integrations — GitHub, GitLab, or Bitbucket.
What does it produce?
The agent:
Identifies the relevant work item and its available attributes.
Extracts associated context such as:
Description
ADRs
Specifications
Other relevant linked information
Generates baseline ideation prompts for the engineer.
Produces a context-grounded development prompt that can be used with coding tools such as Claude Code and Cursor.
Optionally posts the generated brief as a work item comment.
The generated prompt serves as a baseline for engineering ideation and code-generation workflows.
Deep dive
See the Dev Prompt Builder detailed guide.
Governance Agents at a Glance
Choosing the Right Governance Agent
Use the following guidance to identify the agent most relevant to a governance requirement:
For architecture governance
Use ADR Drift Auditor when the objective is to verify that implemented code continues to align with documented architectural decisions.
For sprint planning
Use Build Candidate Recommender when the objective is to identify backlog items that are strong candidates for the upcoming sprint.
For change-impact analysis
Use Code Area Impact Analyzer when the objective is to understand which code areas and dependent areas may be affected by changes.
For cross-PR dependency risks
Use Code Dependency Risk Checker when engineers need to understand whether changes in one PR could affect changes being developed in other open PRs.
For automated code review
Use Code Reviewer when the objective is to continuously evaluate code against quality, security, and coding-standard guardrails.
For open-source dependency vulnerabilities
Use Code Vulnerability Checker when the objective is to identify vulnerabilities in project dependencies.
For customer defect prioritization
Use Customer Defect Ranker when the team needs to select the most appropriate customer defects for the bug-fixing capacity available in a sprint.
For development-context generation
Use Dev Prompt Builder when engineers need a context-grounded development brief derived from the work item's specifications, related tickets, ADRs, previous PRs, and code context.
Common Configuration Concepts
Several configuration concepts recur across the Governance Agents.
Scheduler
Defines when a scheduled agent runs. This is used by agents such as the ADR Drift Auditor, Code Area Impact Analyzer, Customer Defect Ranker, and Code Vulnerability Checker.
Target Audience
Defines the users who can view the output generated by an agent.
Planning-tool Integration
Governance Agents can integrate with planning systems such as:
Jira
ADO
Coding-tool Integration
Agents that analyze code can integrate with:
GitHub
GitLab
Bitbucket
Work Item Configuration
Several agents allow administrators to define which work item types or labels should be considered or ignored during analysis.
Agent Output
Depending on the agent, output may be delivered as reports, recommendations, vulnerability lists, impact analysis, IDE feedback, PR comments, or work-item comments.
Agent Trigger Types
Governance Agents use different trigger models depending on the nature of the governance activity.
Scheduled triggers
The agent runs at a configured time or according to a configured schedule.
Planning-event triggers
The agent responds to a planning event, such as a work item entering In Progress.
Code-event triggers
The agent responds to development activity such as a commit being added to a PR or branch.
Planning lead-time triggers
The agent runs a defined number of days before a planned event, such as the start of the next sprint.
Choosing the appropriate trigger ensures that governance feedback is generated at the point where it is most useful to the delivery or engineering team.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article