Your agents ship code.
Ticinuum makes sure they don't ship a $40k bill.

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.

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.

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.

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.

Independent layers. No build starts until someone asks for it. A global kill switch and a per-org daily budget breaker in real dollars — it auto-pauses the org on breach and fails closed — stop new work from starting, and budgets per project, team or person can refuse new runs at their own limits. Configurable per-run ceilings on tokens and on dollars pause a single run before it balloons, and the review loop stops the moment a round stops making progress. And an operator hard-stop cancels a run already in flight, cutting the model call within seconds.

Treating tokens as a unit of cost and a unit of value, the way the FinOps Foundation describes it: metered, attributed, and tied to an outcome. Its opposite is tokenmaxxing — rewarding how many tokens people burn instead of what the tokens bought. In Ticinuum the unit of account is the piece of work. Every ticket carries its own cost from real usage — by model and by token class — and rolls up into the feature it belongs to, so the question changes from "what did we spend on AI this month?" to "what did this change cost, and was it worth it?" Validated efficiency alerts on top of that are still on the roadmap.

Only once a person says yes — or once your org has chosen, on the record, to let the agent merge. Autonomous (the default): once a person presses Run, Ticinuum runs review and revise unattended, and once the review approves and CI is green a "Merge needed" item asks the ticket's owner to merge it with one click. Letting the agent make that merge on its own is a separate setting your org admin elects against a recorded disclosure — it lapses after 90 days unless re-confirmed, and isn't yet available to orgs on GitLab. Either way nothing merges without an affirmative review and green checks; a review loop that stops making progress, red checks, or a conflict it cannot resolve go to a human instead, and merges wait while someone has frozen the base branch or its checks are red. Supervised (a per-ticket choice, or your org default via one Safety and guardrails setting): the ticket waits at a gate for a person to approve it, then Ticinuum merges the approved PR for you and the ticket settles to done. If the loop escalates instead, a person can take the merge decision themselves — and that person can't be the ticket's author or owner. Your git host still owns branch protection either way.

Not unless you choose it. By default a person starts each piece of work: filing a ticket grooms it if it needs it, then it waits until someone presses Run. From that one click an autonomous ticket goes through review to an approved, green PR with no further click — gated by the kill switch, the budget breaker and injection quarantine, held to your org's executor capacity, and never touching a quarantined or on-hold ticket — and then a person merges it. Supervised tickets also wait for a person to promote them. Work no person started — a ticket an agent files, a ticket a finished one unblocks, and a pull loop that starts your backlog's top-ranked work under a work-in-progress limit — all wait until a platform admin exposes it and your org admin opts in against a recorded disclosure of what it does and spends. (Patrols your admin schedules, and the next steps of a plan a person started, run on their own.) Issues from your tracker or git host land in Intake as requests, and nothing happens until a person admits them.

The reviewer is always a fresh agent in a fresh context — never the coder. Before its model weighs in, the build and test commands your repository declares run on a real checkout, and a red result blocks the change automatically; Ticinuum doesn't guess your toolchain, so with nothing declared it leaves that to your pull request's own CI, which the merge waits on anyway. It can post under a distinct identity; if you don't connect a separate reviewer identity, it falls back to the coder's identity and labels the verdict as a comment — we're upfront about that.

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.

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. 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; where the IdP supports it, signing out of Ticinuum signs you out there too.

Sign-in is email-first: Ticinuum offers each address only the methods it actually has — a password, your org's SSO, a one-time link emailed to you (on by default; a platform admin can turn it off), or a passkey where your deployment enables them — and an unrecognized address sees the same choice an ordinary password account sees. Sessions are revocable: sign out everywhere from Settings → Security & access, and a password change or a deactivated account ends every session at once; signing out everywhere or changing your password also revokes your MCP connections. How sign-in works →

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.

Your agents run on your executor, on the model credential in its own environment — an Anthropic API key, a Claude subscription, or your own AWS Bedrock account — so their spend lands on your provider account, the control plane never holds that key, and we add no markup to it. For the control plane's own small AI calls (drafting a ticket, the injection classifier, error explanations) you can store your org's key: write-only, encrypted with AES-256-GCM, versioned for rotation, decrypted only in the service layer. Whether Ticinuum's own key may serve you — before you add yours, or as a rescue if yours breaks — is a choice your org records: allow it and those calls go through our provider account with the platform fee; deny it and it's your key or nothing. Left unset, our key serves you until you add one, but never silently rescues a key of yours that breaks.

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, the run-log archive, the test and other reports an executor produces, workstation-attached artifacts, and finding evidence. 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.

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.

Yes, once the platform operator turns on the MCP server — it ships off. An engineer connects Claude Code, Claude Desktop, or claude.ai by URL and signs in through the browser — or signs the tici launcher in once with tici login, after which tici claude TIC-827 activates the ticket and launches an unmodified Claude Code. More than 200 tools — read the plan, the changes, the repo profile, the run history; file, comment, attach, label, link, and put a ticket on hold so nothing auto-acts on it — act as that engineer, bounded by their live role in one org, through the same injection quarantine and audit trail as the UI. The tools whose purpose is starting or resuming agent work that spends your budget (run, groom, retry, approve, merge) need a separate permission the engineer grants explicitly when connecting, and tici login doesn't ask for it; no tool completes a ticket. Every connection shows up in Settings → Connections, where it can be revoked. A ticket filed over MCP is groomed like any other, then waits for a person's Run; the merge waits for a person unless your org lets the agent merge. Connect a client →

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.

Two layers — red-teamed pattern matching plus a cross-lingual LLM classifier — scan every request at the door, before it can become a ticket: what a teammate types, issues from Jira, Linear or your git host, and comments on a pull request. A hit holds the request in Intake and creates no ticket until an admin other than its author clears it — never over MCP. The same gate scans text added to a ticket later, what an engineer's client writes over MCP, and every answer to an agent's question. If the classifier can't be reached, the request or ticket is held and re-scanned on its own, released when the classifier is back, and put to a person only if the outage lasts an hour. Scanning ships on; an org can opt out.

Yes. Sensitive changes — kill-switch flips, org halts, role and secret changes, quarantine, logins — land in an append-only audit stream, hash-chained per org and re-verified on a schedule. Each change is written in the same transaction as the state it describes, with one deliberate exception: engaging a halt or a budget pause commits first and audits a moment later, so a stop can never fail because its log line did. 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.

No, and we won't claim a status we don't have. What's true today: state changes and their events written atomically, a hash-chained audit stream, AES-256-GCM key encryption, revocable sessions, app-layer tenant isolation (404), and a two-layer injection gate.

See "Today vs. on the roadmap" above — we draw the line plainly.