From an event to a known end state.
Your tracker, code host and chat keep owning the work. Tinfirm adds the specialists, their runs, the decisions and the audit trail, and every turn ends in a state you can see, with its cause. Here is one piece of work, in six steps.
- Event
agent:refineis added to SHOP-241 in Jira07:42 - TriggerRefine stories hands it to Analyst07:42
- SandboxA fresh sandbox on runner-0207:43
- QuestionCan the customer pay the rest by card?07:51
- ResultAcceptance criteria posted on SHOP-24108:06
- SucceededMoved to Ready for refinement08:06
Something happens where you already work.
Work starts from an event in a system you already use, or from a person. Tinfirm watches each system with the account a trigger names, so it sees only what that account may see.
- Jira, GitHub and GitLab: an issue or a pull or merge request is created, updated, labelled, assigned, mentioned, commented on or closed; in Jira also when it enters a status.
- Slack and Teams: someone mentions the bot in a channel. Schedules fire on a cron, webhooks when another system calls them.
- A person starts a conversation in the Tinfirm app, from their own AI client, or in a direct message to the bot.
- Changes, not states. A trigger fires once per change, polled once a minute by default, and Tinfirm's own writes never start more work.
- Lena added
agent:refineto SHOP-24107:42 - Pull request #412 opened in
shop-web07:44 - Ben mentioned
@analystin #product07:51 - Lena started a conversation with Writer08:03
- Your CRM called the webhook: deal won08:10
- Monthly review: first working day09:00
A trigger hands it to a specialist.
Each trigger reads as one sentence, and carries the accounts, the budget and the team its author chose. Anyone who may use a specialist can write one, with accounts they are entitled to.
- Every matching trigger fires, each in its own conversation. A trigger fires once per issue, or every time, continuing its open conversation there.
- Limits on floods: at most 30 firings an hour by default, up to 300. Past that, firings are skipped and the team hears about it once an hour.
- It never switches account or payer. When its author loses a right it needs, or leaves, the trigger pauses until it's fixed or handed over.
- Shared places, said plainly: whoever can write where a trigger listens can drive it. The editor says so, and suggests narrowly scoped service identities.
When the label agent:refine is added to an issue in SHOP whose status is Backlog, Analyst prepares it for refinement.
- WhenLabel addedagent:refine
- OnIssues in SHOP
- IfStatus is Backlog
- ThenANAnalystprepares it for refinement
- Accounts
- svc-analystsvc-analyst
- Paid by
- svc-analyst's budget
- Team
- Product: they see its conversations and decide its approvals
- Results
- A comment; on success, move to Ready for refinement
- Repeat
- Once per issue
It works in a sandbox, live.
Every run gets a fresh sandbox on one of your runner hosts: a container or a Kata microVM with its own limits and a clean workspace. Your systems are reached through tools Tinfirm's server runs, so their keys stay outside.
- Its own workspace and branch, such as
agent/shop-241-analyst-1. Several specialists can work on one issue at once, each in its own conversation. - What it's told: its instructions, the trigger's instruction or your request, the issue, the conversation so far and the answers. Text from issues and tools arrives as other people's words, never as instructions.
- Watch it, and steer it. The transcript streams to your browser; a message you send reaches it after its current step, without starting over.
Each guard on the way is on the Security page.
- jira_getRead SHOP-241 and the two issues it links
- jira_searchSearched "gift card": 6 issues
- read
shop-web/src/checkout/payment.ts - write
acceptance-criteria.md, 9 criteria
The default limits: a run stops at the first it reaches, or if it puts a credential in its output, and then pushes and saves nothing.
It asks when it needs a person.
A specialist doesn't guess what only a person can decide. It asks, ends its turn and waits; nothing runs in the meantime. Once the last answer is in, the next turn continues the same session with every answer.
- The inbox, not a board. Home in Tinfirm is what needs you: open questions and approvals, failed turns with their cause, accounts to connect.
- Approved calls run first, and the specialist finds the result with the answers. An approval covers this conversation, or the specialist for good if the approver may edit it.
- Reviews before results go out: a trigger can hold its result until its team approves the exact writes.
When the gift card doesn't cover the whole order, can the customer pay the rest by card?
shop-api, read only: "The payment service lives there."The result comes back where you look.
Results go back to the place the work started, written with the account the trigger chose, in the order they were made. Writes are retried for up to an hour and recorded in the audit log; one that still fails is posted in the conversation.
- On an issue: a comment signed with the specialist's name, then the trigger's actions: a transition or documents in Jira, labels or closing on GitHub and GitLab.
- In a chat: the bot's reply in the thread. In Tinfirm or your AI client: the conversation itself.
- Pull and merge requests: the runner host pushes the specialist's own branch with a lease check, never a force push, and Tinfirm opens the request.
- Schedules and webhooks: outputs in Tinfirm, with a review when the trigger asks.
- A customer can apply one gift card at checkout.
- A refund to a gift card goes back to that card.
- Paying the rest by card is a separate story, SHOP-252.
Every turn ends in a known state.
Nothing fails silently. A turn finishes, fails with its cause, is cancelled, or waits on someone, and the people who can act on it are told where they look.
- Told where they look: a note in the conversation, an item in the inbox and, on an issue, "Analyst could not finish this: time limit reached. The team of Refine stories was told."
- Retries that make sense: a turn stopped by its time limit retries from where it stopped. If you turn it on, a turn that failed because the provider was limiting, or its runner host restarted, retries by itself up to three times.
- A spent budget stops only its owner: that person's or service's conversations wait until it resets or an admin raises it.
- SucceededSHOP-241Finished with a summary, next steps and open questions.
- WaitingSHOP-244On a question to the product owner.
- FailedSHOP-238Time limit reached. A retry continues from where it stopped.
- CancelledSHOP-230By Lena. The conversation stays open.