Questions teams ask first.

No. Your tracker, code host and chat keep owning the work and the conversation. Tinfirm adds the specialists, their runs, the decisions and the audit trail, and writes results back where the work started. It is not a tracker, a board or a chat product.

An assistant inside one tool sees that tool, with its own setup, permissions, bill and log. A Tinfirm specialist can take a Jira story, read the code on GitHub and query your own MCP server in the same job, under one set of rules for access, approvals, spend and audit. You can keep the assistants you like.

No. To Tinfirm, code and other work are the same thing: a job with a workspace, tools, decisions and results. Refining stories, writing test scenarios, updating documentation and evaluating projects run the same way as implementing an issue.

In the Tinfirm app, from their own AI client over MCP, or in a direct message to the Tinfirm bot in Slack or Teams. Triggers start specialists from Jira, GitHub, GitLab, a chat channel, a schedule or a webhook.

No. Specialists do jobs; no agent manages agents. Triggers say which specialist does what and when, and a person decides every approval.

Yes. Each conversation has its own session, branch and workspace, so several specialists can work on one issue at the same time. The turns of one conversation run in order.

Tinfirm, its database and its runner hosts run on your infrastructure. There is no product telemetry, and error reports reach us only if your operator turns them on. Prompts go to the model provider you choose, through your own gateway, and your systems' credentials stay in the deployment, outside the sandbox.

Only as far as you let it. Each tool reads or writes, and writes ask a person by default. Whoever edits a specialist can let a write run without asking; a person's or a trigger's settings can only make it stricter. A member decides each approval, never an agent, and every call is on the audit log.

Your own conversations are yours. Your company's Owners can read them in full for support and audit; Tinfirm says so, records each read and shows it to you. A trigger's conversations are seen by its author, its team and admins.

Text from issues, comments and tool results reaches a specialist as other people's words, never as instructions. Still, whoever can write where a trigger listens can drive its specialist with the trigger's accounts; the trigger editor says so and suggests narrowly scoped service identities for such triggers.

Every tool call with its conversation, the account used and its holder, its effect and its approval; every run with who paid and which host ran it; and every choice of authority, such as a trigger's accounts, grants and budgets. Each entry carries the hash of the one before, and the app can only add and read.

The ones you choose. Specialists reach models through a LiteLLM gateway, bundled with Tinfirm or your own, so any provider it serves works. They run on Claude Code, Codex, pi or OpenCode.

What your model provider charges you. Model traffic goes from your runner hosts through your server to your own gateway and on to your provider, with a budget per person; it doesn't pass through us.

That person's or service's turn fails with a usage limit, and their conversations wait until the budget resets or an admin raises it. Nobody else's budget pays for it.

Yes, for their own work. A member's subscription runs on their own runner host and serves only their own conversations and the triggers paid from their model access.

Community is free. Pro is €15 a seat a month, billed yearly (€180 a seat a year), for 5 to 150 seats, in euros. Enterprise is negotiated. Owners, Admins and Members take a seat; Viewers, who only read, and people who meet an agent in a channel or on an issue are free.

Yes: Community, with unlimited seats, agents, sandboxes, triggers and runs. Budgets, kill switches, erasure, OIDC sign-in and the audit come with it. Pro adds the Outlook add-in, tinfirm-lore, the audit's filters, export and checks, and your own retention periods.

Its core is, under MIT. The paid features live in one directory, ee/, under a commercial licence. Both are public in one repository, so your security team can read everything you run. The licence files ship with the first public release.

Yes. A licence is a signed text string you paste in the app, and the server checks it itself, offline. There is no call home. An offline installation bundle for air-gapped networks is planned for Enterprise.

For 30 days everything keeps working, with a notice. Then Tinfirm runs as Community. Nothing is deleted: retention periods in force keep running, open legal holds stay, and the audit's export stays for 90 days more. A new key restores everything at once.

Tinfirm runs on your infrastructure and you bring your own models through LiteLLM, so you pay your model provider directly and a run costs us nothing. You pay per seat, and agents, sandboxes, triggers and runs are never limited or metered.

Kubernetes 1.29 or later with the Helm chart, or a single host with Docker Compose; a PostgreSQL 18 database; LiteLLM, bundled or your own; and runner hosts on your own machines or VMs with Docker or Kata Containers. An Ansible role sets up runner hosts.

Runner hosts connect out to the Tinfirm server, so they need no inbound port, and Tinfirm polls Jira, GitHub and GitLab instead of waiting for their webhooks. A webhook trigger, if you use one, is called by the system that sends it.

Jira Cloud and Jira Data Center 8.14 or later; GitHub.com and GitHub Enterprise Server; GitLab.com and self-managed GitLab; other git hosts over HTTPS; Slack; and Microsoft Teams.

With local accounts or your own identity provider over OIDC: Entra ID, Keycloak, Okta or any other. AI clients sign in with OAuth or a personal access token.

Tinfirm is in development and not released yet. Early access is open to a few teams who will run it on their own infrastructure and tell us what's missing. They get a discount off the published prices.