Owner Ping - Ownership Intelligence Agent

Ownership Intelligence Agent automatically routes GitLab issues to the right owner using Orbit codebase context, reducing triage time and improving issue resolution.

Comment

Inspiration

When a new issue gets filed on a fast-moving project, it's often unclear who should pick it up. Manually figuring out the right owner wastes time and slows down response, especially as teams and codebases grow. I wanted to remove that guesswork using GitLab's own codebase context.

What it does

Owner Ping is an Ownership Intelligence Agent built on GitLab's Duo Agent Platform. When a new issue is created, it automatically reads the issue, uses GitLab Orbit's codebase context to identify the likely affected files or modules, determines the most probable code owner, and rates its own confidence (High, Medium, or Low), based on how clearly the issue points to a specific area. If no strong owner can be identified, it honestly flags the issue for escalation to a team maintainer instead of guessing.

How we built it

I built Owner Ping using three layers of GitLab's Duo Agent Platform: a custom skill (owner-ping/SKILL.md) defining the reasoning logic, a custom agent configured with GitLab Orbit's knowledge graph tools (Get Graph Schema, Get Graph Status, Invoke Command, List Commands), and a custom flow connecting a "Work item created" trigger to the agent. The flow fetches issue content via the get_issue tool, reasons about the affected code area and confidence level, and posts a comment via create_issue_note. I iterated on the prompt design specifically to keep responses concise and to ensure the agent states an honest confidence level rather than presenting unsupported certainty.

Challenges we ran into

Getting the flow's YAML schema exactly right took several iterations , fields like unit_primitives and the correct structure for prompt_template weren't immediately obvious from the initial template, and required cross-referencing GitLab's example flows to get right. I also discovered that the "Work item created" trigger only passes the issue's ID by default, not its actual content, so the flow needed to be updated to explicitly fetch the issue via the get_issue tool using the project and issue IDs before any reasoning could happen. Branch protection on the default branch also required understanding how GitLab's Duo Agent Platform service accounts interact with repository permissions.

Accomplishments that we're proud of

Getting a fully working, end-to-end automation, trigger, agent, skill, and flow all communicating correctly, built and tested. I'm also proud of the agent's honesty: rather than always forcing a confident answer, it transparently escalates when there isn't enough evidence to name a clear owner, which is a more trustworthy behavior than blindly guessing.

What we learned

I learned how GitLab's Duo Agent Platform separates concerns between skills (reasoning instructions), agents (tool access and identity), and flows (triggers and orchestration), and how all three need to be aligned for a project to actually function end-to-end. I also learned the practical value of testing early and often: small issues like a missing schema field or a misrouted context variable were only caught by creating real test issues and reading the session logs closely.

What's next for Owner Ping - Ownership Intelligence Agent

Future iterations could extend Owner Ping to merge requests, incorporate additional Orbit signals like code ownership files and merge request review history for richer confidence assessment, and add lightweight feedback tracking so suggestions improve over time based on whether they were accepted.

Built With

  • create-issue-note)
  • gitlab-custom-agents
  • gitlab-custom-flows
  • gitlab-custom-skills
  • gitlab-duo-agent-platform
  • gitlab-issue-api-(get-issue
  • gitlab-orbit
  • gitlab-orbit-knowledge-graph
  • markdown
  • yaml
Share this project:

Updates