Kintsugi

mended in gold

Comment

Kintsugi: every break, mended in gold. A user reports a bug in plain words. Agents prove it, mend it, ship it, and show the user the proof.

Path B, Bring Your Own: Coop Call, MIT. Autonomy: Hands-off. Deployed on Google Cloud Run.

Inspiration

Every app breaks, and someone always sees it first. That person writes a support ticket, and the trail goes cold. The engineers fix it weeks later, if they ever reproduce it, and the person who reported it waits in silence.

Coop Call is a web app for small broiler farms in Zimbabwe. Its users are farmers, the people least likely to file a GitHub issue and most likely to give up on a broken page. We wanted the person who saw the bug to get the proof that it is fixed.

The name comes from the Japanese art of mending pottery with gold. The repair stays visible, and the bowl grows more beautiful where it broke. Every bug Kintsugi mends leaves a gold seam: a regression test in the suite and an entry in a public ledger.

What it does

Kintsugi is a closed loop from a user's bug report to a proven fix in production.

  1. Report. Inside the app, a quiet button says Report a problem. The user writes one sentence. The widget attaches a screenshot, console errors, failed requests, the page and the build.
  2. Screen. Kintsugi Desk reads the report as untrusted public text. Hostile reports go to quarantine, where a person reads them first. Clean reports become a GitLab issue, with the user's words fenced as data.
  3. Triage, reproduce, mend. Desk starts kintsugi-mend, a custom flow of three agents. Triage classes severity and risk. Reproduce writes a Playwright test that fails on today's build for the reason the user gave. Mend finds the root cause, fixes it, proves the fix with that same test, and opens a merge request.
  4. Verify and secure. The pipeline runs unit tests, the app build, SAST, secret detection and dependency scanning.
  5. Review app. Each merge request gets a tagged Cloud Run revision pair. The user's steps replay on it, and the after screenshot goes back to the user.
  6. Govern. A policy classes the change by the files it touches. Gold (styles, copy) and silver (app logic) merge on green. Iron (auth, storage, infrastructure) waits for one human approval.
  7. Release. A canary under a release tag, the replay again, traffic shifted, a three-minute production watch with automatic rollback, and a GitLab release.
  8. Close. The issue closes. The next time the user opens the app, a gold toast says Mended, with their screenshot beside the mended screen.

The release gate and a scheduled production watch file their own reports when they see a failure, with the server's stack trace attached, so the same loop mends what monitoring finds.

How we built it

Kintsugi architecture: a bug report in, a proven fix out, through GitLab Duo Agent Platform and Google Cloud

GitLab Duo Agent Platform

  • A custom flow, kintsugi-mend, published to the AI Catalog from YAML in the repository and enabled on the project with its own service account and a Mention trigger.
  • Three AgentComponents with inline prompts and narrow toolsets: get_issue, update_issue, run_command, run_git_command, create_merge_request and file tools.
  • The Flows API starts the flow from Desk, because triggers fire only on human actions and a public report arrives through a service.
  • agent-config.yml runs every flow in our own image: Playwright's official image plus Python, git and the Anthropic Sandbox Runtime, so GitLab's sandbox and a strict network allowlist stay in force.
  • The flow trace API feeds the reporter's status page.

GitLab CI/CD and DevSecOps

  • SAST, secret detection and dependency scanning on every merge request.
  • Environments for review apps and production, deployments tracked per revision.
  • GitLab releases cut by the pipeline after the production watch.
  • A risk policy in .gitlab/kintsugi/policy.yml, enforced by a govern job that sets auto-merge or holds the change for a person.

Google Cloud

  • Cloud Run for Coop Call (API and web), the review apps, the canaries and Kintsugi Desk.
  • Every release is an API and web revision pair under one tag, so promotion and rollback stay consistent.
  • Workload Identity Federation: GitLab's OIDC token becomes a short-lived Google token. The pipeline holds zero service account keys.
  • Its own Firestore database and storage bucket, so agents and canaries work on a copy of the demo coop.
  • Cloud Logging feeds server stack traces into reports.

The nine stages: plan (triage, the issue), create (the mend), verify (tests and the replay), package (images), secure (scans and the report screen), release (canary and GitLab release), configure (environments, Cloud Run, Workload Identity), monitor (production watch and the scheduled check), govern (the risk policy and the audit trail).

The first real loop

Kintsugi's first mend was a real bug it found in its own release. The first release candidate on Cloud Run returned a server error on the demo coop. The release gate stopped it, filed the failure through Desk, and the flow started on its own. Triage traced the empty page to one endpoint. Reproduce proved it on the candidate. Mend found the root cause from the code alone: the API signed camera-frame URLs with a private key, and Cloud Run's identity holds only a token. Its fix signs through IAM. The review app returned the real camera frame, the user's steps passed, and the policy held the change as iron until a person approved it. Report to merge request: 17 minutes. Report to live: 42 minutes, including the human approval.

The hands-off run

The same afternoon, a report came in from a phone: the coop's name in the header read "Th...". Triage classed it gold, a style fix. Reproduce measured it: 19 pixels visible of 98. Mend gave the name its own row on small screens, one line of CSS, and the same test passed. The merge request cleared SAST, secret detection and dependency scanning, its review app replayed the user's steps, and the policy set auto-merge. GitLab merged it, the canary passed, the watch held, and release-21 shipped. The reporter's app said Mended, with a link to the proof.

Report to merge request: 8 minutes. Report to live: 28 minutes. Human steps: zero.

The run in the film is a third real bug, filmed as it happened. A farmer's app told her the best day to sell was "in 0 days". Triage classed it silver, logic in the API. Mend made it say today and tomorrow, with unit tests. A canary replayed her steps, the watch held, and release-25 shipped. Report to merge request: 11 minutes. Report to live: 35 minutes. Human steps: zero.

Challenges we ran into

  • Triggers fire only on human actions. A report from the public arrives through a service, so Desk starts the flow through the Flows API instead.
  • Flows receive only predefined CI/CD variables. The production addresses live in the repository, where agents read them.
  • GitLab keeps one label per scope. Our "held" label silently erased "verified". Path stages and holds now live in separate scopes, and the test double enforces the rule.
  • Hosted runners reach Ubuntu's Azure mirror unreliably. The flow image rewrites its package sources to kernel.org's mirror.
  • Real bugs in the app we care for. Kintsugi's own test suite found that the breed-growth data had stayed out of git, and its release gate found the signing bug before any farmer saw it.

Accomplishments we're proud of

  • An agent found a root cause from code alone, wrote a fix with a safe fallback and unit tests, and named honestly what remained to verify.
  • The reporter sees their own screen beside the mended one.
  • A hostile report waits for a person.
  • Autonomy scales with blast radius, written as a policy file.

What we learned

The hard part of agentic software delivery is the evidence around the code: a test that proves the bug, a replay that proves the fix, a stack trace the agent can trust, and a person who sees the result.

What's next

Kintsugi Desk is a small service with one widget. It can sit in front of any web app on GitLab. Next: video replays from the widget, a mobile SDK, and the ledger as a public changelog users can follow.

Built With

Share this project:

Updates

Submission history