The bug pipeline that starts and ends with an email The bug pipeline at this+that starts and ends with an email: a bug report is triaged by this+that, turned into a DoBox task, assigned via the Brain to the right engineer, fixed by an agent running locally via Claude Code or Codex, and closed with an automated reply to the reporter. The company contrasts its on-premises agent execution with cloud-based rivals GitHub Copilot, Linear, and Atlassian Rovo Dev, which have all converged on the same delegate-and-review loop. The bug pipeline that starts and ends with an email A bug report lands at our support address. this+that reads it, recognizes it as a bug rather than a billing question or a feature request, and turns it into a task in the DoBox. Then it assigns the task based on what the Brain, our operational knowledge layer, knows about each engineer’s capabilities and which area of the product they own. The bug goes to the person who knows the code, not into a round-robin queue. From there, the engineer hands the fix to an agent. Our desktop companion connects the task to Claude Code or Codex running on that engineer’s own machine. The agent gets its own git worktree off the local checkout, so it writes the fix without disturbing whatever branch that engineer is working on, and it opens a draft pull request. The review request goes to the task owner, and the task in the DoBox updates as each step happens, so anyone watching the queue can see where the fix stands without asking. When the review is approved, another workflow closes the loop: it replies to the person who filed the bug. It’s fixed, it ships soon, watch the changelog. From their side, it looks like it did before AI: someone fixed the bug. They probably have no idea how little work the engineer did. What is built in, and what you build That story is a workflow, and we built it ourselves. Worth separating the two halves, because they are different kinds of thing. Delegation is the built-in half. Open any task in the DoBox, pick an agent, send it. That works one task at a time, by hand, with no automation in front of it and nothing configured first. It is also where most people start and where a lot of them stay, because looking at a task and deciding an agent should take a run at it is a perfectly good way to use this. The pipeline is the half you build. Which address counts as a bug report rather than a billing question, who owns which area of the product, where a person has to approve: those are decisions we deliberately don’t make for you, because the right answer differs in every team. Read our bug pipeline as an example of what the pieces do together, not as a template you switch on. Neither half is only for code. A task holding a report, an analysis or a piece of research can be delegated exactly the same way, and most of them need no repository at all. Assigning work to an agent is now normal The middle of that story has gone mainstream, and credit where it’s due. GitHub Copilot’s coding agent https://github.blog/news-insights/product-news/github-copilot-meet-the-new-coding-agent/ takes an issue and opens a draft pull request. Linear lets you assign an issue https://linear.app/agents to Devin, Codex, or Copilot the way you’d assign it to a teammate. Atlassian’s Rovo Dev https://www.atlassian.com/rovo does the same for Jira. These are useful products, and they have all converged on the same loop: describe the work, hand it to an agent, review what comes back. When GitHub, Linear, and Atlassian all land on the same loop, the pattern has won. We made the same bet early, so we’re glad to see it validated. We differ from those three in two places: where the agent runs, and where the loop begins. The agent can run on your machine Those agents run in cloud sandboxes. The vendor spins up an environment, clones your repository into it, and the agent works there. It’s a reasonable design, it makes setup easy, and you can delegate from this+that to cloud agents too. What we add is the option to keep the work at home. Delegate a coding task and the agent runs on the assignee’s own machine, through Claude Code or Codex, in a worktree off their local checkout, on their hardware, under the subscription they already pay for. Nothing gets cloned into someone else’s compute, no copy of your repository exists anywhere but your machine, and there’s no separate metered bill for agent minutes. Claude Code and Codex run locally but still call Anthropic or OpenAI, the same as they do when you run them yourself in a terminal. If that’s a problem for your code, point delegation at a Qwen model served by Ollama on the same machine instead. Then there’s no API call at all: the repository, the model, and the work all stay on the laptop. That option is live now, and cloud sandboxes can’t offer it. The loop starts at an email The second difference is the shape of the loop. Copilot’s loop starts at an issue and ends at a pull request. Linear’s starts at a ticket and ends at a ticket. That works when the work originates inside engineering. But most work doesn’t arrive as a well-formed ticket. It arrives as a message. A customer emails support. A teammate flags something odd in Slack. Somebody replies to a thread with “is anyone else seeing this?” Before any agent can take the work, a person has to notice the message, translate it into a ticket, and file it in the right place, and that translation step is where things get dropped. So our loop starts where the work starts, at the message, and ends where it should end, with a reply to the person who asked. The tracker is in the middle of the loop, not the front door of it. The customer never files a ticket, creates an account, or watches a status page. Email in, email out. A second example, with no code in it A client asks for a summary of last quarter’s numbers. The task routes to whoever you have said owns that account, and the agent drafts the analysis in their working folder for them to review. The same goes for the report a partner is waiting on, or the follow-up doc a prospect was promised on a call. The agent drafts, a person reviews, and a workflow sends the reply. Tasks like these need no repository, and the result arrives attached to the task itself. Delegating one of these by hand is the same three clicks as delegating a bug: open the task, pick an agent, send it. Wiring it into a workflow is the same work as wiring the bug pipeline, and the decisions are yours in the same way. What counts as a request worth drafting against, whose account is whose, who signs off before anything reaches the client. Coding is where delegation matured first because the output is easy to check. A pull request has a diff and a test suite. The loop itself, message to task to local agent to reviewed output to reply, works the same whatever the deliverable is. We run our own bugs through it This isn’t a demo we built for a launch video. It’s how we fix our own product. Bug reports become tasks, we add proposed solutions to the tasks in the DoBox, and we delegate them to a coding agent on our own machines. The draft PRs come back, we review them, and the fixes ship. One thing we hold constant: every delegated fix arrives as a draft pull request, and a person reviews and merges it. Nothing technical forces that. The whole loop could run hands-off: email to task to delegated fix, a second agent doing the code review, an automatic merge, a deploy through CI/CD, and the reply to the reporter, with a model deciding up front which bugs are straightforward enough to trust to it. Models are genuinely good at that judgment call now. We keep a person in the review loop anyway, because we’ve read enough of our own agents’ diffs to know that review is where the mistakes get caught, and because reading those diffs is how the team stays current on a codebase it is no longer writing line by line. Where this goes next Today, delegation runs through our desktop companion on macOS Apple Silicon , and targets Claude Code, Codex, or a local Qwen model through Ollama. Windows and Linux are next. Key takeaways - Delegation is the built-in part and it is manual by default: open any task in the DoBox, pick an agent, send it. Nothing has to be automated first. - The bug pipeline described above is a workflow we built for ourselves, not a feature you switch on. What counts as a bug report, who owns which area of the product, and where a person approves are decisions we leave to you, because the right answers differ in every team. Build the version that matches yours. - None of it is specific to code. A task holding a report, an analysis, or a piece of research can be delegated the same way and needs no repository at all. - Assigning work to a coding agent is now an industry-standard pattern: GitHub Copilot, Linear, and Atlassian’s Rovo Dev all support it, and they deserve credit for making delegation normal. - Those agents work in cloud sandboxes, and this+that can delegate to cloud agents too. What we add is the local option: the agent runs on the assignee’s own machine macOS today through Claude Code or Codex, in a worktree off their own checkout, on the subscription they already pay for, and no copy of your repository is made anywhere else. - Claude Code and Codex still call their provider’s API from that machine. Point delegation at a Qwen model under Ollama instead and nothing leaves the laptop at all, which is the configuration for code that can’t go to a third party. - Their loop runs ticket to ticket. Ours runs email to email: a customer’s message becomes a task, the fix comes back as a draft PR for human review, and a workflow replies to the person who reported it. The tracker sits in the middle, not at the front door. - We run our own bug pipeline this way, and every delegated fix is reviewed and merged by a human. The loop could run fully hands-off, agent code review and CI/CD deploy included; keeping a person in the loop is a choice, not a limitation. Start by delegating one task by hand, and build the workflow around it once you know what you want it to do. Get started with this+that https://assistant.thisandthat.chat/signup?utm source=blog%2Fbug-pipeline-starts-and-ends-with-an-email and connect the inbox where the work already lands. Free during beta.