Inspiration

Software teams lose a surprising amount of time not because work is missing, but because signal is scattered across issues, merge requests, code review threads, and failing CI/CD pipelines. GitLab already contains the full operational story of a team, but engineering managers still spend too much time jumping between tabs, summarizing context, chasing blockers, and turning raw repository activity into decisions.

GitLab Engineering Manager Agent was created to act like an AI engineering manager that sits on top of GitLab activity and helps technical teams move faster. Instead of only answering questions, the agent reads GitLab context, identifies what matters, explains what went wrong in pipelines, drafts follow-up issues, and generates release-oriented summaries using GitLab MCP and Gemini on Google Cloud.

What it does

GitLab Engineering Manager Agent monitors and analyzes GitLab issues, merge requests, and pipelines, then turns that raw activity into actionable outputs for a technical team.

Key capabilities include:

Triaging issues by identifying likely priority, missing details, and suggested next actions.

Reviewing merge requests and summarizing what changed, what risks exist, and what reviewers should focus on.

Inspecting failed CI/CD pipelines and explaining probable causes in plain language so teams can debug faster.

Drafting follow-up work items or bug reports based on merge request discussions and pipeline failures.

Generating release summaries from recent development activity to help teams communicate progress clearly.

The goal is to reduce management overhead and let engineering teams spend less time coordinating and more time shipping.

How we built it

The project was built with Google Agent Builder / Gemini Enterprise Agent Platform as the orchestration layer for the agent workflow and reasoning engine. The agent uses Gemini for decision-making, summarization, and multi-step planning across GitLab workflows.

For GitLab integration, the project uses a GitLab MCP server so the agent can interact with GitLab resources as tools rather than treating GitLab as plain text context. This allows the agent to inspect issues, merge requests, and pipelines, and then perform useful actions like drafting work items and producing structured summaries.

The implementation focused on a practical agent loop:

Read relevant GitLab context.

Analyze repository state with Gemini.

Identify blockers, failures, or missing follow-up work.

Produce actionable engineering outputs for the team.

This made the project feel less like a chatbot and more like a working operational assistant.

Challenges we ran into

One of the biggest challenges was designing the agent so it felt genuinely agentic instead of just a Q&A wrapper around GitLab data. The project needed to show clear multi-step behavior: inspect context, reason over it, and produce concrete outputs such as triage decisions, failure explanations, and drafted follow-up work.

Another challenge was turning noisy GitLab activity into useful management signals. Merge requests, issue threads, and pipeline failures often contain fragmented technical details, so the agent had to be guided carefully through instructions and tool usage to produce outputs that are concise, reliable, and relevant to real engineering workflows.

A further challenge was keeping the project scoped correctly for a hackathon. Rather than trying to automate an entire software organization, the implementation focused on a few high-value workflows that could be demonstrated clearly in a short demo.

Accomplishments that we're proud of

The strongest accomplishment is building an agent that goes beyond conversation and actually supports engineering execution through GitLab workflows. The project demonstrates a meaningful partner integration and a realistic use case that technical teams can immediately understand.

The project is also strong because it is easy to demo: a failed pipeline can be analyzed, a merge request can be summarized, and a follow-up issue can be drafted in a short, compelling flow. That makes the value of the agent visible very quickly, which is important in a hackathon setting.

What we learned

The biggest lesson was that good agents need more than a strong model — they need the right tools, the right scope, and carefully designed instructions. Gemini provides the reasoning layer, but the real usefulness comes from connecting that reasoning to meaningful GitLab actions through MCP.

Another lesson was that the best hackathon agents solve a very specific workflow well. A narrow, high-confidence workflow such as pipeline failure analysis or merge request triage creates a better product and a better demo than trying to solve every engineering problem at once.

What's next for GitLab Engineering Manager Agent

The next step is to turn the project from a hackathon prototype into a more autonomous engineering operations assistant.

Planned improvements include:

Automatic daily engineering standup summaries from recent GitLab activity.

Smarter risk scoring for merge requests and production-sensitive changes.

Better pipeline debugging flows using CI/CD job context and historical failure patterns.

Team-level release digest generation across multiple repositories and milestones.

Approval-aware action flows so the agent can suggest or draft changes while keeping humans in control.

The long-term vision is an AI teammate that helps engineering leaders stay on top of execution without getting buried in operational noise.

Built With

Share this project:

Updates