this+that for engineers
You already have the agent. You are still the pipeline.
Bug reports don’t arrive as well-formed tickets. They arrive as an email to support, a message from a colleague, a customer complaint in a thread. Somebody reads it, works out what it means, files it, finds the owner, and answers the reporter when it ships. That somebody is you, several times a week. Handing the fix to an agent on your own machine is built in. The triage in front of it is a workflow you build once.
The work doesn’t start in the tracker
A coding agent takes a well-specified issue and returns a pull request, and it does that well. But something has to produce the well-specified issue, and on most teams that something is a person reading a support inbox and translating. The report is three sentences and a screenshot, half of it is the reporter guessing at a cause, and the actual repro is buried in the fourth reply. Turning that into an issue takes ten minutes and knowledge of the codebase, which is why it lands on an engineer.
The other end leaks too. The fix merges, it ships, and the person who reported it hears nothing, because closing the loop means finding the original thread and writing back, and the thread is in a system nobody has open. So the same bug gets reported twice, and the second report goes through triage from the start.
Message in, reply out, agent in the middle
Delegation itself needs no setup. Open a task, pick an agent, send it. The pipeline below is what you build around it, and this is the version we run against our own support inbox. Which inbox, who owns what, and where a person has to approve differ on every team, so we don’t make those decisions for you.
The report lands
Reading every message that arrives is automatic, and so is telling a bug report apart from a billing question. The AI classifies it, and it has an easier job when you point the workflow at one address or one channel.
It becomes a task
The report turns into a task with the original thread attached, so nothing is lost in translation and the repro steps stay one click away.
It routes to whoever owns the code
Assignment comes from what you’ve written in the Brain, which engineer owns which area. We ship no opinion about who owns your code, so it goes to the person who knows it instead of a round-robin queue.
The owner hands it to an agent
Our desktop companion gives the task to Claude Code or Codex on that engineer’s own machine. The agent gets its own git worktree off the local checkout, so whatever branch they’re on stays untouched.
A draft PR comes back
The agent opens a draft pull request and the review request goes wherever your workflow sends it. Nothing merges without a person deciding to commit it.
The reporter gets an answer
Once the review is approved, a workflow replies to the original email. It’s fixed, it ships soon, watch the changelog. The person who filed it has no idea how automated this was.
On your machine, on your subscription
Delegated agents usually run in a cloud environment the vendor provisions. That’s a reasonable design and we support it too. Our approach adds another option. The agent works in your own local checkout, on your hardware, through Claude Code or Codex, under the AI subscription you already pay for. Nobody copies your repository anywhere else, and there’s no metered bill for agent compute.
If even the model calls have to stay home, point delegation at a Qwen model served by Ollama on the same machine. Then the code, the model and the work never leave the laptop. That works today.
The engineering tools it already connects to
Every one of these is reachable from a workflow as an action step, so the loop does not stop at the tracker. Each has its own page with the specifics.
GitHub
A built-in MCP server, so any workflow can create issues, check PR status, comment on threads and query open issues by label or assignee. Triggers scope to a single repository, so a flow built for one service stops firing on every other.
Learn more →Linear
A bug report that arrives by email becomes a Linear issue with the thread attached. Workflows find, create and update issues, projects and comments through Linear’s own MCP server.
Learn more →Jira and Confluence
Through Atlassian Rovo, an email or a Slack message becomes a Jira ticket, a Confluence page or an assignment, without anyone retyping it into a second system.
Learn more →Notion
Connected over MCP alongside GitHub, so release notes can draft themselves from the descriptions on merged PRs.
Learn more →Sourcegraph
Code search across your repositories, as a built-in MCP server. A workflow can find where a reported bug actually lives and hand the engineer that context along with the ticket.
Learn more →Glean and Snowflake
Enterprise search and warehouse queries, both built in, both pointed at your own instance. Answer a data question inside the thread that asked it.
Learn more →DoBox over MCP
The connection runs the other way too. Your own agents read and write DoBox over MCP, so the task list the workflow feeds is reachable from whatever you already run in your terminal.
Learn more →The channels reports arrive on
Not every report comes by email. Gmail, Outlook, Slack, Microsoft Teams, Google Chat, and WhatsApp Business all feed the same loop, so a bug flagged in chat gets the same treatment as one sent to support.
Learn more →The same loop without a repository
Delegation is not limited to code. Hand an agent a report, an analysis or a piece of research and it works on the real file and comes back for review, with the result attached to the task and no repository involved. The pipeline is the same shape: it arrives as a message, a person approves what comes back, and whoever asked gets an answer.
Point it at the inbox your bugs actually arrive in.
Connect an account and watch the reports already buried in it become tasks. Free during beta, no credit card required.