Tinfirm connects your trackers, code hosts, chats and your own tools to the same specialists, and puts one set of rules over all of them: one inbox, one permission model, one budget per person and one audit log. It runs on your servers.
An admin registers each system once. From then on any specialist can take work from it, use it as a tool, or both, with the accounts each piece of work is allowed. Pick one to see what it does.
An issue is created, updated, enters a status, gets or loses a label, is assigned, mentioned, commented on or closed.
Read and search issues; comment and transition them.
A comment, a transition or attached documents, and a link to the conversation.
agent:refine is added to SHOP-241An issue or a pull request is opened, updated, labelled, assigned, mentioned, commented on or closed.
Read and search; comment and label; work on its own branch and open a pull request.
A comment, labels added or removed, the issue closed, a pull request.
shop-webAn issue or a merge request is opened, updated, labelled, assigned, mentioned, commented on or closed.
Read and search; comment and label; work on its own branch and open a merge request.
A comment, labels added or removed, the issue closed, a merge request.
shop-apiSomeone mentions the bot in a channel, with a specialist's @handle or for the channel's default, or sends it a direct message.
Read the channel's history.
A reply in the thread under the specialist’s name, and approval buttons for linked approvers.
@analyst in #product which stories touch gift cardsSomeone mentions the bot in a channel, or sends it a direct message. People are linked through Entra ID.
Answer in the thread it was asked in.
A reply in the thread, and approval buttons for linked approvers.
You start a conversation with any specialist shared with you.
Everything the specialist may do, with your own accounts and your own budget.
The conversation, live: watch the transcript, steer it, decide its questions and approvals.
You start or continue a conversation from the AI client you already use, signed in with OAuth or a personal access token.
The same as in the app, with your accounts and your budget.
The answer in your client. Decide your questions and approvals, and read or delete your memory notes there too.
At the times you set, at most every 15 minutes. While the last run is busy, the next one is skipped, or starts beside it if you choose.
Whatever its specialist may do.
Outputs in Tinfirm, with a review before they go out when you ask for one. After downtime it catches up one missed run at most.
accounting MCP serverAnother system calls the webhook’s URL with a signed request. You map its JSON to the subject, the actor and the text, and set conditions on it.
Whatever its specialist may do.
Outputs in Tinfirm, with a review when the trigger asks.
Nothing: MCP servers give specialists tools, not events.
Call the tools you grant each specialist. An admin confirms whether each tool reads or writes; until then it counts as a write.
Results to the specialist. Writes ask a person first unless the specialist allows them.
accounting MCP serverOther git hosts work too, for repositories over HTTPS.
An assistant built into each tool brings its own settings, bill and log. In Tinfirm the same rules hold whether the work came from Jira, a chat or a schedule.
docs-siteEvery question and approval, from every system, waits in one place per person, and also where the work started: on the issue, in the chat thread or in your own AI client. Failed turns and accounts to reconnect show up there too, with their cause. How decisions work
Every tool of every system reads or writes. A specialist lists the tools it may use and whether each runs at once or asks a person first; reads run and writes ask unless its editors decide otherwise. A person's settings, or a trigger's, can only narrow that. Tools in three layers
Every member and service identity has one key on your LiteLLM gateway, with a budget your admins set: a company default, changed per person where needed. A spent budget stops only its owner's work. Admins see spend by person, specialist and trigger.
Every tool call, with its conversation, the account it used and its holder, its effect and its approval. Every run, with who paid and the host that ran it. Every choice of authority: a trigger's accounts and payer, grants, budgets. Each entry carries the hash of the one before.
A specialist holds no credentials. Whom the work is for decides whose accounts it uses and who pays, and that stays fixed for the whole conversation: checked at every use, never switched, never a silent fallback.
Three roles, and accounts that belong to whoever they act for. Admins manage the company's own identities; members manage their own.
Your tools will get AI either way. The difference is whether you set it up, secure it, pay for it and audit it once, or again in every tool.
| Compared | An assistant in each tool | With Tinfirm |
|---|---|---|
| Setup | Configured again in every tool, with its own instructions | Defined once, used from every system and shared with the teams that need it |
| Reach | Works inside the tool it ships with | One job can use Jira, your repositories and your own MCP servers together |
| Decisions | Questions wait in each tool's own screens | Every question and approval in one inbox, and where the work started |
| Access | Permissions set separately in every tool | Each tool reads or writes, writes ask a person by default, and a person's settings only narrow |
| Spend | A plan or seats per tool, billed by each vendor | One key and budget per person on your own gateway, with spend by person, specialist and trigger |
| Audit | A separate log in every tool | One hash-chained log of every tool call, the account it used and who approved it |
| Models | The models its vendor offers | Any model your LiteLLM gateway serves, on Claude Code, Codex, pi or OpenCode |
| Where it runs | Usually in the vendor's cloud | On your own servers, and your systems' keys never enter the sandbox |