Rafinery captures the thinking behind your code and turns every decision, correction, and change into compounding engineering knowledge. Agents use that knowledge to move from ticket to deployment with less human intervention — getting better with every task they complete.
“We're changing the shape of the auth token. What breaks?”
01Why we built it
We don't think the future is engineers versus agents. It's engineers and agents working together on problems that once felt impossible. But for that to work, agents need the context and knowledge engineers have built up over time.
The knowledge
What makes an engineer effective is knowing why something was built a certain way, what went wrong before, which approaches didn't work, and all the small conventions and decisions experienced engineers carry with them.
The problem
Coding agents write code incredibly quickly, but they come into a codebase without its history. They rediscover things the team already knows, forget corrections, and repeat mistakes engineers have already solved.
The answer
Capture that context once, keep it current, and let every agent and every engineer work from it. Then the work compounds instead of starting from zero every time.
02The problem
Every one of them blocks real work today, and none of them lives in the code. The answers live in decisions, incidents, conventions and reviews, which is exactly what gets lost.
Which decision led to it. What was tried and rejected. Which constraint it satisfies. Which incident it fixed. Which plan delivered it, and who signed it off.
Rafinery answersRafinery links the change back to the ticket, the plan, the review and the merge that produced it. You follow the links instead of reading old pull requests.
Which other code depends on this. Which conventions apply here. Which flows run through it. Which other repositories depend on its shape. And which failures would be silent.
Rafinery answersRafinery walks the code around the file and lists what depends on it, with the evidence for each claim and how sure it is.
Whether a playbook for this already exists. How much of the codebase the change really touches. What has to stay in sync. Which known debt is in the way. How you prove the thing is actually done.
Rafinery answersA plan built from what the team already knows. Every task names the files it touches and has a check that an independent agent re-runs itself.
03The graph
A real graph, scanned from this repository. Every node is a file, every edge a link declared in it, every shaded area a domain. Hover to explore; click to read a node the way an agent does.
drag to pan · ⌘/ctrl + scroll to zoom
verifiedGenerated from the committed sample graph and checked against it on every build. The 28solid edges are re-verified each time; if a cited token moves, the build fails. Graphs extracted by a model can't offer that: their edges are guesses, these are declarations.
04Ticket to shipped
How a ticket becomes a shipped change. Every stage reads from the graph or writes back to it. Exactly two moments need a person: the amber rows.
The ticket arrives with context, the plan comes from what the team already knows, and nearby cleanup is offered alongside. Then a person decides.
Linear agentintake
Starts the ticket with context
A ticket lands. The agent looks up what the graph knows about that area and comments back with the rules, flows and past decisions that apply. The ticket starts informed instead of empty.
out → issue id · graded context on the ticket
Atlasplans
Plans from what the team already knows
Every task names the code it touches, the rules and playbooks that apply, and a check that proves it's done. How much the change touches is computed from the graph, not estimated.
out → plan · tasks · done-checks · blast radius
Bloomnegotiates
Adds nearby cleanup to the plan
Finds the most useful open improvements and security fixes near the code this change touches, and offers them as optional tasks. Critical security findings can show up even from outside that area. You can dismiss any of them. None of them block.
out → enriched plan
Youhuman gate
Approve. Nothing runs without this.
You see exactly what the change will touch before you agree to it. Reject it, trim it, or send it back. No agent can skip this step.
out → go / no-go
Atlas goes straight to the right lines. Prism re-runs every check itself and reviews the diff against the graph. Then a person merges.
Atlasbuilds
Builds at the lines the graph already found
It goes straight to the files the graph mapped instead of searching, and follows the verified rules it was given. Where a test harness exists, it writes the acceptance test first, failing.
out → commits carrying the task's identity
Prismverifies
Re-runs every check itself
It works in isolation and judges the code, not Atlas's description of it. It trusts nothing self-reported. It can report problems but never edit, so a failure goes back to Atlas to fix.
out → cited verdict · Critical / Important / Minor
Prismreviews the diff
Reviews the change against the graph
The review works out exactly what the diff touches: rules, playbooks, open improvements, stale references, related decisions. Then it judges only that list. Review becomes a judgement call instead of a dig through history.
out → review verdict
Youhuman gate
Merge
The second and last gate. Everything after it runs on its own.
out → merge commit
Everything after runs on its own: the merge updates the graph, two observers learn from the run, and the team hears what shipped, with the evidence.
Reconcilerabsorbs · automatic
The merge updates the graph
It fixes the references your change moved, merges anything that duplicates knowledge already held, retires what is now obsolete, re-checks everything the merge touched, and audits dependencies. It can't be skipped, and it needs nothing from anyone's laptop.
out → the graph, updated and re-checked
meanwhile · outside the run
Compassobserves · private
Notices how you worked through this, and which of your tools went unused. Later it offers one tip at a natural pause. Opt-in, private to you, never shown to a manager.
Sageobserves · agents only
Reads how the agents performed across this run and many others. When a pattern of misses traces back to how an agent is defined, it proposes a fix with the evidence attached, for a person to review.
Slack agentannounces
The team finds out, with the evidence
What shipped, why, what it touched, what it cost. Every line links to the code, and it reads fine for someone who has never opened the repository. It answers follow-up questions from the same graph. When it doesn't know, it says so and records the gap.
out → the announcement · a recorded gap if knowledge was missing
05The team
Three do the work, two make the people and the system better at it. They run your development from the day you install, the same way they run Rafinery's own. Any agent you already use reads the same graph alongside them.
Builds your features. Before it writes anything, it looks up what the team already knows — the rules, the past decisions, how things are done here — so it goes straight to the right files instead of guessing. It keeps that knowledge up to date as it works, and never writes the same thing down twice.
Checks Atlas's work. It doesn't take Atlas's word for anything — it runs every check itself, reads the actual code, and says plainly whether the change is really done. It can flag problems but never fix them itself, so nobody grades their own homework.
Cleans up the codebase a little with every task. It spots the messy or risky parts near the code you're already changing and offers to fix them along the way — so the cleanup actually happens, instead of waiting for a big refactor project that never comes. You can always say no.
Helps you get more out of the tools you already have. It notices how you work, spots what Claude Code, Cursor, Codex or your other tools could do for you that you're not using yet, and offers a tip at the right moment. What it learns stays private to you — never shown to a manager.
Makes the other agents better over time. It watches where they keep making the same kind of mistake, works out why, and proposes a fix — with the evidence attached, and a person approves it before anything changes. It studies the agents, never the people.
06Measured
We use Rafinery to build Rafinery. In one A/B experiment, the same feature used 51% fewer tokens with the graph, and the agent avoided a correction round caused by an engineering convention it didn't know about. Same model, same task, separate working copies: one agent explored the codebase cold, the other read the graph first. Both shipped working code, but the cold agent paid for its mistake with a correction round larger than its original build.
verifiedEvery number above comes from the published write-up. If the write-up changes, this section changes, never the other way round.
The caveats: this was a 20-file repository, close to the worst case for this idea, since reading a small repo cold is cheap. And the graph's advantage was following conventions, not raw build speed. Both are in the published write-up, with the method and raw numbers.
Read the full experiment →Private preview
We're early, and we onboard each team by hand while we learn what a large codebase does to the graph. Tell us who you are and we'll come back with an invite and setup instructions.
The plan for general availability: a single developer on their own repositories is free. Teams pay for the platform, per seat, one price.