-
-
architecture diagram
Deki — AI That Remembers, Predicts, and Prevents Engineering Failures
Inspiration
I've seen engineering teams fix the same failure twice.
The first time, an incident happens. Engineers spend hours tracing logs, comparing deployments, reviewing commits, and trying to understand how a seemingly harmless code change caused a production failure.
Eventually, they find the root cause.
A post-mortem is written.
The incident is documented.
The team learns the lesson.
Then, months later, someone makes a similar change.
The same pattern appears.
And the same failure happens again.
The knowledge existed — but it was sitting inside a post-mortem, an issue, a Git history, or someone's memory.
It wasn't available at the moment the developer needed it.
That became the idea behind Deki.
We asked:
What if an engineering team's past failures could actively protect its future code?
Instead of waiting for production to fail and then documenting what happened, Deki brings historical engineering knowledge directly into the merge-request workflow.
When a developer opens a merge request, Deki asks:
"Have we seen this before?"
"What could this change break?"
"How large is the blast radius?"
"What could happen after deployment?"
And most importantly:
"Is this change safe enough to merge?"
That led us to a different kind of DevSecOps system.
We didn't want to build another tool that simply finds vulnerabilities or posts warnings.
We wanted something that could understand context, remember history, predict failures, and take action.
That's what Deki became.
What It Does
Deki is an autonomous AI DevSecOps intelligence platform that analyzes GitLab merge requests before they reach production.
It combines the current code change with historical engineering memory, service dependencies, security information, database changes, deployment context, and CI information.
The result is a 0–100 engineering risk score, an explanation of the risks, a simulated failure scenario, and — when necessary — an automated intervention.
Deki runs a structured 9-phase analysis pipeline.
The 9 Specialist Phases
| Phase | Specialist | What It Analyzes |
|---|---|---|
| 1 | Orchestrator | Collects live MR information, code changes, commits, and CI status |
| 2 | Chronos | Searches organizational memory for similar historical incidents and failures |
| 3 | Athena | Analyzes affected services, dependencies, API changes, and blast radius |
| 4 | Cerberus | Checks dependencies, CVEs, authentication risks, and security issues |
| 5 | Hermes | Examines database migrations, deployment risks, rollback complexity, and infrastructure changes |
| 6 | Morpheus | Calculates the 0–100 risk score and simulates possible production failure cascades |
| 7 | Echo | Stores the analysis in Firestore as persistent organizational engineering memory |
| 8 | Prevention | Converts findings into actions: blocking, issues, reports, annotations, runbooks, and CI gates |
| 9 | Report | Produces the final structured risk report with findings, risk level, and recommendations |
The important part is that these aren't isolated AI calls.
Each phase builds on the context produced by the previous phases.
For example:
Chronos may discover that a similar authentication change caused an outage six months ago.
That information becomes context for Athena.
Athena determines that the current change affects three downstream services.
That becomes context for Morpheus.
Morpheus can then simulate how the failure could propagate across those services.
Finally, Prevention decides what action should be taken.
This creates a reasoning chain:
Historical Memory
↓
Current Code Change
↓
Service & Security Analysis
↓
Blast Radius
↓
Failure Simulation
↓
Risk Score
↓
Action
Deki doesn't just analyze a merge request.
It reasons about what the merge request could become.
What a Real Deki Analysis Looks Like
During live testing against a real GitLab merge request, Deki produced:
RISK SCORE: 86/100 — CRITICAL
⚠ MORPHEUS FAILURE SIMULATION
T+0m Change deployed
T+2m Authentication regression detected
T+3m Downstream service begins returning errors
T+4m API gateway circuit breaker opens
T+9m P1 incident triggered
T+14m Database migration increases failure impact
T+90m Incident resolved
ESTIMATED BUSINESS IMPACT:
$4.23M
BLOCKING FINDINGS:
5
ACTION:
⛔ Merge request converted to Draft
Deki then automatically:
- Created 5 GitLab issues
- Posted the risk report to the merge request
- Generated an incident runbook
- Identified risky code
- Simulated the production failure
- Stored the analysis in Firestore
- Blocked the high-risk merge
All before the developer could accidentally push the risky change into production.
Deki Doesn't Just Analyze — It Acts
This is the core difference between Deki and a traditional analysis dashboard.
Most tools stop at:
Detect → Report
Deki continues:
Detect → Understand → Predict → Recommend → Act → Remember
Autonomous Prevention Actions
| Action | What Deki Does |
|---|---|
| Block High-Risk MR | Converts a CRITICAL merge request to Draft, preventing an immediate merge |
| Create GitLab Issues | Creates actionable issues for blocking findings |
| Post Risk Report | Places the complete analysis directly inside the MR |
| Inline Risk Annotations | Highlights risky code directly in the diff |
| Generate Incident Runbook | Creates mitigation, rollback, escalation, and recovery instructions before deployment |
| CI Risk Gate | Fails the pipeline when risk exceeds a configured threshold |
| CI Failure Diagnosis | Analyzes failed CI jobs, identifies likely root causes, and suggests fixes |
This means Deki can operate on both sides of the engineering lifecycle.
Before Deployment
Developer
↓
Merge Request
↓
Deki Analysis
↓
Risk Prediction
↓
Prevent Dangerous Merge
After Something Breaks
CI Failure
↓
Deki Retrieves Logs
↓
Root Cause Analysis
↓
Fix Recommendation
Deki therefore isn't only predictive.
It is also reactive.
It can look forward and ask what might break, while also looking backward and asking why something just broke.
How We Built It
The AI Core — Google ADK + Gemini on Vertex AI
Deki is built around a central AI orchestrator powered by Google ADK and Gemini 3.5 Flash on Vertex AI.
Our original idea was to create multiple independent agents — one for security, one for databases, one for incidents, one for blast radius, and so on.
However, we discovered that managing sequential handoffs between independent agents introduced unnecessary complexity.
Instead, we designed a single orchestrator containing multiple specialized reasoning phases.
The phases behave like specialist engineers while remaining inside one coherent execution context.
The biggest advantage is shared context.
When Morpheus performs a failure simulation, it can reason using the historical incidents discovered by Chronos, the service topology identified by Athena, and the deployment risks identified by Hermes.
The analysis therefore becomes one continuous engineering reasoning process instead of nine disconnected AI responses.
The Deki Architecture
The architecture is designed around one central principle:
A merge request should be analyzed using both current engineering context and historical organizational memory.
The flow begins when a developer creates or updates a GitLab merge request.
1. GitLab Layer
GitLab is the entry point.
Deki receives merge-request information through GitLab webhooks and communicates with GitLab through REST APIs and MCP-based integration.
Deki can access:
- Merge request metadata
- Code diffs
- Commits
- Pipeline status
- CI jobs
- Job logs
- Issues
- Comments
- Repository information
This gives the AI access to the same engineering context that a developer would normally have to manually collect.
2. Deki Orchestrator
The request reaches the Deki backend running on FastAPI and Google Cloud Run.
The orchestrator coordinates the nine analysis phases.
It determines what information is needed, invokes the appropriate tools, maintains the analysis context, and produces the final risk assessment.
This is the brain of the system.
3. Engineering Analysis Layer
The orchestrator runs the specialist phases:
Chronos
↓
Athena
↓
Cerberus
↓
Hermes
↓
Morpheus
↓
Echo
↓
Prevention
↓
Report
Each phase has a specific engineering responsibility.
The output of one phase becomes context for the next.
4. Organizational Memory
This is one of Deki's most important architectural components.
The Echo phase stores analysis results in Google Cloud Firestore.
Instead of every analysis disappearing after the request finishes, Deki builds a persistent memory of the organization's engineering history.
For example:
MR #102
Auth regression
Risk: 91
MR #148
JWT change
Risk: 86
MR #193
Payment API change
Risk: 78
Future merge requests can use this information.
This creates a feedback loop:
Past Incidents
↓
Firestore Memory
↓
New Merge Request
↓
Deki Analysis
↓
New Findings
↓
Firestore Memory
↓
Future Merge Requests
The longer Deki operates, the more engineering history it can remember.
5. Risk Simulation
The Morpheus phase transforms analysis into a prediction.
Instead of simply saying:
"This API change is risky."
Deki attempts to reason about what could actually happen:
Code Change
↓
Service Failure
↓
Dependency Failure
↓
Traffic Impact
↓
User Impact
↓
Business Impact
This gives engineering teams something much more useful than a generic warning.
They receive a possible failure narrative.
6. Prevention Layer
Once the risk score is calculated, Deki can take action.
For example:
Risk < 50
↓
Continue
Risk 50–79
↓
Warn + Recommend
Risk ≥ 80
↓
CRITICAL
↓
Block Merge
Create Issues
Generate Runbook
Post Report
Annotate Diff
Gate CI
The system therefore connects AI reasoning directly to engineering controls.
7. Google Cloud Infrastructure
The cloud architecture provides the infrastructure required to run Deki reliably.
| Component | Purpose |
|---|---|
| Vertex AI | Runs Gemini intelligence |
| Google ADK | Orchestrates the AI reasoning workflow |
| Cloud Run | Hosts the FastAPI backend |
| Firestore | Persistent organizational memory |
| BigQuery | Historical analytics and engineering trends |
| Pub/Sub | Event-driven processing |
| Secret Manager | Secure credential management |
| Cloud Build | Continuous deployment |
| Artifact Registry | Container image storage |
The result is a cloud-native architecture where AI reasoning, engineering memory, event processing, and enforcement work together.
Challenges We Faced
1. Designing the AI Architecture
Our original design used multiple independent agents.
The challenge was maintaining reliable sequential context between them.
We solved this by moving to a single orchestrator with specialized phases.
This simplified execution while allowing every phase to access the findings generated earlier.
2. Making AI Actually Enforce a Decision
Our first version could identify risks but only reported them.
We quickly realized that a warning is not enough.
So we connected the risk decision to GitLab actions.
For CRITICAL-risk changes, Deki can convert the MR to Draft and prevent an immediate merge.
That transformed Deki from an analysis tool into an engineering guardrail.
3. Making AI Reliable
Live AI calls introduced quota and transient API failures.
We added retry logic, exponential backoff, and fallback handling.
This was important because a DevSecOps system cannot become unavailable simply because one AI request failed.
4. Building Persistent Memory
Initially, analysis results existed only during the request.
Once the request ended, the knowledge disappeared.
We introduced Firestore through the Echo phase so Deki could persist:
- Risk scores
- Findings
- Historical patterns
- Incident matches
- Analysis results
This transformed Deki from a stateless analyzer into a system with organizational memory.
5. Integrating GitLab
GitLab integration required combining multiple interfaces.
We use GitLab REST APIs for direct engineering operations and MCP-based integration for contextual GitLab capabilities.
This allowed Deki to operate directly inside the development workflow rather than requiring developers to copy code into another AI application.
Accomplishments We're Proud Of
Deki works end-to-end against real GitLab data.
During live testing, we achieved:
- 86/100 CRITICAL risk score
- 5 GitLab issues automatically created
- Automated risk report
- Production failure simulation
- $4.23M predicted revenue impact
- Automatic incident runbook generation
- Automatic merge blocking
- Inline code-risk annotations
- CI risk gating
- CI failure diagnosis
- Firestore organizational memory
- GitLab integration
But the most important accomplishment is the complete workflow:
Deki identified a dangerous change, explained the failure, simulated the consequences, generated remediation steps, and blocked the merge.
That is the difference between:
Detection
and
Prevention.
What We Learned
Engineering Memory Is More Valuable When It Is Active
Documentation is useful.
But documentation that developers have to remember to search is passive.
Deki makes organizational knowledge active.
When a new merge request resembles a previous failure, the system can surface that history automatically.
Context Makes AI More Useful
An AI model can review a code diff.
But a code diff alone doesn't tell the whole story.
The real engineering question requires:
Code
+
History
+
Dependencies
+
Security
+
Database
+
Deployment
+
CI
+
Business Impact
Deki combines these contexts before making a decision.
Prevention Is More Valuable Than Detection
A scanner can say:
"There is a risk."
Deki asks:
"What will happen?"
Then:
"How serious is it?"
Then:
"What should we do?"
And finally:
"Should this merge be allowed?"
That progression is the foundation of Deki.
Organizational Memory Should Improve Over Time
Every analysis produces new information.
That information becomes memory.
Future analyses can use that memory.
So Deki can evolve from:
AI reviewing code
into:
AI understanding how an organization engineers software.
What's Next
Longitudinal Engineering Intelligence
Deki currently stores historical analyses in Firestore.
The next step is using BigQuery to identify long-term engineering patterns.
For example:
AUTH REGRESSIONS
────────────────────────────
Team: Payments
Last 90 days: 14
Previous 90 days: 9
Change: +55%
Primary pattern:
JWT / API contract changes
Deki would move from remembering individual incidents to identifying systemic engineering risks.
Learn From Real Production Outcomes
The next major evolution is closing the prediction loop.
Today:
Analyze
↓
Predict
↓
Prevent / Deploy
Future Deki:
Analyze
↓
Predict
↓
Prevent / Deploy
↓
Observe
↓
Compare Prediction vs Reality
↓
Learn
↓
Improve
If Deki predicts a failure and that failure actually happens, the outcome becomes additional evidence.
If Deki predicts a failure that never happens, that also becomes feedback.
Over time, Deki can learn which signals are actually predictive for a particular engineering organization.
More Development Platforms
Deki's intelligence layer is designed to be platform-independent.
We plan to support:
- GitHub
- Bitbucket
- Azure DevOps
The Git provider becomes an integration layer while the engineering intelligence remains the same.
More Production Intelligence
We also want Deki to connect the development lifecycle with production systems.
Future integrations could include:
- Slack
- PagerDuty
- Monitoring platforms
- Observability systems
- Incident management platforms
This would allow Deki to understand the entire lifecycle:
CODE
↓
MERGE REQUEST
↓
CI
↓
DEPLOYMENT
↓
PRODUCTION
↓
INCIDENT
↓
ROOT CAUSE
↓
MEMORY
↓
FUTURE PREVENTION
The Vision
Deki is built around one simple belief:
Every engineering failure should make the next failure less likely.
Today, organizations have enormous amounts of engineering knowledge trapped inside post-mortems, Git history, CI logs, issues, code reviews, and incident reports.
Deki connects that knowledge to the exact moment when a developer is about to make a change.
It remembers what went wrong.
It understands why it happened.
It predicts what could happen next.
It explains the potential impact.
It generates the remediation plan.
And when the risk is serious enough:
Deki acts before someone clicks Merge.
The long-term vision is not simply an AI code reviewer.
It is an engineering memory system that continuously learns from how a team builds, breaks, fixes, and improves software.
Deki turns yesterday's failures into tomorrow's guardrails.
Log in or sign up for Devpost to join the conversation.