Orbit AI Engineering Manager

Inspiration

I've worked with engineering teams where the manager spent more time chasing people on Slack than actually managing. "Hey, can you review this MR?" "Is this issue still blocked?" "How are we tracking against the sprint?" — the same questions, every day, manually.

The problem isn't that managers don't care. It's that the information they need is scattered across dozens of GitLab pages, and pulling it together takes 30 minutes every morning before they can make a single decision. When I saw the Orbit lifecycle context graph in the hackathon brief — a single graph connecting developers, commits, files, MRs, and issues — I knew this was the right foundation. Not another dashboard. An agent that actually acts.

What it does

Orbit AI Engineering Manager is a 4-agent GitLab Duo flow that handles engineering coordination autonomously:

• Detects stalled MRs and assigns the optimal reviewer using the Orbit graph — based on file expertise (who has committed to these files before) and current review load, not just availability
• Calculates workload scores per developer and flags imbalances — overloaded developers get reassignment suggestions, available developers get matched to issues by expertise
• Escalates blocked issues with targeted comments to the responsible party, and escalates to maintainers if the first ping is ignored
• Predicts sprint completion using daily velocity: predicted% = (closed + velocity × days_remaining) / total × 100
• Generates sprint retrospectives automatically at milestone close — velocity trends, MR review times, pipeline health, team contributions, all backed by real data

Also includes a Daily Health Check flow (lightweight morning standup summary) and five slash command skills: /stall-detector, /workload-balancer, /blocker-escalator, /retrospective-generator, /sprint-predictor.

How we built it

The core is a 4-agent sequential flow on the GitLab Duo Agent Platform:

1. Context Collector — queries the Orbit context graph first, then fills gaps with GitLab APIs. One query_graph call replaces ~12 individual API calls to get the full picture of MRs, issues, members, and pipelines.
2. Health Analyzer — reads the snapshot from conversation history and runs stall detection, workload analysis, blocker identification, and sprint velocity prediction.
3. Action Executor — assigns reviewers, posts escalation comments, creates the workload suggestion issue, and logs every action taken.
4. Report Generator — reads the full conversation history across all three agents and creates a structured Engineering Manager Report issue with sprint health score, actions taken, and items needing human decision.

All flows are published to the GitLab AI Catalog as public flows, with two additional flows and five skills on top of the main orchestration.

Challenges we ran into

Undocumented schema fields. GitLab's flow YAML requires specific field names (prompt_id not id, prompt_template not parameters, entry_point not entry) that aren't clearly documented. Discovered through trial and error by reading the UI template carefully.

Inter-agent data passing. You cannot reference another agent's output directly — from: component:name.output is not a valid source. Everything must flow through conversation_history. This forced explicit prompt design where each agent tells the next one exactly where to find its input.

Unicode corruption. Em dashes in YAML got silently corrupted to ??? in GitLab's flow editor. The YAML looked valid but wasn't. Fixed by replacing all em dashes with regular hyphens before pasting.

Wrong trigger handle. When a flow is enabled, GitLab creates a service account with its own username. You mention that account to trigger the flow — not @GitLabDuo. Found this after the flow was live and sessions weren't appearing.

Accomplishments that we're proud of

The reviewer assignment logic is genuinely intelligent. Most tools flag a stalled MR and stop there. Ours traverses the Orbit graph — developer → commits → files → MR — to find someone with actual expertise in the changed files, checks their current review load against the team average, and explains the reasoning in the comment it posts. That's the kind of decision an experienced engineering manager makes. Getting an agent to do it reliably felt like a real milestone.

Publishing three working flows and five skills to the GitLab AI Catalog, all validated by CI, also felt solid — it's a complete, deployable system, not just a demo.

What we learned

Multi-agent coordination requires more than splitting work across agents. Each agent needs to know exactly what the previous one wrote and where to find it. The prompts do more coordination work than the YAML does — explicit instructions like "the previous agent's output is in your conversation history, read it and build on it" are what make the pipeline actually work.

The Orbit graph also changed how I think about LLM tool use. When you replace 12 API calls with one query_graph call, you're not just saving tokens — you're giving the agent a relational view of the data it can reason about as a whole rather than assembling piecemeal. That's a qualitatively different input.

What's next for Orbit AI Engineering Manager

• Slack/Teams integration — post the daily standup summary outside GitLab where the team already lives
• Configurable thresholds via CI/CD variables — let teams set their own stall time, overload multiplier, and escalation delay
• Cross-project view — a single flow that spans multiple repos for engineering managers overseeing a portfolio
• Preference learning — if a manager overrides a reviewer suggestion, remember that preference and factor it into future recommendations
• MR complexity scoring — weight reviewer assignment by MR size and changed file complexity, not just file overlap count

Built With

• gitlab-ai-catalog
• gitlab-ci/cd
• gitlab-duo-agent-platform
• gitlab-flows-(yaml)
• gitlab-orbit-context-graph
• gitlab-rest-api
• python-(ci-validation)
• yaml