Inspiration

Writing code got fast. Everything after it did not. Someone still has to decide who reviews a merge request, read a long job log to find why the pipeline went red, and judge whether a release is safe to ship. Most "autonomous" tools answer by giving an agent a shell and hoping. We wanted the opposite: agents that do the tedious evidence-gathering and the bounded fixes, and a human who makes the decisions that can hurt.

What it does

Hive is an agentic DevOps system with two loops. The recovery loop collects evidence on a failure, forms a hypothesis, picks an action from a fixed catalogue, checks it against a safety policy, and verifies the system recovered. The change loop triages a change, picks its owner and a reviewer who is not the author, and follows it to deploy.

For this hackathon we brought those loops onto GitLab:

  • issue-triage (work item created): classifies the item, rates severity, names owners from CODEOWNERS, and flags likely duplicates.
  • mr-triage (merge request created): rates risk by the paths touched and assigns a reviewer who is not the author.
  • pipeline-doctor (pipeline failed): a read-only agent diagnoses the failure from job logs; a second agent acts from a fixed catalogue: a retry note, a fix MR it never merges, or an incident issue that proposes a rollback.
  • release-gate (merge request approved): writes release notes and a ready or not-ready verdict from the pipeline checks and open vulnerabilities.

Around the flows is a full pipeline: lint, about 2,500 tests, a Docker image per commit, GitLab SAST, secret detection and container scanning, an automatic staging deploy, and a production deploy that runs only when a person starts it. A deploy only counts when the environment's /healthz reports the commit the pipeline built.

How we built it

  • Four GitLab Duo Agent Platform custom flows (.gitlab/duo/flows/), with Duo Code Review instructions that hold reviews to Hive's safety rules.
  • .gitlab-ci.yml with GitLab's SAST, Secret Detection and Container Scanning templates, environment-scoped deploy settings, and a manual production job.
  • scripts/deploy.sh, which triggers the host and then polls /healthz until the new release answers.
  • tests/test_duo_flows.py, which holds every flow to GitLab's custom-flow rules and to Hive's: no shell, no merge, and a diagnosis agent with no write tools.
  • Hive itself: Python 3.12, FastAPI, LangGraph, Postgres, deployed on Render.

Path B: what existed and what is new

Hive existed before the submission period: 296 commits from Aug 20 to Oct 22, 2026 (the agent loops, safety policy, Postgres state machine, integrations, benchmark and dashboard). Everything built for this hackathon is the GitLab layer above, all committed on Oct 27, 2026. One view shows every new change: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/31635560/showcase/-/compare/45562cd...main

Challenges we ran into

  • GitLab's flow validator rejects fields the v1 flow spec documents (for example max_cycles). We encoded the accepted shape in a test so a flow edit cannot regress it.
  • Splitting diagnosis from action, so the agent that reads logs can never also write, took two components and a handoff instead of one agent.
  • Proving a deploy rather than trusting it: a 200 from a deploy hook only means the host accepted the request, so the pipeline waits for the new release to answer.

Accomplishments that we're proud of

  • Agents never merge, never deploy to production, and never weaken a check to go green, and a test enforces it.
  • Every stage of the lifecycle, plan to govern, has a concrete owner in the pipeline or a flow.

What we learned

Bounded agents are more useful than open-ended ones for operations work. A fixed action catalogue and a named human approver make the agent's output something a team can trust and audit.

What's next for Hive

  • Feed GitLab pipeline and deploy events into Hive's own incident store, so the GitLab flows and the Hive service share one history.
  • Measure the flows the way Hive's benchmark measures its loops: time to diagnosis, correct-fix rate, and false escalations.

Built With

Share this project:

Updates