Now in development · early-access waitlist opening soon
Your agents ship code.
Ticinuum makes sure they don't ship a $40k bill.
Tickets are a control plane. Not a record system.
Ticinuum is an agent-first work control plane. Agents take the ticket, write the code, and open a real pull request — with a per-org budget breaker, policy-gated approval, and a full audit trail. Not AI inside Jira.
coming soon
Early access opens once the waitlist terms and privacy notice are final. Nothing to sign up for yet — this page collects no email.
tick-in-YOO-um · TIC(ket) + cont(INUUM) — The Continuum of Work.
See how it works ↓The shape of a run
Watch a ticket become a pull request.
This is what a run looks like end to end. A ticket goes in. The agent plans, clones the repo, writes the change, and runs tests. It opens a real PR on GitHub — or a merge request on GitLab. A reviewer agent in a fresh context posts a verdict, a bounded revise pass pushes fixes, and in autonomous mode Ticinuum merges the PR and settles the ticket to done. The transcript below is illustrative — a recorded run replaces it once early access opens.
A real autonomous run
Watch the agents build a real app.
Captured from the product: Ticinuum’s agents take one goal — “build a chess game” — and carry it from an empty backlog to shipped, tested Go. Planning, parallel grooming, real pull requests, code review, and a budget breaker, all on the record.
Built for the whole C-suite
One run. Every seat at the table.
The same autonomous run produces the evidence every leader needs to trust it — captured from the product. Finance sees cost and ROI. Engineering sees velocity. Product sees the breakdown and dependencies. The CIO gets an audit trail down to every run log and artifact.
Not AI inside Jira.
A record system stores what happened. A control plane makes things happen. Your ticket isn't a row a human updates by hand — it's a machine-reasonable unit of intent an agent can execute.
Cursor and Devin write the code. Ticinuum governs the work.
The problem
The hard part isn't getting an agent to write code.
It's the control plane around it — cost, audit, approval, isolation, safety — that makes autonomy something you can actually operate. Today you're stuck between a passive record system and an ungoverned coder.
- cost
Autonomous agents burn money with no ceiling.
An agent calling a paid API in a tool-calling loop is, by construction, a way to spend money quickly. One stuck run can re-send a growing conversation on every turn.
-
No audit trail, no governance.
Most autonomous tools give you a diff and a vibe — not a record you can take to compliance. When something goes wrong, you can't reconstruct what happened or what it cost.
-
It's all-or-nothing.
Full autonomy is scary. Full human review is a bottleneck. There's no dial for "autonomous here, human gate there."
-
Anyone who can file a ticket can hijack the agent.
The moment untrusted input reaches an autonomous run, prompt injection is a live attack surface — in any language.
Our approach
Most AI tooling focuses on generating work. Ticinuum focuses on governing work.
Organizations can tell you what they spend on AI, but rarely what value they receive from it. Teams use coding agents, review agents, and investigation agents, yet these systems operate as isolated assistants rather than coordinated workflows.
Ticinuum is built on a simple belief: the entire software delivery lifecycle can be partially automated — but only when cost attribution, governance, auditability, and human oversight are built into the foundation. The ticket is that foundation — a durable, machine-reasonable unit of intent that drives execution, not a row a human updates by hand.
Our goal isn't to replace engineers. It's to create a safe, measurable, and accountable system where humans and AI agents work together to accelerate delivery.
- Every action tracked.
- Every cost attributed.
- Every decision auditable.
- Every workflow governed.
How it works
From intent to pull request — governed end to end.
A ticket isn't a row a human updates by hand. It's a durable, machine-reasonable unit of intent. Works today
-
Describe the intent.
Describe the work in plain language and Ticinuum drafts the full validated ticket spec — type, priority, scope, validation — mapping every inferred value through the domain rules. A grooming agent then fills any missing fields before it can run. Describe-first is on by default; the structured knobs are one click away.
-
Dispatch safely.
Before anything runs, the ticket clears an injection gate and the budget/kill-switch breaker. If it can't be verified safe, it doesn't run.
-
The agent does the engineering.
It plans, clones the repo, writes the change, and runs tests in a fresh per-run workspace that is discarded when the run ends.
-
It opens a real pull request.
On a branch named ticinuum/<ticket-key>-<work-item-id>-a<attempt>, with a real diff and PR body. Connect a developer identity on GitHub or GitLab and it opens the pull/merge request for real; without one the change is recorded as a diff artifact instead.
-
Independent review, then you approve.
A fresh agent (never the coder) reviews the PR and can post under a distinct identity; on REQUEST_CHANGES a fresh agent revises in place, bounded. Autonomous is the default: Ticinuum runs that whole loop — review, revise, merge, done — unattended. Prefer a checkpoint? Set the ticket (or your org default) to supervised and a human approves before Ticinuum merges the approved PR to done.
-
Everything on the record.
Every state change, decision, token, and dollar is written to an append-only timeline — atomically with the state it describes. Watch the run live (a tail of the agent's real output) and export the whole ticket as a self-contained bundle — a markdown summary, every run's full log, and the artifacts.
The spec the agent reasons over has six parts:
- Intent
- goal, success criteria, non-goals
- Scope
- repos, paths, environments, constraints
- Inputs
- context references (tickets, docs, incidents)
- Outputs
- required artifacts (PRs, tests, reports)
- Validation
- automated and manual checks
- Execution
- mode (autonomous / supervised / manual), agent type, timeouts, retry policy
Cost guardrails
Autonomy you can afford.
Every org gets a daily budget breaker in real dollars. Cross it and Ticinuum auto-pauses the whole org until an operator resumes it. And it fails closed: if the system can't verify spend is safe, it refuses to run.
Where the system cannot verify that spend is safe, it fails closed — it refuses to run rather than burn money it cannot account for.
- Global kill switch — halt every execution platform-wide, instantly.
- Configurable per-run token ceiling — a hard cap that survives pause/resume, so a single run can't quietly balloon.
- Bounded loops — the agent's tool-calling rounds and revise passes are bounded, so it can't spin forever.
- Operator hard-stop — cancel a run and the in-flight model call is aborted within seconds; whatever was spent is still metered.
Audit trail
Every diff, decision, token, and dollar — on the record.
A state change and the event that describes it are written in one database transaction. Most event systems are eventually-consistent and can drift from reality. This one can't.
State changes and their events are written in the same PostgreSQL transaction, so the timeline can never diverge from reality.
- An append-only timeline — of everything that happened — relayed to an analytics store with at-least-once delivery and dedup.
- Every token and dollar — per ticket and per run — metered from real input/output counts and stored, surviving later price changes.
- A live tail of the agent at work — stream the real run's iterations, tool calls, and pauses to the ticket view — like CI logs, for the agent — then archived to blob storage.
- Export the whole ticket — one self-contained .tar.gz bundle — a markdown summary (spec, PRs, reviews, cost, comments, timeline), every run's full log, and the artifacts — to hand a local model or keep as an audit artifact.
- Run logs, diffs, plans, and snapshots — in durable blob storage — ours by default, or yours (see Data residency below).
- A searchable admin Audit view — sensitive changes beyond the ticket timeline — kill-switch flips, role and secret changes, quarantine, logins — land in an append-only audit stream you filter by entity, actor, action, and time at /ui/audit: an OrgAdmin over their own org, a SystemAdmin across every org. A streaming CSV/JSONL/JSON export of exactly the filtered slice is an admin-gated toggle, on by default.
- The evidence an audit actually asks for — every interaction logged; a reviewer running in a fresh context.
Governance & human-in-the-loop
Humans approve only where policy requires.
Autonomy isn't all-or-nothing. You set the policy; Ticinuum enforces it.
Agents request human approval only where policy requires it.
- Policy gates — require human approval, a security review, or a change window for the work that warrants it. The rest runs autonomously.
- Durable human-in-the-loop — when an agent needs a human, it pauses, snapshots its workspace and conversation, and resumes the exact conversation and workspace under the same run ID — surviving crashes and restarts.
- Take the wheel anytime — operators can inject notes into a run, and REVIVE or CANCEL it outright.
- A role-scoped kill switch — a SystemAdmin halts every org at once or an explicit set of them from a searchable picker; an OrgAdmin halts their own. Every halt and resume is authorized server-side and written to the audit trail with an actor and a reason.
- A SystemAdmin console — retune the operational tunables — the org daily budget, the dashboard estimate knobs, the feature toggles — at runtime, no redeploy, from one guarded console that also hosts the platform-wide controls.
- A lifecycle that is machine-governed, not draggable — tickets move open → in_progress → in_review → ready → done through an enforced state machine. open and ready sit at opposite ends — open means “in the backlog,” ready means “validated and ready to merge.” It is not a board you drag cards across; it is a state machine the platform enforces.
Autonomy is a dial — and it defaults to on. New tickets run the full loop unattended — dispatch through merge to done — gated by the budget breaker, injection quarantine, bounded loops, and kill switch, not by a human click. Prefer a checkpoint? One per-org Safety and guardrails setting makes supervised your default, and any single ticket can be set supervised so a human dispatches and approves before Ticinuum merges the approved PR to done.
Security, BYOK & multi-tenancy
Your key, your quota, your data.
Each tenant runs on its own key, its own quota, and can't see anyone else's data.
- Bring your own key — each org can bring its own Claude key, so it burns its own quota. Keys are encrypted with AES-256-GCM, versioned for non-disruptive rotation, and decrypted only in the service layer. If a key cannot be read, the run falls back gracefully to a system key.
- Tenant isolation at the app layer — cross-tenant access returns 404 — a resource you don't own is indistinguishable from one that doesn't exist.
- Injection quarantine, before dispatch — two layers — red-teamed pattern matching plus a cross-lingual LLM classifier — hold suspicious tickets in quarantine before they ever reach an autonomous run.
- Auth — JWT on the API (the service won't start without a configured secret); session-cookie auth on the UI.
- Single sign-on, per org — an OrgAdmin binds an OIDC identity provider and members sign in with SSO — OIDC discovery, PKCE, and ID-token verification, with just-in-time provisioning gated on the IdP's verified email domain. No global flag: the button appears once your org binds an IdP, exactly the way BYOK activates per-org.
- Multi-org identity — identity is global — one account, one email — with a distinct role in each org and an org switcher that re-scopes the session. OrgAdmins manage members from Settings; N org-spanning root admins are a separate grant, and every change is on the audit trail.
Data residency & bring your own bucket
Choose what lands where.
The hybrid shape already runs the agents inside your network. Now you decide which artifacts Ticinuum stores at all — per family, with three presets — and whether your run artifacts land in your own S3-compatible bucket instead of ours.
- Three presets, one switch each — Standard keeps everything on the platform (the default). Restricted stops workspace snapshots, diffs, the repo-survey cache, and webhook archives. Minimal adds rendered prompts, the run-log archive, and workstation-attached artifacts — every family that can be turned off. An advanced per-family matrix sits behind the presets.
- Off means never produced, not deleted later — a disabled family is refused at the gateway with a machine-readable reason, and the executor is told the policy at run start so it never builds the tarball or captures the diff at all — nothing crosses the wire. If the policy cannot be resolved, the write is denied.
- Bring your own bucket — point run artifacts, run-log archives, repo surveys, uploaded attachments, and webhook archives at your own S3-compatible bucket. The control plane signs each upload against your endpoint and the executor still holds no storage credential. Grant a read-only key and the app renders diffs and plans from your bucket through short-lived links; withhold it and you see references only.
- The cost is disclosed before you choose — every off switch shows what stops working and what still works before it accepts the change, warns that turning a family back on never recovers what was never produced, and months later the empty panel says "your organization chose not to store this" — with who and when — instead of looking like a broken agent.
Honesty note: by default artifacts still land in Ticinuum's storage — a snapshot of the working tree (git history excluded), diffs, plans, rendered prompts, summaries, run-log archives, and repo surveys. Under Minimal without your own bucket, a paused run's conversation state, plans, summaries, and uploaded attachments still do; artifacts attached from a workstation over MCP land with us unless that family is off. Your own bucket is S3-compatible only, all-or-nothing per org, verified at the storage layer against MinIO — not yet end-to-end or against AWS — and while it is on, a child agent cannot read its parent's plan. The control plane holds your write credential encrypted to sign uploads. Every change is audited per family.
Claude Code & MCP · opt-in
Your engineers' sessions join the record.
Turn on the Ticinuum MCP server and an engineer's own Claude Code session can read the ticket, its plan, the repo profile and the run history, annotate the work as that engineer, and have its token spend attributed to the ticket — in the same ledger the autonomous runs use.
- tic claude TIC-827 — one command activates the ticket — resolving its initiative and project and opening a session — then launches an unmodified Claude Code. No fork, no wrapper. Any MCP client works; Claude Code is first.
- Read and write as the engineer, never as the platform — ten read tools (ticket, plan, attachments, repo profile, project context, runs, run logs, initiative, findings) and eight write tools (create, update, comment, attach, label, link, hold, release hold). Writes go through the same services as the UI, so the injection quarantine applies, and every write is audited with the credential that made it.
- Spend attributed, prompts never captured — the laptop reports what it spent — tokens, model, latency — and the control plane decides what it belongs to from the activated ticket. Metadata and counters only; prompt content is never ingested. Every cost figure is labelled autonomous, workstation, or total.
- A laptop can never start an autonomous run — dispatch and complete are deliberately not tools. The credential is scoped to the engineer's own role in one org, revocable, rate-limited, and no tool ever accepts an org id.
Honesty note: both halves — the MCP server and workstation metering — ship off until the platform operator turns them on. The CLI's browser login (tic login) is not built yet; today the launcher reads a credential issued out of band. Sessions on a Claude subscription seat price at $0 under our catalog, so the workstation figure is tokens-first until a valuation is decided, and the combined autonomous-plus-workstation dashboard is not built.
Founder note
We're measuring the wrong thing.
We're building Ticinuum because we believe we're measuring the wrong thing.
Most organizations using AI today can tell you what they spent. Very few can tell you what they got in return.
One engineer might spend thousands of dollars a month on AI tooling. Another might spend hundreds. Which one delivered more value? Did the first engineer produce twice the output? Ten times the output? Did either of them reduce cycle time, improve quality, or accelerate delivery? In most companies, nobody really knows.
At the same time, what we call "agentic engineering" today is often just a collection of disconnected assistants. A coding agent writes code. A review agent reviews it. An investigation agent analyzes an incident. A ticket agent drafts requirements. Each tool can be useful, but they operate independently, with little coordination, governance, or accountability.
We think software delivery is headed somewhere much bigger.
Every stage of the software development lifecycle can be automated to some degree: requirements gathering, ticket grooming, implementation, testing, security review, deployment, operations, and incident response. But automation without governance creates risk, and governance without automation creates friction.
Ticinuum exists to bridge that gap.
Ticinuum is a governance and orchestration platform for AI-driven software delivery. It provides the controls, auditability, cost attribution, approval workflows, and human-in-the-loop checkpoints needed to safely automate work across the entire SDLC. Every action is tracked. Every cost is attributable. Every decision is reviewable. Every workflow can be automated without losing accountability.
It's still early, and we won't pretend otherwise.
The core path—from ticket to implementation to pull request to review to completion—already works. So do the audit trail, guardrails, and BYOK model. The broader vision is still being built, and the roadmap below reflects that reality.
If you're an engineering, platform, or technology leader who believes AI should be measured by business outcomes rather than token consumption, we'd love to run a real ticket through Ticinuum with you.
Verifiable today
Architected for trust.
No fake logos, no invented metrics — just what's verifiable today:
-
Audit events written in the same database transaction as state.
-
AES-256-GCM key encryption with non-disruptive rotation.
-
App-layer tenant isolation that returns 404 on cross-tenant access.
-
A two-layer prompt-injection gate that quarantines malicious tickets before dispatch.
-
Per-org SSO — OIDC sign-in with PKCE and domain-gated JIT provisioning, activated per org like BYOK.
-
Role-based access control — a typed system_admin ⊃ org_admin ⊃ user ⊃ viewer hierarchy, enforced across many orgs.
-
Per-family data residency — turn off what Ticinuum stores, refused at the gateway and never produced by the executor.
-
Bring your own S3-compatible bucket — run artifacts written to and read from storage you own, each upload signed by the control plane.
Built on a stack you trust:
Under the hood
Conservative by design — verifiable in code.
Ticinuum is three small Go services: an API, an orchestration worker, and an executor that runs the agent. The audit relay isn't a fourth service — it runs in-process inside the API. They divide into two planes, and that line is the whole security story.
- A control plane and a data plane. The API and the worker are the control plane: they hold the state, the orchestration, and the decisions. The executor is the data plane — the only piece that ever touches your source code. Scale the expensive tier on its own; a runaway agent can't starve orchestration.
- The executor reaches out. Nothing reaches in. It isn't a queue worker you have to expose. It asks the control plane for work over ordinary outbound HTTPS, does the job, and reports back — so it needs no inbound ports, no database, and no connection to the orchestrator. It holds none of the platform's keys, and borrows a repo-scoped, short-lived git credential one run at a time.
- Run it wherever your policy says. Because the executor only needs to dial out, the same binary works in either shape: host the whole platform yourself, or leave the control plane hosted and run executors inside your own network. The checkout, the model traffic, and the build run on your infrastructure; what Ticinuum keeps afterwards is your call — turn artifact families off, or point your run artifacts at your own bucket — while tickets, approvals, and spend stay in one place.
- Durable by default. Temporal workflows make execution crash-safe and resumable — it still schedules, retries, and times out every step. Single execution per ticket is guaranteed by the workflow ID, not a fragile lease. Orchestration never leaves the control plane.
- Clean data discipline. One writer per store: Postgres for current state, blob storage for artifacts — ours by default, yours by policy — and an append-only ClickHouse trail for events. A state change and the event describing it commit in one Postgres transaction; a leader-elected in-process relay then drains the outbox into three streams — ticket_events_v1 (the timeline), usage_events_v1 (cost), audit_events_v1 (the audit trail). Every store the executor would need sits behind that boundary — it gets what a run requires handed to it, and keeps nothing.
- A roster of agents, not one God-agent. Every SDLC stage resolves to a role-specific agent — developer, reviewer, reviser, planner, groomer — drawn from an in-binary standard-agent registry; bundle a lineup as a reusable squad and bind it at the org, project, or ticket level. Each org sets its own default Claude model, and repos come from a cached git-host catalog instead of free text re-typed per ticket.
Roadmap fence
Today vs. on the roadmap.
We'd rather under-promise. Here's exactly where the line is.
- Autonomy is a dial — defaulting to on. New tickets run the full loop unattended — dispatch → real PR → review → revise → merge → done, bounded by the budget breaker, injection quarantine & kill switch; set a ticket (or your org default) to supervised and a human dispatches and approves before Ticinuum merges the approved PR itself
- Ticket → agent → real PR → independent-context review → a bounded review→revise loop (per-org round cap) → done
- Backlog grooming lifecycle — a machine-checked groomed gate, a grooming agent that asks when unsure, and a depends-on / blocks ticket-dependency DAG (plus manual parent/child linking)
- Multi-org identity + SSO. One account across many orgs with a per-org role, member management, and per-org OIDC single sign-on with just-in-time provisioning
- Agent roster & squads — every SDLC stage resolves to a concrete agent (no whole-ticket "God agent"); reusable role→agent squads bind a lineup once
- AI-native ticket creation — describe-first "Draft with AI" infers the full validated spec (on by default)
- Findings — a shared, evidence-backed observation pool with no flag to turn on: agents write down what they notice, confidence-scored and deduped by fingerprint (close one as fixed and it re-opens if it comes back; acknowledge it and a recurring confirmation stops nagging), and a high-confidence critical finding linked to a ticket raises a blocking gate. Produced by read-only investigations (no write, commit, or PR tool, a throwaway checkout Ticinuum never pushes) and by ordinary coding runs reporting mid-flight
- Notifications — an in-app inbox plus email alerts when an agent pauses for input, a run fails, or a budget trips, with per-user category toggles; email delivery activates once a Postmark token is set
- Admin Audit view — search, filter & drill-down over an append-only audit stream, with a streaming export
- SystemAdmin console — runtime config store, role-scoped execution halt (global + per-org), and per-org model configuration
- Project-scoped repositories — repos attached to a project from a cached git-host catalog, not retyped per ticket
- GitHub and GitLab — the same developer/reviewer role split on either host, selected by the repository's host; an unmatched host is refused, never silently fallen back
- Agent egress controls — on by default: the agent's web fetches go through a guard that checks the resolved IP right before connect, so DNS rebinding cannot walk it into your private network or cloud metadata endpoint (governs web fetch, not shell)
- Analytics — org-isolated spend + velocity dashboards plus decision-support (agent-quality, flow & bottleneck, cost-by-type)
- Prompt/agent lineage attribution — every run's rendered prompt is content-addressed and stamped onto the cost stream, so Analytics compares first-pass success, cost & latency per prompt version — "did this agent edit help?"
- Multi-scope spend budgets, chargeback & Teams — hard budgets by org / project / user / team, a period-close chargeback export, and org-chart team cost centers with per-team caps and spend rollups
- Autonomous backlog dispatch — on by default: a bounded schedule promotes, dispatches, grooms & reconciles existing backlog tickets on a cadence, gated by the breakers and per-cycle / in-flight caps; a per-org toggle opts out
- Project memory — a one-time repo survey builds a durable profile later tickets recall to start oriented (per-org toggle; secret masking best-effort)
- Data residency policy — per-family off with Standard / Restricted / Minimal presets, refused at the gateway and never produced by the executor; the workspace snapshot excludes git history; every change is disclosed first and audited
- Bring your own bucket — run artifacts, run-log archives, repo surveys, uploaded attachments & webhook archives written to and read from your own S3-compatible storage, with an optional read-only grant (all-or-nothing per org; verified at the storage layer — end-to-end and AWS conformance still open)
- Distinct reviewer identity — a separate reviewer App (GitHub) or application (GitLab) reviews under its own VCS identity, else a review comment under the developer
- PR/MR review-feedback → child tickets — on by default: non-blocking review comments become tracked, linked follow-up tickets
- Transactional email — welcome / reset / invite mail, active once a Postmark token is set
- Live agent-log tail + per-ticket cost (tokens & USD) + self-contained export bundle
- Cost guardrails: per-org daily USD breaker (auto-pause, fail-closed), kill switch, per-run token ceiling, bounded loops, operator hard-stop
- Audit trail written atomically with state; real per-run USD metering
- BYOK with AES-256-GCM encryption + graceful fallback
- App-layer tenant isolation (404)
- Two-layer prompt-injection quarantine
- Durable human-in-the-loop (pause / snapshot / resume same run)
- JIRA & Linear import. Keep your tracker as the system of record; issues import via verified webhook + reconcile poll (in end-to-end testing)
- Self-service signup & org creation. Email-first, double opt-in; off keeps the platform invite-only
- Full observability — metrics, distributed tracing, logs & continuous profiling. OpenTelemetry out to your own stack, with a self-hosted Grafana / Loki / Tempo / Mimir / Pyroscope setup, dashboards & alert rules included. One trace follows a ticket across every service. Point it at a collector to switch it on; unset, it is a no-op Every role also serves a Prometheus /metrics endpoint you can scrape with no collector deployed at all (alert rules evaluate but nothing pages yet)
- claude-local backend — ~$0 subscription-backed execution (reduced: fresh runs only, no HITL/pause/BYOK)
- Ticinuum MCP server — Claude Code (or any MCP client) reads and annotates tickets as the signed-in engineer over a revocable workstation credential: ten read tools, eight write tools,
activate_ticket, and thetic claudelauncher. A laptop can never dispatch a run (tic loginis not yet built — credentials are issued out of band) - Workstation session metering — an engineer's Claude Code spend attributed to the ticket in the same ledger as autonomous runs; metadata and counters only, prompt content never captured
- Initiatives — the "what are you trying to accomplish?" front door. For work that is still an idea: spar with a cheap model, mature it into a versioned objective, then decide — plan it, write an RFC, or reject it with a rationale (a good outcome, and scored as one). It commissions tickets and never executes or spends on its own. One switch also opens the findings triage queue and patrols — a standing question, a persona roster and a schedule, answered on a cadence by read-only investigations (patrols are built but not yet validated end-to-end)
- Closing the full circular loop: deploy → observe → feedback
- Multi-tenant agent sandboxing — isolated per-job execution (credential brokering & egress filtering have since landed; the isolation itself has not)
- Configurable "Draft with AI" agent — project → org → system layering (today's drafter is a fixed one-shot)
- Support portal + attested, per-field-provenance intake
- Full multi-repo / multi-PR spanning one ticket
- SKIs — reusable engineering standards ("how we write Go") injected into agent prompts
- Flexible tenancy — deployment options spanning shared to fully isolated per-tenant databases
- Bring-your-own-bucket, finished — per-family routing (today it is all-or-nothing per org), GCS / Azure, and end-to-end + AWS conformance
- The combined autonomous + workstation cost dashboard (waits on a decision about valuing subscription-funded sessions, which price at $0 today)
tic login— browser-assisted credential acquisition from the CLI (the server half exists)- Opt-in prompt-content ingestion — an undecided governance question; today prompt content is never captured
- "Ticinuum builds Ticinuum"
Autonomy is a dial, and it defaults to on — the whole loop, merge included, runs unattended, gated by the budget breaker, injection quarantine & kill switch rather than a human click. Prefer a checkpoint? One per-org setting makes supervised your default, and any ticket can be set supervised so a human dispatches and approves before Ticinuum merges. You choose where the human stands.
Comparison
Where Ticinuum fits — and where it doesn't.
| Capability | In-editor coders (Cursor, Copilot) | Autonomous coders (Devin-class) | Record systems (Jira, Linear) | Ticinuum |
|---|---|---|---|---|
| Writes code, opens PRs | You drive | Agent drives | No | Agent drives, real PR |
| Independent-context review + bounded revise | No | Limited | No | Yes (fresh-context reviewer) |
| Ticket as a durable, machine-reasonable unit of work | No | No | Human-driven rows | Yes |
| Cost breaker that fails closed | No | Not exposed | n/a | Yes |
| Per-tenant cost metering & analytics | No | Not exposed | n/a | Yes (per-model, per-ticket) |
| Audit written in the same DB transaction as state | No | No | No | Yes |
| BYOK per-tenant quota | No | No | n/a | Yes (with fallback) |
| Policy-gated human approval | No | Limited | Manual | Yes |
For raw in-IDE coding fluency, Cursor and Copilot own that lane — we're not trying to take it. Ticinuum is the control plane you run an autonomous agent inside: the cost, audit, approval, and isolation layer that turns "an agent that writes code" into autonomy you can operate.
FAQ
Questions, answered plainly.
How do you pronounce it, and what does it mean?
Tick-in-YOO-um. It's TIC(ket) + cont(INUUM) — the continuum of work. A ticket runs as one durable thread from intent to PR to review to done.
Is this just AI on top of Jira?
No. Jira and Linear are record systems — humans drive the rows. In Ticinuum the ticket is the control plane: a machine-reasonable spec an agent executes, with the lifecycle enforced by the platform, not a person dragging cards.
Do I have to fill out a big structured form to file a ticket?
No. Creation is describe-first: pick a project and an assignee, describe the work (drop in a screenshot or log if you have one), and "Draft with AI" infers the full validated spec — type, priority, severity, references — which you can then edit. It's on by default; the classic structured form is one toggle away. Every inferred value is mapped through the domain validators, so the model can't widen the domain.
Can I control which agent does each step?
Yes. There's no single whole-ticket "God agent" — every SDLC stage (develop, review, revise, plan, groom) resolves to a concrete agent through a hierarchy: a ticket per-role pin, then the ticket's squad, then the project's default squad, then an org default, then an in-binary standard agent. A "squad" is a named, reusable role→agent lineup you bind once at the ticket or project level.
How do you stop agents running away with my bill?
Independent layers, each able to stop a run: a global kill switch, a per-org daily budget breaker in real dollars that auto-pauses on breach and fails closed, a configurable per-run token ceiling, bounded loops, and an operator hard-stop that cuts the in-flight model call in seconds.
Will it auto-merge my PRs?
It depends on the dial — and the dial defaults to on. Autonomous (the default): Ticinuum runs the whole loop — review, revise, merge, done — unattended, gated by the budget breaker, injection quarantine, and kill switch. Supervised (a per-ticket choice, or your org default via one Safety and guardrails setting): a human approves first, then Ticinuum merges the approved PR for you and the ticket settles to done.
Does it run my backlog unattended?
Yes, by default. New tickets are autonomous AND the backlog sweep is on, so once a ticket is groomed Ticinuum dispatches and runs it to a merged PR unattended — gated by the budget breaker, injection quarantine, kill switch, and per-cycle / per-org in-flight caps, and it never touches a quarantined, on-hold, or over-budget ticket. Want a human to dispatch each ticket? Turn off auto-dispatch for your org (and/or set your default to supervised) in Safety and guardrails; a platform admin can disable it everywhere.
Is the review actually independent?
A reviewer agent runs in a fresh context and can post under a distinct identity. If you don't configure a separate reviewer identity, it falls back to the coder's identity and labels the verdict as a comment — we're upfront about that.
Can a whole team use it? How do roles and multiple orgs work?
Yes. Identity is multi-org: one account can belong to many organizations with a different role in each, and an org switcher re-scopes your session. Access is four tiers — system admin, org admin, member, viewer — enforced server-side; org admins invite members and change roles from Settings, and a viewer is genuinely read-only.
Do you support SSO?
Yes. An org admin binds an OIDC identity provider — issuer, client ID, allowed domains — and members then get a "Sign in with SSO" button. There's no global flag: it appears once your org connects an IdP, exactly like BYOK. New users can be just-in-time provisioned, gated on a verified email domain and a configured role, with PKCE and ID-token verification throughout.
Can I sign up myself, or is it invite-only?
Both are supported — which one is live is an operator's call. Self-service signup ships off by default, so the platform stays invite-only until an operator turns it on. When enabled, signup is email-first and double opt-in: nothing lands in the real tables until you confirm the emailed link and finish setup, so there's no org-name squatting and no junk accounts.
Where are my keys stored?
Encrypted with AES-256-GCM, versioned for rotation, decrypted only in the service layer. Bring your own key and your org burns its own quota, with graceful fallback to a system key.
Does our source code reach Ticinuum?
In the hybrid shape the agent clones and works inside your network, and your model provider sees what any coding agent sends it. What Ticinuum itself stores is a policy you set. By default its storage holds a snapshot of the agent's working tree (never the git history), diffs, plans, rendered prompts, summaries, run-log archives, and repo surveys. The Restricted preset stops the snapshot, diffs, repo surveys, and webhook archives; Minimal adds rendered prompts and the run-log archive. Even then a paused run's conversation state, plans, summaries, and uploaded attachments still land with us — unless you point your run artifacts at your own bucket. Ticket text, events, cost, and audit rows always live in the control plane. We won't write "your source never leaves your network": it isn't true of any hosted control plane, and we'd rather show you the matrix.
Can we use our own bucket?
Yes — any S3-compatible bucket. An org admin adds an endpoint, a bucket, and a write credential; Ticinuum verifies it with a round trip (screened so it can't be pointed at internal or cloud-metadata addresses) before using it. From then on run artifacts, run-log archives, repo surveys, uploaded attachments, and webhook archives are written to and read from your storage; the control plane signs each upload against your endpoint and the executor still holds no storage credential. Add a read-only key and the app renders diffs and plans through short-lived links; skip it and you see references only, with the offer to add one. Said plainly: it is all-or-nothing per org, the control plane holds your write credential encrypted in order to sign uploads, artifacts written before you switched stay where they were, artifacts attached from a workstation over MCP still land with us unless that family is off, planner decomposition is degraded until one read path is converted, and it is verified at the storage layer against MinIO — not yet end-to-end or against AWS.
Can our engineers use Claude Code with it?
Yes, once the platform operator turns on the MCP server — it ships off. Each engineer gets a revocable workstation credential scoped to their own role in one org. tic claude TIC-827 activates the ticket and launches an unmodified Claude Code with ten read tools and eight write tools — read the plan, the repo profile, the run history; comment, attach, label, link, and park a ticket so nothing auto-acts on it — as that engineer, through the same injection quarantine and audit trail as the UI. A laptop can never dispatch or complete a ticket, and the CLI's browser login isn't built yet; today the credential is issued out of band.
Do you see our prompts?
No. Workstation metering (also opt-in) ingests metadata and counters only — tokens, model, latency, timestamps — and attributes them to the activated ticket server-side. Prompt content is never captured; an opt-in content path is an undecided governance question, not a feature. The autonomous agent's own rendered prompts are stored as artifacts by default, and that family can be turned off or kept in your bucket like any other.
What about prompt injection?
Two layers — red-teamed pattern matching plus a cross-lingual LLM classifier — quarantine suspicious tickets before they reach a run.
Can I see and export the audit trail?
Yes. Sensitive changes — kill-switch flips, org halts, role and secret changes, quarantine, logins — land in an append-only audit stream written in the same transaction as the state they describe. Admins browse it in an Audit view with structured and free-text filters and per-row before/after drill-down; a streaming CSV / JSONL / JSON export of the filtered slice is available (on by default, and an admin can close it). Org admins see their own org; system admins see across orgs.
Are you SOC 2 certified?
No, and we won't claim a status we don't have. What's true today: audit events written atomically with state, AES-256-GCM key encryption, app-layer tenant isolation (404), and a two-layer injection gate.
What works today vs. roadmap?
See "Today vs. on the roadmap" above — we draw the line plainly.
Put your backlog on the continuum.
From intent to PR to review — one durable, auditable continuum of work. Early access opens soon.
coming soon
Early access opens once the waitlist terms and privacy notice are final. Nothing to sign up for yet — this page collects no email.