Give coding agents the context of the organisation.
A coding agent understands the repository it is changing. It does not know what other teams are changing, which decisions are still open, or who needs to review the impact. Ledger works that out from your repositories and turns it into a verdict before the code merges.
Self-hosted. Delivered as full source your security team can read. Sends nothing outside.
- ~2 s
- per answer from the organisation index
- 11 → 339
- decision documents found once in flight context is available
- 0
- data sent outside
Speed and document counts measured on one estate of 175 repositories.
orders-service · feature/slim-order-event
This change
Removes customerId from the order.created event
Affects
billing-service reads that field
One open branch in billing-service touches the same event
Recommendation
decision_needed
Ask the owners of billing-service before merging.
Illustrative example
Not search. A verdict.
Agents scale locally. Organisations don’t.
AI made it cheap to open a branch. Knowing what that branch collides with is still one person’s memory.
Reviews approve conflicts
The agent and the reviewer both see one repository. The change is correct there. The service that reads the field it just removed lives somewhere neither of them looked.
Decisions live on branches nobody reads
On one estate, 11 decision documents were visible on default branches. Counting unmerged branches, there were 339. Most of what was being decided was invisible to everyone not in that branch.
Coordination is one person
Branch output went up. The capacity to coordinate stayed with the one staff engineer who happens to remember what every team is doing. Documentation can’t keep up, and nobody can search fifty repositories by hand.
How Ledger works
Derive, select, deliver. Nothing for your team to maintain.
Derive
Ledger reads your repositories and builds an index: which work is in flight, which repositories share a topic, an HTTP route or a table, and which decisions govern them. Almost all of it is computed without a model.
- · Built from git, kept current as branches move
- · Reads unmerged branches too
- · No catalogue to fill in by hand
Select
For one change, Ledger picks out what matters: the other repositories it touches, the open branches on the same ticket, the contracts it shares, and the decisions that apply to them.
- · Affected repositories
- · Work in flight elsewhere
- · Decisions and who decides
Deliver
The answer arrives where the change is being made: inside the coding agent, at push time, and in CI. It ends in a recommendation and names the people with authority to decide. Then it stops.
- · In the agent, through MCP
- · Before a push
- · As a CI step, report-only by default
Every answer ends in one of four verdicts
Finding things across repositories is the mechanism. The verdict is the product.
Nothing outside this repository depends on what changed. Go ahead.
Other teams have work in flight on the same ticket or contract. Here is who to show it to.
The change removes something another repository uses, or touches a contract with an open decision. Someone with authority decides first.
Ledger can’t tell. It says so. Unknown is never reported as safe.
What the organisation server adds
The free client answers on one machine. The server is one shared index that every developer, agent and CI job asks.
One warm index for everyone
Synced on an interval and on every push. It rescans only what moved, so answers come back in about two seconds and say how old they are.
Finds your whole estate
The server discovers and mirrors the organisation’s repositories. A developer only needs the one repository they work in.
Who produces, who consumes
Real producers and consumers of each topic, with direction, read from the infrastructure declarations you already keep.
Field-level contracts
Knows which fields each shared contract carries, so it can say “this diff removes a field another repository reads”.
Documentation that has fallen behind
Shows which wiki page describes a contract and how many commits behind the code it is.
Work that is merged but not released
Sees changes sitting on staging and develop branches, and decisions written on branches that have not merged.
Context before code is written
An agent can ask about a ticket or a contract while it is still planning. On one estate, about half of all recorded questions came before there was a diff.
Memory
Records every question, every verdict and what your developers said about it, so you can see which kinds of verdict are right on your code.
Gates you switch on yourself
Enforcement is off by default. You list the verdict classes that may fail a build, one at a time, once they have earned it.
Free client first
Start on one laptop. Upgrade in place.
The client gives a verdict on a developer’s own machine with no account, no server and nobody’s permission. It uses the same verdict logic as the server. On 35 real branches the two agreed on 33; the two they differed on were the two the server escalated.
When the organisation adds the server, nothing is reinstalled and nothing is thrown away. Same plugin, same commands.
Local answers when you ask. The organisation index answers before anyone asks.
-
1
Install the server once
A config file, a read-only credential for your git host, and one Docker Compose command.
-
2
Point developers at it
Each developer sets two environment variables. Their agent now asks the shared index.
-
3
Add CI, report-only
CI asks the same server and prints the brief. It does not fail anything yet.
-
4
Enforce what proved right
After a few weeks the report shows which verdict classes were right. You choose which of them may block.
Built for the questions your security team will ask
You get the source. Read it and scan it before it runs.
Full source delivered
You build the image from the source you receive. Nothing is pulled from Aglium at run time.
Nothing sent home
No usage counter, no licence check, no call to Aglium.
Facts, not file contents
Answers carry repository, branch, contract and decision names. Giving an agent Ledger does not give it your code.
Read-only access
One read-only credential for your git host is all the server needs.
One small machine
One process and one PostgreSQL database, started with Docker Compose.
Your model key, if any
A model is used only for field extraction, on your key, with personal data stripped first.
Works with what you already run
Coding agents
A Claude Code plugin with an MCP server. The agent can ask four things:
- brief — what does this branch affect, and what is the recommendation?
- inflight_for — what else is open on this ticket, in any repository?
- who_owns — which repositories publish, consume or declare this topic, route or table?
- decisions_for — which decisions apply here, and who decides?
Git hosts and CI
GitHub and Bitbucket Cloud are supported directly. Any other git host can be read as mirrors, and any CI system can ask the server over HTTP.
Infrastructure and decisions
Topic wiring is read from Strimzi, Terraform and AsyncAPI. Decisions are read from the ADRs and TODO files already in your repositories. Documentation is read from a docs repository or a mirrored wiki.
How you buy it
It is not per seat. A hire does not trigger an invoice.
Local
Free
The client and the Claude Code plugin, on a developer’s own machine. No account and no contract.
Pilot
Four weeks, fixed price
We install the server on your estate with you, replay your recent merged changes through it, and hand you a report of what it would have told you.
Organisation
Annual licence
Priced in bands by active contributors, counted from git. Unlimited repositories, briefs, agents and CI calls.
Common questions
Does our source code leave our network?
Nothing is sent to Aglium. The server runs on your infrastructure and talks to your git host. It hands out derived facts — repository, branch, contract and decision names — not file contents. A developer’s client sends its own diff to your server to get a brief; the server computes the answer and keeps none of it. A model is called only if you run field extraction, on your own key, with personal data stripped first.
What does the server need to run?
One small machine with Docker. The server is one process with one PostgreSQL database, started with Docker Compose, plus a config file and a read-only credential for your git host. Disk grows with your repositories, not with use.
Which coding agents and git hosts does it work with?
Claude Code is the packaged agent integration today, through a plugin and an MCP server. GitHub and Bitbucket Cloud have full adapters. Any other git host can be read as mirrors, and any CI system can ask the server over HTTP.
Will it block our merges?
Not unless you tell it to. Ledger is advisory by default and fails open, so an outage never blocks a merge. You choose which verdict classes to enforce after you have seen how they perform on your own changes.
How is it licensed?
The client is free. The organisation server is a commercial annual licence, banded by active contributors, with unlimited repositories, briefs, agents and CI calls. It is delivered as full source, and there is no licence check in the code.
What does it not do yet?
Ledger is new and we are running first pilots. It does not yet have single sign-on, a Kubernetes chart, merge-request comments on GitLab, or a link to your issue tracker’s workflow. It detects removed and renamed fields, not changes to a field’s type. Every figure on this page was measured on one estate.
See what Ledger finds in your repositories
Thirty minutes. We’ll walk through a brief on a real change and what a four-week pilot on your estate looks like.
Or reach us at info@aglium.com • Telegram