Agentic engineering platform · join the early-access waitlist
Autonomy you can be
accountable for.
Ticinuum takes engineering work from ticket to merged code. Its agents plan the change, build it, test it and review each other's work — and it lands only when your checks pass and the people your policy names say yes.
Budgets, policy and a tamper-evident record govern every step. That is what lets you move fast without lowering the bar: engineering done the right way, at machine speed — where a well-specified change can cost a few dollars of model time.
tick-in-YOO-um · TIC(ket) + cont(INUUM) — The Continuum of Work.
-
What was asked
Give every setting a working control in the web app — filed by a person, turned into a brief with ten success criteria
-
What was checked
A second agent found two tests the change broke and sent it back — fixed, re-reviewed, approved; 6 checks passed
-
Who said yes
Merged by the platform — our org chose that on the record; by default a person gives the final yes
-
What it cost
$3.64 model usage at published API rates · 20 files · 1h 10m
-
Can you prove it
56 events, each one attributed — written as it happened
The problem
Agents made code cheap to write. Shipping it well is still hard.
An agent can write a change in minutes. Without a system around it, you choose between slowing every agent down to a person's review speed, or letting them run and finding out later what they cost, what they broke and who said yes. Burning more tokens and hoping more ships — tokenmaxxing — isn't a strategy.
The way through
Discipline gets cheap when the platform does it.
The practices that make engineering reliable — a written brief, independent review, tests that gate the merge, a budget, a sign-off — slow people down. Built into the platform, they take minutes, and they happen every time, not when someone remembers. Speed and quality stop being a trade-off.
- Slow every agent to the speed of a person reading diffs A second agent reviews every change; people decide what needs them
- Spend first, explain later A measured cost on every piece of work, and limits that stop
- Trust the agent, find out later Nothing merges until it passes review and your checks
One ticket, start to finish
A real change, from request to merged.
TIC-2115, from Ticinuum's own backlog: "give every setting a working control in the web app." A person filed it on October 18; once it started, no one stepped in. (Times are UTC.)
- 05:50
Groomer
Turned the request into a brief with ten success criteria.
- 06:05
Developer
Built the change — 20 files — tested it, and opened a pull request.
- 06:36
Reviewer changes requested
Found two tests the change had broken. Sent it back.
- 06:47
Reviser
Fixed both and pushed a new revision.
- 06:52
Reviewer
Re-read what changed. Approved. Six checks passed.
- 07:01
Platform
Merged — under our org’s on-record choice to let approved, green work land.
- 1h 10m
- request to merged
- 5
- agent runs
- $3.64
- model usage at published API rates
- 2
- broken tests caught before merge
Our org lets the platform merge work that passed review and checks. Yours starts with a person's final yes — and changes only when you choose, on the record. See every tab of this ticket →
How it works
A closed delivery loop. Every step on the record.
From ticket to a green main branch, the work moves on its own — with people exactly where your policy puts them.
-
The work is written down.
A request becomes a structured brief — specific enough that a machine can act on it and a person can audit it. Writing it down does not start the build.
-
Someone says go. An agent does the work.
A person presses Run, or a rule your organization chose starts it. The agent reads the codebase, makes the change and tests it — then proposes it for review rather than pushing it live.
-
A second agent checks the first.
A fresh reviewer that never saw the first one work goes over the change and sends it back if it is wrong. When a round stops making progress, it stops and asks a person instead of paying for another.
-
A person gives the final yes.
By default nothing an agent makes is merged until it passes review and your checks and a person says yes. Your policy can ask for sign-offs earlier, or let approved work land on its own — a choice that is itself on the record. Silence is never taken as a yes.
-
It lands — and the loop closes.
Changes land in order, and a broken main branch holds the line. Turn on the trunk watch and when something breaks after a merge, Ticinuum finds the change that did it, files the fix and proposes the revert for a person to approve.
Ticinuum builds Ticinuum · Oct 18 – Nov 8, 2026
- ~1,070
- pull requests merged into Ticinuum
- 86%
- opened by Ticinuum’s own agents
- 3 in 4
- landed by the platform itself
Three weeks of our own repository. Our org has turned on automatic starts and agent merge; yours begins with both off. Watch it being built →
The three questions
Three questions every engineering leader has to answer.
Before you let agents ship — and again the first time an AI-written change causes an incident, shows up on an invoice, or lands in front of an auditor.
-
Who approved it?
You decide what needs a person. Agents do the routine work on their own, but by default a person gives the final yes before any change is accepted.
Letting agents take that last step alone is a separate choice, made on the record. Either way, the record says who said yes, and when.
approval -
What did it cost?
Every piece of work carries its own measured cost — the tokens it used, priced at your model provider’s published rates (on a subscription plan, the tokens). Not a monthly invoice you take apart later.
Set a daily limit and the system stops starting new work when it is reached. Every run has ceilings of its own and pauses for a person if it crosses one. If it cannot confirm the spend is safe, it refuses to run.
cost -
Can you prove it?
Every decision is written down as it happens, in a record the product never edits. Sensitive changes are hash-chained and the whole chain is re-checked every day, so a break is caught and flagged.
When an auditor, a customer or your board asks what your AI did and who let it, the answer already exists.
evidence
Why it is different
Not a dashboard.
A control in the path of the work.
A report tells you what already happened. Ticinuum runs the agents that do the work, and decides — by your rules — what is allowed to happen next.
-
the usual A report that tells you what the agents spent
ticinuumA limit that stops them spending it
A number arriving after the money is gone is not a control.
-
the usual A dashboard you check when something feels wrong
ticinuumOne switch that stops all new agent work, instantly
Whoever is accountable can pull it without filing a ticket — and cancel a job already running within seconds.
-
the usual An audit trail assembled from logs afterwards
ticinuumA record written at the moment of the decision
A change and its record are committed together, so there is no change without its record.
Coding assistants help a person write code. Ticinuum delivers the work, and governs it.
Straight answers
Where we are.
What works, what doesn't yet, and what we don't claim — in the same size type as everything else.
- Works today
- The whole delivery loop above, on GitHub (on GitLab, with a person merging), building Ticinuum itself every day. It has rough edges, and we fix them in public.
- Not built yet
- Watching your software in production after it ships, and putting other vendors’ coding agents under the same limits and approvals. Both are on the roadmap, not in the product.
- Not claimed
- Security certifications. We keep the evidence trail an audit asks for; that is not the same as holding a certificate.
- Where we are
- Pre-launch. Nothing is for sale yet. We expect to meet a small number of people from the waitlist first.
Let the agents run.
Keep the receipts.
Join the early-access waitlist. We email you a link to confirm; after that we write only about early access — launch news, product updates, and for a few people, an invitation to talk.
Want to check our work first? Tech Details