From ticket to pull request, without leaving your repository.
Agents that plan a change, write it, test it and open the PR — on your branches, through your CI, inside your review rules. Your engineers keep the merge button.
The tickets nobody wants are the ones a system should be doing.
Bump the dependency. Add the rate limit. Backfill the tests. Real work, well understood, and a poor use of the people who understand it. This product takes those and hands back a reviewable pull request. Never a merge.
01 — A RUN, AS IT ACTUALLY READS
$ svakrit run [ENG-2841]
“Rate-limit the public search endpoint”
[01] read 4 files · middleware chain, config, tests
[01] plan token-bucket limiter, reuse request-context
redis client. no new deps.
———— awaiting plan approval ————
[02] approved [reviewer] · “use the shared config key”
[02] applied comment folded into plan
[03] write api/middleware/ratelimit.py [+124]
api/middleware/__init__.py [+3 ]
api/config/defaults.py [+7 ]
tests/test_ratelimit.py [+52 ]
[04] refused add dependency [ratelimiter@2.1]
rule [ENG-DEP-00] · no new third-party deps
wrote against existing client instead
tradeoff noted in PR body
[05] ci your pipeline, not ours
run 1 FAIL [test_search_paging] (flake)
run 2 PASS reported as flaky, not retried away
[06] pr opened [#1204] → base main
merge blocked: policy requires named approval
the agent will not merge, and structurally cannot. A refusal names the rule, what the agent wanted, and what it did instead. An agent that quietly worked around the policy would be the failure — not the one that stopped and said so.
02 — THE LOOP, IN A REPOSITORY
The same four steps CortexVigil runs on a camera feed.
That is not a coincidence or a marketing frame. It is the same runtime and the same governance layer, pointed at a git history instead of a control room.
Observe
The repository, the ticket, the CI history and the conventions this team already follows. Read, not guessed.
Decide
A written plan: what would satisfy this ticket, and would this team accept it in review. You approve or redirect it.
Act
Write the change, run your CI, open the pull request on your branch, with the tests that prove it. Never merge.
Account
Every tool call, file read, refusal and retry against the run. Reviewable at the next audit, not only while it is live.
Not a chat window. A colleague with a checklist.
This product is in development and this page describes where it is going. We would rather write that plainly than let you discover it in a trial.
Plans before it edits
Every run opens with a written plan against the real codebase. You approve or redirect it before a single line changes.
Lives in your repository
Your branch naming, your commit conventions, your CI, your PR template. Nothing new for the team to learn or log into.
Writes the tests too
A change arrives with the cases that prove it, and a note on what it deliberately did not cover, so review knows where to look.
Reports failure honestly
A flaky test is named as flaky, not retried until it passes. A ticket it cannot do comes back with a reason rather than a plausible wrong answer.
Leaves a trail
Every tool call, file read, refusal and retry is logged against the run. Reviewable months later, not only while you are watching.
Stays inside your walls
Self-hosted in your VPC, with the model provider you have already approved. Your source never becomes anyone else’s training set.
04 — GUARDRAILS
The interesting part is what it refuses to do.
An agent with commit access is a security boundary before it is a productivity feature. The policy layer is written by you, enforced outside the model where no clever input can argue with it, and logged whether it fires or not.
“The agent decided to” should never be the end of an incident review.
We are taking a small number of early-access teams.
We would rather work closely with a few teams on real repositories than open a waitlist we cannot serve. If you have a codebase and a backlog you would trust an agent with under supervision, tell us about it.