Kandryn
Sign inBook a walkthrough

A run is not a chat. It’s a pipeline.

Eight discrete stages. Four of them run every time; three of them wait until you ask. If one fails, the run row says which, and nothing half-finished lands in your repository.

Every run

Happens each time you press Run, in this order.

01

Context

Before an agent sees anything, the run assembles the case file: the work item, its acceptance criteria, and the files in the bound repository that the change planner selects as relevant. The detected stack profile rides along, so the agents write Express and Drizzle rather than generic pseudocode.

WHAT GOES IN
  • Work item title, description and acceptance criteria
  • Relevant repository files, chosen by the change planner
  • The directory tree, so the plan targets paths that exist
  • The detected stack profile
  • Your refinement prompt, if you wrote one
02

Two answers

Raptia and Fovea run in parallel against the same case file. They reason differently by design — when one misreads the acceptance criteria, the other usually does not.

WHY PARALLEL
  • One shared context, two independent reasoning paths
  • No sequential prompting, so no shared blind spot
  • Either answer is committable — Synthesia tells you which, and scores it out of 10
  • Both are kept on the run for later comparison
03

Synthesia ranks

Synthesia scores each suggestion on five model-judged dimensions plus a mechanical coherence check, weights them into a single score out of 10, and flags the leader as Recommended with a plain-English explanation of its reasoning. Two behaviour signals — ambiguity handling and surgical precision — are scored alongside it and shown on the run, but carry no weight in the ranking.

SCORED ON
  • Correctness — does it solve the stated problem? (30%)
  • Coherence — a mechanical check against the surrounding code (15%)
  • Convention adherence — does it match existing patterns? (15%)
  • AC coverage — how many criteria does it address? (15%)
  • Readability — is it clear and maintainable? (15%)
  • Minimal diff — does it change only what is needed? (10%)
04

Commit

Committing creates the deterministic branch task/<id>, writes the change, and opens a pull request titled with the work item. The item moves to review and the run records which suggestion won.

WHAT LANDS
  • Branch task/<id>, from the default-branch head
  • One commit containing the chosen suggestion
  • PR titled [Kandryn] <work item title>
  • Work item moved to review, run marked succeeded

If you schedule it

The same pipeline, claimed by the dispatcher instead of by you.

05

Schedule and sweep

A run can be queued up to thirty days out. Every five minutes the dispatcher claims what is due, runs it, and emails you the outcome — including the failures, with the reason attached.

THE LOOP
  • Up to twenty pending runs per user
  • Claimed two at a time, no double-dispatch
  • Runs stuck over twenty minutes are failed
  • Completion and failure both send email

After the commit, when you ask

None of these start on their own. Each is a button on the run, and each needs your Anthropic key.

06

Veria reviews

YOU TRIGGER THIS

After you commit a suggestion, Veria reads the committed code against the acceptance criteria and writes a structured review: what was addressed, what was missed, and what the human reviewer should focus on.

WHAT VERIA CHECKS
  • Which acceptance criteria are fully covered
  • Which are partially addressed or missing
  • Specific strengths in the committed code
  • Risks or gaps to watch in code review
07

Aegis secures

YOU TRIGGER THIS

Run Aegis on a committed run and it scans each changed file on its own for injection flaws, hardcoded secrets, authentication bypasses and other OWASP Top 10 (2021) categories. High and Critical findings fail the status check it posts to the pull request; that check blocks a merge once your branch rules require it. Medium and Low findings create sub-tasks in your tracker. Remediate Now creates the ticket, syncs it to the board, and starts a new run with the remediation brief pre-filled — closing the security loop without leaving Kandryn.

WHAT AEGIS CHECKS
  • Injection: SQL, NoSQL, command, LDAP, XPath
  • Hardcoded secrets, API keys, and credentials
  • Authentication and authorisation flaws
  • Cryptographic weaknesses and insecure data exposure
  • SSRF, XXE and deserialization issues
  • Missing input validation and rate limiting
  • Categorised against OWASP Top 10 (2021)
  • Each changed file is scanned independently; a file that cannot be scanned fails the gate rather than passing it
08

Narratia documents

YOU TRIGGER THIS

Narratia generates an operational runbook from the completed run: what changed and why, deployment steps specific to this change, rollback procedure, validation commands, and a summary of Veria and Aegis findings. Pushed to Confluence via REST API, Notion via the Notion API, or committed as docs/runbooks/ITEM-KEY.md to the same PR branch — zero extra credentials for the Markdown option.

RUNBOOK SECTIONS
  • Summary — the change in two or three sentences
  • What changed — the files and the reasoning
  • Deployment steps — specific to this change
  • Rollback procedure — referencing the branch and PR
  • Validation — how to verify it is working in production
  • Test cases — from the generated test suite
  • Security notes — Aegis gate status and findings
  • References — work item key, branch, commit hash, PR link

What it will not do

The boundaries are the product. Each of these is something you can check rather than something you have to take on trust.

  • It does not merge

    Kandryn opens the pull request and stops. Merging is your review, your rules and your CI.

  • It does not touch your default branch

    Work lands on task/<id>, and nothing else is ever written. Re-committing a work item moves that branch to the new commit, so keep your own work elsewhere.

  • It does not read your whole repository

    A handful of files selected as relevant to the work item. The planner also sees the directory listing — names only, capped.

  • It does not run the post-commit agents by itself

    Review, security and runbook generation are three buttons. A run that nobody follows up on has none of them.

  • It does not write to your tracker uninvited

    New items and test cases go up only when you push them. The single automatic write-back is a status change when an item closes.

  • It does not hold a model contract on your behalf

    Every call uses the API keys you saved, so the usage, the terms and the retention settings are all on your own account.

The full governance picture, with sub-processors and model disclosure →

Easier to watch than to read about.

Book a walkthroughExplore the demo
Request access

Queue the work tonight. Read the pull requests in the morning.

Request accessRead the guides