How it works

Six stages between a ticket and a merged branch

Nothing here is a black box. Each stage has a job, a gate it has to clear, and a written record of what it decided and why.

Request a demo Explore the platform

run · BUG-2847

Stage 1 of 6

Running

IngestionTicket BUG-2847 queued · priority high0.2s
PlanningPlan: 3 files, middleware.ts, session.ts, auth.test.ts1.1s
Code gen47 lines across 3 files (batch 1/1)2.4s
Validation16/16 checks · confidence 94% · auto_apply0.8s
PR createdfix/BUG-2847 → PR #412 · CI running0.4s
CompleteTotal 4m 52s · cost $0.34 · merged

Pipeline stages

Validation checks

Files per run, max

Reasoning layers

why six and not one

One long loop is easier to build and harder to trust

A single agent doing everything in one context is the obvious design. It is also the one that cannot tell you which part of its reasoning failed.

one agent → six stages+4−4

−One model holds the ticket, the code and the review in the same context

+Each stage gets only what it needs, so the context stays small and the cost stays low

−When it goes wrong you get one confidence number for the whole run

+Every stage scores separately, so you can see which step was the weak one

−The model reviews the code it just wrote

+A different agent reviews it, with no memory of having written it

−Improving it means changing one prompt and hoping

+A stage that underperforms is replaced without touching the other five

stage 01 of 06

Ticket ingestion

The ticket arrives from wherever you file it

EnsureFix connects to your tracker by webhook or polling. When a ticket is created or tagged, it enters the queue with a priority score.

+Jira, Azure DevOps, GitHub Issues and Bitbucket

+Webhooks for instant pickup, or configurable polling

+Priority queue with an aging bonus for older tickets

+Similarity detection groups related issues

+Batch scheduling for efficient multi-ticket runs

queue, acme/payments

Incoming

BUG-2847JiraHighnow
#1182GitHubMedium
AB-441Azure BoardsMedium
BUG-2801JiraLow

Priority score includes an aging bonus, so old tickets surface.

stage 02 of 06

Intelligent planning

The codebase is read before anything is written

The PlannerAgent reads the description, scans the repository tree, and produces an implementation plan naming exact files with a per-file intent.

+Hybrid ranking: dependency graph 40%, semantic search 40%, code similarity 20%

+Root cause analysis finds the problem, not the symptom

+Impact simulation models behaviour before code exists

+Repo Intelligence Layer checks the plan against your rules

+Plan quality guard catches architectural issues early

+Optional human approval gate before it proceeds

plan, BUG-2847

Dependency graph40%

Semantic search40%

Code similarity20%

Files to modify

auth/middleware.ts
Add clock-drift tolerance
auth/session.ts
Renew before hard expiry
tests/auth.spec.ts
Cover the boundary case

stage 03 of 06

Code generation

Written in batches, reviewed as it goes

The CoderAgent generates in intelligent batches. Each batch is reviewed and scanned, and self-healing loops fix failing tests without anyone stepping in.

+Intelligent batching: 5 files per batch, 12 per run

+Reviewer checks logic, security, breaking changes and N+1 queries

+Security agent scans for OWASP vulnerabilities

+Self-healing detects test failures and fixes them

+16-point post-generation validation

+Decision engine: auto_apply, needs_review or block

ensurefix · run

batch 1/1 · 3 files
▸ coder      writing auth/middleware.ts
▸ coder      writing auth/session.ts
▸ tester     auth.spec.ts → 1 failing
▸ self-heal  adjusting guard clause
▸ tester     auth.spec.ts → 4 passing
▸ reviewer   logic, N+1, breaking changes
▸ security   OWASP scan → 0 findings
✓ 16/16 post-generation checks

stage 04 of 06

Review and approval

A human in the loop exactly where it matters

High-confidence fixes can apply themselves. Anything complex surfaces for review with the full reasoning trace, the diff, and the confidence breakdown.

+Trust panel: confidence ring, pattern-match badge, risk breakdown

+Expandable reasoning timeline across 7 layers

+Inline syntax-highlighted diff viewer

+Safety gate requires acknowledgement for blocked fixes

+Structured refinement turns a rejection into a targeted prompt

+Feedback trains the learning engine

trust panel, BUG-2847

94%

Confidence

Decision: auto_apply

Securitypass
Logicpass
Regression riskreview
Testspass

Pattern match: 4 previously accepted fixes in this repository.

stage 05 of 06

Commit and deploy

Branch pushed, PR opened, CI watched

EnsureFix pushes a branch, opens a pull request with the full context, and monitors CI. When a build fails, it diagnoses and fixes it.

+Branch creation with your naming conventions

+PR description carries ticket context, reasoning and risk

+CI failure auto-diagnosis via CIFeedbackAgent

+Automatic re-push once the fix lands

+Commit policy enforcement: files, risk level, blocked paths

+Auto-merge available for approved, low-risk changes

pull request #412

Branch fix/BUG-2847 created
PR #412 opened with context
CI pipeline running
All checks passed
Ready to merge

If CI breaks, CIFeedbackAgent diagnoses the failure and re-pushes.

stage 06 of 06

Learn and improve

Every outcome changes the next run

Accepting or rejecting a fix is training data. The engine calibrates weights, extracts patterns, and blocks approaches that keep failing.

+Pattern learning from accepted fixes

+Weight calibration from per-signal rejection rates

+Failure memory blocks patterns rejected 70%+ of the time

+Three-tier contextual weights: repo, problem type, global

+Strategy boosting rewards approaches that land

+Reasoning pattern store with Jaccard similarity matching

learning engine, acme/payments

Signal weights, recalibrated

Pattern match+0.10

Repo conventions+0.06

Broad refactor−0.05

Blocked pattern

Rejected in 7 of 9 attempts. Injected as a DO NOT USE instruction for this repository.

Where your code lives

Context goes out. Code never does.

EnsureFix reads what it needs in memory and writes back a branch. Nothing is persisted, and repository credentials are encrypted at rest with AES-256-GCM.

Read the security overview

Your infrastructure

Git repository

Issue tracker

CI / CD

Crosses the boundary

Context, in memory only

Comes back

Branch + pull request

No source code at rest

See the whole run

Watch it work, end to end

A live run on your codebase, from the ticket you pick to the pull request you review.

Request a demo View pricing