-
-
Ignite API - Architecture
-
Ignite Chat - Architecture
-
Ignite API - Evidence
-
Ignite Chat - Evidence
📜 Disclosure of Pre-existing Work (Path B: Bring Your Own): Ignite API and Ignite Chat existed before October 5, 2026. Everything presented here as the post-code automation (the GitLab Duo review agent, the GitLab CI pipelines, the supervised release flow, the smoke check and the new Google Cloud Run deployment) was built during the official Submission Period. The full list is in What we built during the Submission Period below.
Inspiration
- An AI provider bill kept growing because one default silently pointed to the wrong provider.
- API keys ended up in test files and in Git history.
- Deploys had to be verified by hand, and a cold start once looked like an outage.
None of these were coding problems. They were lifecycle problems, so we gave the lifecycle to agents.
Meet the agents
🤖 Ignite Reviewer (GitLab Duo Agent Platform)
- When: on every merge request in Ignite API and Ignite Chat.
- What it does: reads the diff and checks it against our own written engineering rules, not generic advice: no hardcoded keys or models, no
?api_key=URLs, explicit imports, mandatory logging, and no images sent to LLMs without vision. - What it decides: posts its findings as MR comments, with the rule that was broken and how to fix it.
🛡️ Security Gate (GitLab CI)
- When: on every merge request.
- What it does: runs our pytest suites, GitLab Secret Detection and SAST.
- What it decides: if anything fails, the MR cannot move to release.
🚀 Release Gate (supervised deploy)
- When: after the MR is merged and every gate is green.
- What it does: waits for a human approval (manual GitLab job), then triggers our existing GitHub Actions workflow through the GitHub API to deploy Ignite API to Google Cloud Run.
- What it decides: a smoke check waits for the new revision, tolerates the cold start, and marks the release healthy or failed.
Before vs. after GitLab
| Before (manual) | After (agentic, on GitLab) | |
|---|---|---|
| Code review | Self-review, rules lived in a document | Ignite Reviewer applies the rules on every MR |
| Secrets | Found weeks later by a manual audit | Blocked before merge by the Security Gate |
| Tests | Run locally, when someone remembered | Run on every MR and required to release |
| Deploy | Push and hope | Approved, triggered and verified by the Release Gate |
Real incidents the agents now catch
| Incident we actually lived | Caught by |
|---|---|
| API keys hardcoded in test files and probe artifacts | Security Gate (Secret Detection) + Ignite Reviewer |
Status URLs leaking ?api_key= in query strings |
Ignite Reviewer |
| A default provider silently pointing to a paid API | Ignite Reviewer (no hardcoded models or providers) |
| Images sent to an LLM without vision | Ignite Reviewer |
| A cold start mistaken for an outage | Release Gate smoke check |
What Ignite is
Ignite API turns documents, images, audio and video into schema-validated JSON. Ignite Chat is a multi-provider assistant that consumes it.
Ignite API: a real file in, schema-validated JSON out, with confidence and reasoning for every field.
Ignite Chat: a multi-provider assistant that consumes what Ignite API extracts.
What we built during the Submission Period (Path B)
- Imported both repositories to GitLab.
- Built the Ignite Reviewer Duo agent and turned our written engineering rules into its instructions.
- Wrote the
.gitlab-ci.ymlpipelines: pytest, Secret Detection, SAST, the manual release approval and the smoke check. - Connected GitLab to our existing GitHub Actions deploy through the GitHub API.
- Redeployed Ignite API to Google Cloud Run through this new flow.
How we built it
- GitLab: Duo Agent Platform for Ignite Reviewer;
.gitlab-ci.ymlfor the Security Gate and the Release Gate. - GitHub Actions: kept as the delivery engine; GitLab triggers it with a scoped token stored as a masked CI variable.
Google Cloud Run: hosts the live demo with scale-to-zero.
Ignite API: Python, FastAPI, Pydantic V2, Gemini-first transcription, Tesseract OCR and a two-stage video pipeline.
Ignite API architecture: extraction, async jobs and multi-provider LLM routing.
- Ignite Chat: multi-provider assistant (Gemini, DeepSeek, Anthropic and others) with voice and document generation.
Ignite Chat architecture: the conversational layer on top of Ignite API.
Challenges we ran into
- Two platforms, one decision-maker: we kept GitHub Actions for delivery and made GitLab the only place that can approve a release.
- Project-specific rules: generic review advice was not enough; the agent instructions went through several iterations until the agent applied our rules consistently.
- Cold starts: Cloud Run scales to zero, so the smoke check had to wait for the first slow response instead of failing.
Accomplishments that we're proud of
- Every merge request now gets an agent review, tests and a security scan before a human decides to ship.
- The agents enforce rules we learned the hard way, from real incidents.
- A real multimodal product behind it, live on Google Cloud Run.
What we learned
- Most incidents are lifecycle failures, not coding failures.
- Written rules only work when something enforces them on every change.
- Supervised autonomy is the right first step: agents do the work, humans keep the final say.
What's next for Ignite
- Fix proposals: let Ignite Reviewer open a suggested fix on the MR, not just a comment.
- Monitor agent: open issues automatically when token cost or latency drifts after a release.
- Hands-off mode for low-risk changes (docs, templates, dependency bumps).
Log in or sign up for Devpost to join the conversation.