Credentials stay in your deployment
Systems are reached through tools the server runs, git through the runner host's proxy, and models through its model proxy. Your systems' keys and the gateway's key never enter the sandbox.
One firm of AI specialists for every system you work in.
Instead of an AI assistant in every tool, each with its own setup, permissions and bill, Tinfirm runs your specialists from one self-hosted platform. Define a specialist once, and it takes work from the Tinfirm app, Jira, GitHub, GitLab, Slack and Teams, works across them with the accounts you allow, and brings every decision that needs a person to one inbox.
- Self-hosted on Docker Compose or Kubernetes
- Any model, through your own LiteLLM gateway
- Your systems' keys never enter the agent's sandbox
Not released yet; early access is open to a few teams.
An example thread, played live. Answer the question to steer it.
One platform instead of an assistant in every tool.
AI is arriving in each of your tools on its own terms: its own setup, permissions, bill and log, and it sees only the tool it lives in. Tinfirm gives all of your systems the same specialists, under one set of rules.
Tinfirmyour deployment
Your specialists, each defined once
AnalystReviewerWriterFinance analyst
- EventIn Jira,
agent:refineis added to SHOP-241 - WorkAnalyst reads the story, related issues and the checkout code on GitHub
- ResultAcceptance criteria posted on SHOP-241
Also usesGitHub
- One inbox
- One permission model
- One budget per person
- One audit log
Your MCP serversYour own tools
InJiraIn Jira,
agent:refine is added to SHOP-241Back toJiraAcceptance criteria posted on SHOP-241
Nine ways in, one set of rules. Pick one to see its example.
Works with Jira Cloud and Data Center, GitHub, GitLab, Slack, Microsoft Teams, schedules, a signed webhook for any other software, and your company's own remote MCP servers. People also start conversations in the Tinfirm app itself, from their own AI client over MCP, or in a direct message to the bot.
Every system and the rules over themManage AI once, not once per tool.
Your tools will get AI either way. The decision is whether you set it up, secure it, pay for it and audit it once, or again in every tool.
From an event to a known end state.
Your tracker keeps owning the work. Tinfirm adds the specialists, their runs, the decisions and the audit trail, and every run ends in a state you can see, with its cause.
Something happens where you already work
A label is added in Jira, a pull request opens on GitHub or GitLab, someone mentions the bot in a Slack or Teams channel, a schedule fires, another system calls the webhook, or a person starts a conversation with a specialist in the Tinfirm app, from their own AI client or in a direct message. Tinfirm watches with the account you chose, so it sees only what that account sees.
JiraGitHubGitLabSlackMicrosoft TeamsWebhookScheduleYour AI clientTinfirm app
SHOP-241Story
Pay with a gift card at checkout
Customers ask to use the gift cards we sell in our stores when they order online.
checkoutagent:refine
StatusBacklog
- 07:42Lena added the label
agent:refine - 07:42Tinfirm picked it up for Analyst
A trigger hands it to a specialist
Each trigger reads as one sentence. Every matching trigger fires, with the accounts and model budget its author chose. When the author loses a right the trigger needs, it pauses. It never switches account or payer.
Trigger on Jira · project SHOP
When the label agent:refine is added to an issue in SHOP and its status is Backlog, Analyst does prepare it for refinement, with the accounts of svc-analyst.
Matched SHOP-241 · conversation started
It works in a sandbox, live
The specialist does a bounded job on your runner host, in Docker or a Kata microVM. Its transcript streams in your browser as it works, and a message you send reaches it after its current step. Your systems are reached through tools the server runs, so their keys stay outside.
Sandbox · Kata microVMSystem keys stay outside
readSHOP-241 · story and 2 comments
search"gift card" in SHOP · 4 issues
Refunds to a gift card and partial payment come up in older issues. Cover refunds, and ask whether partial payment belongs in this story.
writeacceptance-criteria.md · 9 criteria
askPay the rest by card, or a separate story?
answered in the inbox
WorkingRunner host
runner-02 · connects out over WebSocketThe result comes back where you look
A comment, a pull request, a document or a transition, written with the trigger's account. Questions and approvals wait in one inbox and on the issue, and the specialist continues with the same context once you answer.
ANAnalyst commented on SHOP-241The story is ready for refinement: 9 acceptance criteria, with refunds to a gift card covered.
Acceptance criteria: pay with a gift cardacceptance-criteria.md · saved with the threadDocument
SHOP-241BacklogReady for refinement
Turn ended · succeeded
Define your own specialists.
Give each one a name, a role, instructions, tools and access, and share it. Specialists do jobs. No agent manages agents. The four below are examples.
BABusiness analystFor product owners
Turns a rough story into a ready ticket: acceptance criteria, edge cases and the questions only the product owner can answer, posted on the issue.
When a story is created in PROD, Business analyst does write acceptance criteria and ask what's missing.
What comes back (example)
BABusiness analyst commented on PROD-88
Acceptance criteria
- A customer can start a return within 30 days of delivery.
- The return label is sent by email as soon as the return is accepted.
- The refund goes to the original payment method.
TETesterFor test leads
Writes test scenarios from the acceptance criteria as soon as a story moves to test, and attaches them to the story for the test lead to review.
When a story in PROD enters In test, Tester does write scenarios from the acceptance criteria.
What comes back (example)
DVDeveloperFor team leads
Implements labelled issues on its own branch, runs the tests and opens a pull request for your review. Several specialists can work on one issue at once, each in its own workspace.
When an issue in SHOP is labelled agent:dev, Developer does implement it and open a pull request.
What comes back (example)
FAFinance analystFor finance leads
Evaluates every project against plan on a schedule, and holds the report for your review before anyone else sees it. Estimates are labelled as estimates.
On the first working day of each month, Finance analyst does evaluate each project against plan, with a review before results go out.
What comes back (example)
The inbox, not a board.
Attention is the scarce resource. Your tracker stays where the work lives; Tinfirm shows you only what needs a human decision, and lets you make it where you already are: in the inbox, on the issue, or in the chat thread. Try the one on the right.
- Questions
- Answered by anyone who can write where the work is. The next turn gets every answer.
- Approvals
- Decided by you in your own conversations, by the trigger's team in shared ones. A member decides, never an agent.
- Failures
- Shown with their cause. Every turn ends in a known state; nothing fails silently.
Built for the company that runs it.
What decides whether agents get past a pilot: which models they use, what they can reach, who approves their work, and who pays for it.
Your choice of model
Any model, through your gateway
Specialists reach models through LiteLLM, bundled with Tinfirm or your own. Pick the provider, and change it without rebuilding a specialist.
Four agent runtimes
Claude Code, Codex, pi and OpenCode. A specialist lists the runtimes its instructions are tested on, and each person picks among them.
Subscriptions people already pay for
A member's own Claude or ChatGPT subscription can run their own work on their own runner host, outside the company's budgets.
Fits your systems
Your own systems as tools
Connect your company's remote MCP servers. An admin confirms whether each tool reads or writes; until then it counts as a write.
A skills library
Write a procedure once, with its scripts and templates. Specialists pin a version, so editing a skill changes no specialist until its editors move the pin.
Where people already are
Talk to a specialist in Tinfirm, from your own AI client over MCP, or in a direct message in Slack or Teams. Sign in with your own OIDC provider.
Under control
A budget per person
Every member and service identity has one key with a budget your admins set. A spent budget stops only its owner's work; nobody else's budget pays.
Kill switches
Pause a specialist or a trigger. Suspend a service identity, and everything that uses its accounts or budget stops.
No silent widening
When a shared specialist gains a tool, a system or a repository, your conversations keep the version you accepted until you accept the change.
Tinfirm runs where you run it.
It is not a cloud service. Your data, credentials, runners and subscriptions stay yours, and your systems' keys never enter the sandbox an agent works in.
Access follows the audience
When you talk to a specialist, it acts with your own accounts, so every system answers it as it would answer you. A trigger acts with the accounts its author chose.
Every action on the record
Every tool call is recorded with the account it used, whom it acted for and who approved it. Each entry carries the hash of the one before, and the app can only add and read.
Your runners, your sandboxes
Runner hosts run on your own machines or VMs, with Docker or Kata microVMs, and connect out to Tinfirm over WebSocket. Nothing calls in.
Hire your first specialist.
Tinfirm is in development and not released yet. We build it with Tinfirm itself, and we're looking for a few teams who will run it on their own infrastructure and tell us what's missing.
Request early access