This article walks through how that works in practice: the setup, what happens to a single ticket, how dozens of changes from people and agents land on the same main branch every day without queueing behind each other, what happens when something breaks, and what the people on our side still do. It also shows what we measured, and what we learned that you can use in your own team.

A word on what Dutopilot is, so the rest makes sense. Dutopilot is a managed service and software as a service in one. It is a layer above coding agents: it runs Claude Code, Codex, OpenCode and Oh My Pi on your own AI account, on dedicated cloud infrastructure, and every customer gets a Forward Deployed Engineer who sets it up around your backlog and stays with you. Each agent is a Dutopilot virtual team member, and each one can run hundreds of parallel sub-agents, on every plan. You keep the project board you already use. The agents do the delivery work.

Why build the product with itself

There are three reasons, and the first one is not marketing.

The first reason is honesty. A delivery tool that has never carried its own maker's work has not been tested on the hardest customer there is: one that changes its mind daily, files vague tickets, merges in a hurry and notices every slow minute. When our own product waits on a stuck review, we feel it that afternoon. That pressure is a better test suite than any we could write on purpose.

The second reason is feedback speed. When an agent stalls, loops or produces a change we would not accept, the person who can fix Dutopilot is the same person who just felt the problem. There is no support queue between the pain and the repair. A defect we find becomes a ticket on the board right away, and the fix follows through the same pipeline.

The third reason is proof you can inspect. When we say the pipeline holds up under many changes at once, we are describing our own repository, where people and agents merge into the same main branch all day. We are not describing a demo project built to look good.

None of this means every customer should expect our exact setup. Customers choose their own approvals, their own board and their own repositories. What carries over is the method: a ticket goes in, a verified and merged change comes out, and a person steps in only at the gates that matter to you.

The setup: a board, a repository and a clear split of work

The setup is deliberately plain, because a customer has to be able to copy it.

The project board

All work starts as a ticket on a project board. The board is where people say what they want: a new capability, a fix, a change to wording. A ticket is written in ordinary language, the way you would brief a colleague. It does not need to be a specification. If something important is missing, the planning step asks.

The repository

The product's code lives in one repository, which the hosted Dutopilot service reads and changes through a permission grant, the same way it would for a customer. Our repository gets no special back door. If a step works for us, it works through the same path your repository would use.

Each change is a small, separate piece of work that goes straight to the main branch. We do not keep long-lived integration branches or a big combined release change at the end. Smaller pieces mean smaller reviews, easier undoing and no pile-up where one late piece blocks ten finished ones.

What people do and what agents do

The division is simple to say. People decide what is worth doing and where a human must say yes. Agents do the delivery work in between.

• People: write and prioritise tickets on the board, answer questions an agent could not settle alone, approve the steps they chose to keep behind a human gate, and make product decisions.
• Agents: refine the ticket, plan it, split it when it is large, write the code and the tests, review each other's work, run the quality checks, repair failures, merge and deploy.

Behind this sit your AI accounts. Dutopilot runs Claude Code, Codex, OpenCode and Oh My Pi on your own subscription or key, so the cost of the AI work goes to an account you control and you see exactly where it goes. The agents in your plan do not share one narrow pipe. Each plan agent behaves like a Dutopilot virtual team member that can hand parts of a job to as many parallel sub-agents as the work needs.

A ticket's life, step by step

Here is what happens to one ticket, from the moment it is ready to the moment it is live. A ticket passes through nine stages in all: architect, planner, implementer, gate, three reviewers, autofixer and QA. We describe the path in the order you would see it. The seven numbered steps below group those nine stages, and the eight cards in the picture show the same journey.

1. Refining and planning

When a ticket is marked ready, an agent reads it together with the parts of the repository it touches. Its first job is not to write code. Its first job is to check that the ticket can be built: is the goal clear, is anything contradictory, is a decision missing that only a person can make?

If the ticket is clear, an architect agent and a planner agent turn it into a plan: what to change, in which order, what could go wrong and how to know it worked. A large ticket is split into smaller tickets, each one something that can be built, reviewed and shipped on its own. The split matters: small tickets finish faster and cost less to review, and a problem in one does not hold back the rest.

If something only a person can decide is missing, the agent asks, in plain words, on the ticket. A reply in the person's own words is enough. Nobody has to learn special phrases.

2. Building in an isolated sandbox

Building happens on dedicated cloud infrastructure, in a sandbox made for that one ticket. The sandbox gets a fresh copy of the repository, does the work and is thrown away afterwards. Nothing from one ticket's run can leak into another's.

Inside the sandbox, a coding agent (Claude Code, Codex, OpenCode or Oh My Pi, on your account) writes the change and the tests that go with it. Because the work is split across sub-agents, one can handle the data side while another handles the screen, and a third writes the tests, all in the same sandbox. Before it writes anything, the sandbox merges the latest main branch into its working copy. We come back to why that moment matters in the section on working at scale.

3. Independent review

When the build is done, the change is opened as a pull request, which is the standard way to propose a change for review. The reviewers are separate agents that did not write the code. They read the change with fresh eyes, compare it with the ticket and with the plan, and look for mistakes, missed cases, risky shortcuts and changes that wander beyond the ticket.

The point of separating the reviewer from the author is the same as with people. An author reads what they meant to write. A reviewer reads what is actually there.

4. Quality gates

Alongside the review, a set of quality gates run. A gate is an automatic check with a clear pass or fail: the tests, the type and style checks, a check that the change touches what the plan said it would, and checks on things like security and the look of the pages.

5. The self-repair loop

When a reviewer finds a problem or a gate fails, the ticket does not go back to a person. It goes to a repair stage. A fixing agent reads the exact failure, changes the code, and sends the change back through review and the gates. This loop repeats as long as it is making progress. If the same failure keeps coming back without progress, the approach changes instead of trying the same thing again, and if it still cannot be resolved the ticket stops with a plain explanation that a person can act on.

6. Merge

When every gate is green and the review is clean, the change merges into main. Merging is squash-and-merge, so each ticket becomes one clean entry in the history, which makes it easy to read and easy to undo. If you chose to keep a human approval before merging, the ticket waits for that approval instead and tells the person exactly what they are approving.

7. Deploy

For our own product, a merge to main is a release: the deployment starts on its own and puts the change into production. The ticket is closed only when the work is actually live and checked, not when the pull request merges. If a deployment check fails, that is treated like any other failure: it comes back as work for the agents, not as a message that waits for a person to notice. On client projects the work stops at staging or test, a person releases, and the ticket finishes there.

A worked example (illustrative)

Working at scale: many tickets, many people, one main branch

A single ticket moving through a clean pipeline is the easy case. The real test is many tickets at once while people also merge into the same repository.

On our repository, many tickets are in flight at the same time, each in its own sandbox, and our own people merge their own changes into main throughout the day. Every one of those merges changes what main looks like. A system that works only when one change moves at a time would spend most of its life waiting. Each Dutopilot virtual team member can run hundreds of parallel sub-agents, on every plan.

Why nothing waits for a branch to catch up

A common rule in software teams says a branch must be up to date with main before it can merge. With a handful of people that is a small nuisance. With dozens of changes arriving all day it becomes a trap: the moment any change merges, every other open change is out of date again, and has to be refreshed and re-checked. Under heavy traffic that loop never ends, and people spend their day pressing update buttons.

We refuse that rule on purpose. Instead, every agent merges the latest main into its own work at the moment it needs it: before it writes code, and again right before the final checks. The agent establishes for itself that its work is compatible with the current main, instead of waiting for anyone to refresh its branch.

If main moved while the work was in progress and the two changes do not touch each other, nothing more is needed. If they do collide, the agent resolves the conflict in its own copy, reruns the checks, and carries on. The cost is paid by the one change that actually collided, and only when it collides. Everyone else keeps moving.

The same idea applies to every shared resource

We apply the same test to everything that several changes share: the pool of sandboxes, the number of requests we may send to the code host, the AI accounts, the queue of work. The questions are always the same. Does this still work with dozens of writers at once? Does every wait end on its own? Does the cost of each cycle grow with the amount of active work, rather than with the size of the whole backlog?

A design that is correct for one ticket at a time but stalls or needs a person when many tickets arrive is, for us, a wrong design, however safe it looks. That is the first test every decision on our own product has to pass, and it is the reason the setup holds up when a customer connects a busy repository.

How many tickets one AI account can carry is in Today's numbers, further down.

When things go wrong

Things go wrong in any delivery pipeline. A test that was already flaky fails, a service is briefly unavailable, an agent misreads a ticket, a change collides with another. What matters is what happens next, and whether a person has to notice first.

Self-repair first

Most failures are handled by the repair loop described above. A failed check is read, understood and fixed by an agent, and then checked again. On our first client projects, agents repaired 150 stage failures by themselves (the figures are in the numbers section). Each of those is a moment where, in a more traditional setup, a person would have had to notice a red build, work out whose problem it was and chase a fix.

Defects Dutopilot finds in itself become tickets

Dutopilot watches its own behaviour. When it detects a defect in itself, for example a ticket that sits waiting for no reason, or a step that keeps failing the same way, it reports the problem as a ticket on its own project board, tagged so it is clear that it came from the system. That ticket is then planned, built, reviewed and merged by the same agents like any other. The loop in the diagram at the top is real: production behaviour flows back into the board, and from there into the next change.

This is also why we trust the setup in our own repository. A problem does not live in somebody's memory or in a chat thread. It is a ticket, with an owner, a plan and a status.

Some real examples of defects Dutopilot reported against itself and then fixed. It filed its own report that a scheduler loop had hung, and fixed it. The dashboard once told a customer to fix their setup when the fault was Dutopilot's own, and it corrected that so the right party is blamed.

Stops a person can resolve alone

Sometimes the right move is to stop and ask. A decision is missing, a choice has consequences, or a gate you selected needs a human. When Dutopilot stops, we hold it to a standard we call self-serve: the person reading the notice must be able to resolve the stop on their own, with no documentation and no help from us.

• The message says in plain words what happened, before any technical detail.
• It says whose problem it is: their change, or the setup.
• It offers the one thing they can do. Where there is a sensible default, it takes it and tells them, with an easy way to undo.
• A reply in the person's own words works. There is no special command and no hand editing of anything.

The technical detail (the name of the check, the setting involved) comes last, for the administrator. A notice that must be shortened loses the technical detail first and never the plain explanation.

What people still do

Automation that pretends people are unnecessary is not credible, and it is not what we built. People still do the three things that only people can do.

• Choose the work. What goes on the board, in what order, and what is not worth doing at all. Priority is a business decision. An agent can estimate effort. It cannot know what your market needs this quarter.
• Approve where you chose to. You pick which steps stay behind a human gate: a plan, a design, a merge, a release. A gate you select is a real gate. The agents wait for it and tell the approver exactly what they are approving. Steps you did not select are decided by Dutopilot when it is confident, with a clear record and an easy way to reverse it.
• Make product decisions. Whether a feature exists, how it should feel, which trade-off to accept. Agents turn those decisions into working software. They do not replace the judgment behind them.

The effect is a different kind of workday. People spend their time on decisions and priorities. They read short explanations instead of long diffs. They stop babysitting builds.

The numbers

Numbers only help if they are specific about what they count. We give two separate sets and we do not blend them.

Across our first client projects

These figures come from our first client projects. They were not measured on Dutopilot's own repository, and we do not present them as if they were. Numbers for our own repository are measured separately and appear in their own box below.

Since June 2026

Since June 2026, agents have merged 127 tickets and completed 539 agent tasks across our client projects. Those projects are serpent.cloud, the website of a services company, and a monorepo that combines Salesforce and a native iOS app. The last two are not named here. Each project has its own setup and its own approvals, and on client projects the work stops at staging or test and a person decides when to release. Read the figures as breadth, not as one project's pace.

On the current release, since 19 August

A second, narrower set was measured on the same client projects with the current release, from 19 August onwards:

• 0.4% of commits on the work branches were written by a human. The rest were written by agents.
• 2% of tickets needed a human approval.
• 54 minutes was the median time from first commit to merge.
• 150 stage failures were repaired by the agents themselves.
• 9 stages make up a ticket's path.

The low share of tickets needing an approval comes from how those projects configured their approvals. It is a setting, not a ceiling. If you want a person on every merge, you can have that, and the numbers will then look different, by choice.

Lessons learned, for your team

These are the lessons from building this way that transfer to any team that wants to hand delivery work to agents.

Write tickets for a capable colleague

The quality of the output follows the quality of the ticket. A ticket that states the goal, who it is for and how you will know it worked gets built well. A ticket that says "improve the dashboard" gets a clarifying question first. That is a good outcome, and it is cheaper than a wrong build.

Keep every change small

Small tickets pass review faster, fail less often and are easy to undo. When a piece of work is large, the planning step splits it. Do not fight that split. A large change is a risk you would otherwise carry for days.

Let separate agents review

The agent that writes the code should not be the agent that approves it. Independent review catches the mistakes the author cannot see, and the findings go straight into the repair loop instead of onto a person's desk.

Make checks plain code

Anything with a clear right answer, such as whether a test passed or whether a file changed, should be decided by ordinary software, not by a model's opinion. Use models for the judgment tasks: reading a change, deciding whether it matches the ticket.

Design for many at once from day one

A pipeline that is fast for one ticket and stuck for ten is not fast. Test every rule against the busy case: no waiting for a branch to be current, no shared slot that is never released, no wait that needs a person to end it.

Choose your human gates on purpose

Decide which steps need a person and make those gates real. Everything else should move on its own with a clear record. A gate that is selected but easy to bypass teaches people to ignore gates.

Treat a stop as a message to a customer

Every time the system stops, write the notice as if a person who has never heard of the tool will read it. If they cannot act on it alone, the notice is not finished.

What this means for your team

You do not have to run a setup like ours to benefit from it. The practical version is a managed one.

You keep your project board and your repositories. Dutopilot connects to them (Jira, Linear, Notion, GitHub Issues or Azure DevOps for the backlog; GitHub, GitLab, Bitbucket or Azure DevOps for the code; Slack for notices), and your own AI account pays for the AI work, so the cost stays in your hands. The agents run on dedicated cloud infrastructure that we manage, and each ticket gets its own sandbox. Each Dutopilot virtual team member on your plan can orchestrate hundreds of parallel sub-agents, on every plan. The number of tickets in flight follows how many Dutopilot virtual team members your plan has (Solo up to 3, Team up to 15, Enterprise no limit) and your approvals. Plans are priced by Dutopilot virtual team members, not by users: your whole team can use Dutopilot.

The Forward Deployed Engineer

Every customer gets a Forward Deployed Engineer, an engineer from our side who works with you rather than a support desk you queue behind. They connect your board and repositories, read your codebase and your conventions, set up the checks and approvals you want, and tune the agents to your way of working. They also stay after launch: they watch how your first tickets flow, adjust where agents stall, and help you decide when to loosen or tighten a gate.

In practice, that means you get Dutopilot virtual team members and an engineer who knows how to make them work in your codebase, instead of a tool you have to learn alone. The best first step is small: one project, a few tickets and the approvals you are comfortable with.

Frequently asked questions

Does Dutopilot really build Dutopilot?

Yes. The product's own repository is connected to the hosted Dutopilot service like a customer's. Tickets on its project board are planned, built, reviewed, tested, fixed and merged by agents, and every merge to main deploys to production.

Are people involved at all?

Yes. People choose the work, approve the steps they decided to keep behind a human gate, and make product decisions. Agents do the delivery work between those points.

What happens when an agent gets something wrong?

A reviewer or a quality gate catches it, and a fixing agent repairs it and sends it back through the checks. If it cannot be resolved, the ticket stops with a plain explanation that a person can act on alone.

Can I run the same setup on my own backlog?

Yes. You keep your project board and repositories, and Dutopilot runs Claude Code, Codex, OpenCode and Oh My Pi on your own AI account. A Forward Deployed Engineer sets it up around your backlog and the approvals you want.

How do many tickets and many people merge into one main branch?

Each agent merges the latest main into its own work at the moment it needs it, instead of waiting for its branch to be refreshed. That way no change waits for another, and a busy repository keeps moving.

What AI review does well and what people do better

Use that split to decide where a person must stay involved. Routine checks go to the AI. Judgment calls stay with people.

Five layers around every pull request

No single check should carry the decision. A safe setup stacks layers that each catch something the others miss, and the pull request has to pass all of them in order.

1. Automated checks: lint, build and tests give a pass or fail that nobody can argue with.
2. Reviewer agents: separate agents read the change and comment on what looks wrong.
3. Fix loop: findings go back to a fixer, and the checks and reviewers run again.
4. A person: someone you named approves changes in the areas where a mistake is costly.
5. Branch protection: your code host enforces required checks and reviews, whatever any agent says.

The risks to plan for

• A false approval: the reviewer says the change is fine when it is not.
• Being misled: text hidden in a ticket, a comment or a file can try to steer the reviewer. OWASP lists prompt injection as the first risk in its list of risks for applications built on large language models.
• Too much access: a reviewer that can read secrets or change production can do harm if it is misled.
• Marking its own homework: an agent that reviews the code it wrote tends to agree with itself.

A safe setup, step by step

1. Separate the author from the reviewers. The agent that wrote the change never approves it, and more than one reviewer is better than one.
2. Let reviewers comment, not edit. Findings go back to the author to fix, so every change has one owner.
3. Keep automated checks as the gate. Tests, type checks and quality checks must pass again after every fix. On GitHub, branch protection can require passing checks and approving reviews before anything merges.
4. Limit access. Run the agents in a sandbox with no production secrets and only the permissions the work needs.
5. Choose where a person must approve, such as sensitive areas of the code and the production release.
6. Keep a record. Every review comment, fix and approval should be visible on the pull request.

A worked example: a refund endpoint

An illustrative ticket, PAY-301, "Add a refund endpoint": an agent builds it and opens a pull request. This is what each layer does with it.

Notice that the reviewers never edited the code, and that no single layer approved the change alone. In a case like this, the two findings are the kind a tired person skims past on a Friday afternoon.

What happens inside the fix loop

A finding goes to a fixer agent together with the exact comment or failing log. The fixer changes the code, the checks run again and the reviewers read the new version. This repeats until everything is green.

Two safeguards keep the loop honest. If a fix stops getting closer to green, or the risk of the change goes up, the run stops and asks a person instead of trying again. And a test that fails at random is retried and repaired automatically, so one unreliable test does not block a good change.

How Dutopilot does it

In Dutopilot, separate Dutopilot virtual team members, who did not write the code, read each pull request. What they find goes to an automatic fix step, and the tests and quality checks run again before anything merges. The code is processed in a sealed sandbox, and your own branch protection and required reviews keep applying unchanged.

People decide the architecture before code is written and the production release, and you can add approvals anywhere else. Every run leaves a trail in your pull requests. See which steps need a person's approval for how to choose.

What reviewers are allowed to do

• They read the change and the code around it, and they write comments. They do not push code.
• They run in a sealed sandbox with no production secrets.
• They are different Dutopilot virtual team members from the one that wrote the change, so none marks its own homework.
• A single reviewer opinion never merges anything alone. Approvals and merge happen only where you chose, and the automated checks and your branch protection decide.

What you set up

• Branch protection on your main branch, with the checks you already run marked as required.
• A list of approvers, and the parts of the code, such as payments or sign-in, that always need one.
• The strictness you want: which kinds of problem reviewers should block on and which they should only mention.

What your Forward Deployed Engineer does

Every Dutopilot customer gets a Forward Deployed Engineer: an engineer from Dutopilot who works with your team. They do not write your product code. They make review fit your codebase and your habits.

• They tune what the reviewers look for in your codebase, such as your security rules and naming conventions.
• They choose with you which parts of the code need a named approver.
• They read the first month of review results with you: what the reviewers flagged, what people flagged afterwards and what slipped through.
• They tighten or loosen approvals based on that record, and keep tuning as your code and team change.

How to tell whether it is working

Keep a simple record for the first month. For each pull request, note what the AI reviewer flagged, what a person flagged afterwards and whether anything slipped through to a later fix. If people keep finding real problems the AI missed, tighten the setup. If the AI findings are mostly noise, adjust what you ask it to look for before you trust it with more.

Start small and widen

Begin with AI review on a low-risk part of the code, with a person still approving every merge. After a few weeks, look at how often the AI found real problems and how often it missed one that a person caught. Loosen approvals where the record is clean, and keep them where it is not.

Frequently asked questions

Should AI review replace human review?

Not for changes that are costly or hard to undo. Let AI catch the routine problems so people spend their time on judgment, such as whether the change is the right one.

Can an AI reviewer approve and merge on its own?

Only where you choose, and only for low-risk changes. Approvals and merge happen only where you chose them, and a single reviewer opinion never merges alone: the automated checks and your branch protection stay the gate. Start strict and loosen only after you have seen the results.

What about secrets and customer data?

Keep them out of the reviewer's reach. In Dutopilot, code is processed in a sealed sandbox, we never keep a copy of your repository, and run logs and check results are deleted after 90 days.

Start by sorting the backlog

Agents do not need a perfect backlog, but they do need tickets they can finish. Sorting the backlog into four groups before you start saves most of the wasted runs.

Jira can help you find the first candidates. Its query language, JQL, lets you save a filter that lists tickets by status, label or age, as described in Atlassian's JQL guide. Start with a filter for small tickets that already have a clear description.

What a ticket an agent can finish looks like

Here is an example, written the way a product owner would write it in Jira. It is small, it says what done means and it names where the work lives.

That takes about a minute to write. Without the last three lines it is the kind of ticket an agent has to guess at, and guesses are where rework comes from.

One ticket, step by step

Here is PAY-214 going through the nine stages of the Dutopilot pipeline: architect, planner, implementer, gate, three reviewers, autofixer and QA. Before the first stage, people set the human gates once per project and the ticket is picked up. After the last, a person releases to production.

Two points wait for a person by default: the plan and the production release. Everything between them runs without anyone watching, and every stage writes to the ticket, so you read the story afterwards instead of attending it.

Keep many tickets moving without collisions

The hard part of a large backlog is not one ticket, it is many at the same time. Give every ticket its own branch, let tickets that depend on each other wait for the one they need, and limit how many run at once to what your team can review. If two tickets touch the same files, run them one after the other.

Say PAY-215 is an export button on the dashboard that needs the endpoint from PAY-214. Mark it as blocked by PAY-214 in Jira and it waits, then starts from code that already contains the endpoint. Two unrelated tickets, such as a copy change and a new report, run side by side without noticing each other. Before it starts, each ticket brings in the latest code from your main branch by itself, so no ticket waits for someone to refresh a branch by hand.

What you set up

• Connect your Jira project and your code host (GitHub, GitLab, Bitbucket or Azure DevOps).
• Choose the slice of the backlog to start with, for example one label or one saved filter.
• Name who approves the plan and the production release, and any parts of the code that need a named reviewer.
• Connect your own Claude Code, Codex, OpenCode or Oh My Pi subscription.

Most teams run their first ticket within a week.

What your Forward Deployed Engineer does

Every Dutopilot customer gets a Forward Deployed Engineer: an engineer from Dutopilot who works with your team, not a support queue. They do not write your product code. They make the pipeline fit the way you already work.

• Onboarding: they connect your tools with you and choose the first slice of the backlog.
• Ticket readiness: they go through the first tickets with your product owner and agree a short template like the one above.
• Approvals and gates: they set which plans and which parts of the code need a person, and which do not, based on how your team really reviews.
• First runs: they watch the first tickets with you and fix whatever stalls a run.
• Ongoing: they look at stalled tickets and review findings with you, and loosen or tighten the gates as the record shows.

How Dutopilot does it

Dutopilot connects to your Jira backlog and works through it with its nine-stage pipeline: it plans the change, builds it in a sealed sandbox, has it reviewed by three separate reviewers, runs the tests and quality checks, fixes what fails and merges when the approvals you chose are in. Every stage is written back to the ticket, so the backlog always shows where each ticket stands.

Your branch protection and required reviews keep applying, and we never keep a copy of your repository. Besides Jira, Dutopilot works with Linear, Notion, GitHub Issues and Azure DevOps for the backlog, and with Slack. The guide on going from a Jira ticket to a merged pull request shows one ticket from start to finish.

Common reasons a run stalls

• The description has no acceptance criteria, so the agent has to guess what done means.
• The ticket mixes two jobs, so the pull request grows too large to review.
• The tests are slow or flaky, so nobody can tell whether the change works.
• No approver is named, so a finished pull request waits.

Fix these in the backlog and the success rate goes up without any change to the agent.

Where people stay in charge

• Before code is written: a person decides the architecture of anything new or risky.
• At merge: a named person approves changes in the areas that matter most.
• At release: the production release follows your own process.

Add approvals anywhere else you want one, and remove them as trust grows. The guide on choosing which steps need approval explains how to decide.

Frequently asked questions

Do AI agents need a clean backlog?

No, but each ticket an agent picks up needs a clear outcome, a small scope and a way to check it. Leave the messy tickets in the backlog and sort them first.

What happens when an agent gets stuck?

A good setup makes the agent say so on the ticket and stop, instead of guessing. In Dutopilot the ticket shows what is blocking it and what a person can do, and a reply from a person lets the work continue.

Can we use our own AI subscription?

Yes. Dutopilot runs on your own Claude Code, Codex, OpenCode or Oh My Pi account, so Dutopilot virtual team members work under the terms and limits you already have.

How long until the first ticket runs?

Most teams run their first ticket within a week: connect the backlog and the project, point Dutopilot at one slice of the backlog, then widen from there.

Connect in the Claude app

These steps work on the Free, Pro and Max plans.

1. In Claude, open Plugins in the left sidebar.
2. Click Add, then Add custom connector.

   

3. Name it Dutopilot, paste https://app.dutopilot.com/mcp as the MCP server URL, and click Continue.

   

4. Claude opens the Dutopilot sign-in page. Click Send me a code, enter the 6-digit code from your email, and allow access.

   

5. Back in Claude, Dutopilot shows as Connected on its plugin page.

   

Free plans allow one custom connector.

On a Team or Enterprise plan

Turn it on in a chat

Click the + in the message box, choose Plugins, and switch Dutopilot on. Tool access in the same menu lets you choose which tools Claude may use.

Desktop and mobile

Once you add the connector on the web, it also works in the Claude desktop and mobile apps. There is nothing extra to set up.

Connect in Claude Code

In Claude Code, one command adds the connector:

claude mcp add --transport http dutopilot https://app.dutopilot.com/mcp

Then run /mcp in Claude Code, choose dutopilot and sign in with the emailed code.

The tools, in plain words

The connector has seven tools, in two groups. The two admin-only tools are marked.

Claude groups the tools the same way, as read-only and write/delete. On the connector's Permissions tab you choose, per tool, whether Claude asks you first.

Everyone on a Dutopilot project can connect and use the read tools. Filing a ticket needs at least the Member role, the actions a ticket offers depend on your role, and two tools are admin-only; they are marked above.

Your chat history stays yours

The server cannot read your chat history. It receives only what the assistant puts into a tool call, such as the text of a ticket you ask it to file. The rest of your conversation stays between you and the assistant. The privacy page has the details.

Disconnecting

You can disconnect at any time from the connector settings of your assistant. A connection that sits idle expires after 7 days.

Questions and help

Anything unclear, or something that does not work, write to support@dutopilot.com.

Start with a ticket an agent can finish

A good first ticket has a clear outcome, a small scope and a way to tell it worked. "Add an export button to the orders page" works. "Improve performance" does not. If a person on your team could finish the ticket in a day without asking questions, an agent probably can too.

Before you hand a ticket over, check three things: the description says what done looks like, the affected area of the code is named or easy to find, and any tests that should pass are listed.

The five steps

1. Read: the agent reads the ticket, the linked pages and the relevant parts of the repository.
2. Plan: it writes down what it will change and which tests it will add. This plan is short enough for a person to read in a minute.
3. Build: it makes the change on its own branch, runs the tests and fixes what fails.
4. Review: a second agent reads the pull request the way a teammate would and leaves comments. The first agent answers them.
5. Merge: once checks pass and the people you named have approved, the pull request is merged and the ticket moves on.

Keep every step visible

The ticket should show what happened: the plan as a comment, a link to the pull request, and a note when the agent is stuck. Your team should never have to ask "where is this?". If the status lives only in a chat window, it will be lost.

What to review as a person

You do not need to read every line the agent wrote at the start, but you do need to decide where a person looks. Most teams start by reading the plan and the pull request, then relax the plan check once the agent has earned trust on that kind of ticket. The guide on choosing which steps need approval covers this in detail.

Common reasons a ticket stalls

• The description leaves out the acceptance criteria, so the agent guesses.
• The ticket mixes two jobs. Split it into two tickets.
• The tests are slow or flaky, so the agent cannot tell whether its change works.
• Nobody was named as the approver, so the pull request waits.

Fix these in the backlog and the agent's success rate goes up without any change to the agent.

What bring your own means

You hold an account with the model provider, such as a Claude Code, Codex, OpenCode or Oh My Pi subscription, or an API key. The delivery tool uses that account to run the agents. Your provider bill shows exactly what the agents used.

Why teams choose it

• Cost you can see: usage appears on your own provider account, so there is no hidden markup on model use.
• Control: you decide which model runs, and you can change it when a better one ships.
• Existing agreements: if your company already has terms with a provider, those terms keep applying.
• Predictable planning: a flat subscription is easier to budget than usage you cannot see.

What you still pay the delivery tool for

The delivery tool covers the work around the model: reading the backlog, planning, running agents in parallel, review, and keeping the ticket up to date. Model usage is separate and stays on your account. Delivery Autopilot works this way: its packs cover the agents and the workflow, and model usage runs on your own subscription or key.

How to size a subscription

Start with a small number of tickets and watch usage for a couple of weeks. Look at how much one typical ticket uses, then multiply by the tickets you expect each month. Leave headroom for tickets that need a second try.

Questions to ask before you start

• Which provider and plan does my company already use?
• Who owns the account, and who can see the usage?
• Is the code used to train models under our plan?
• What happens when the plan's limit is reached mid-ticket?

Write the answers down once. They are the same for every ticket that follows.

Ask two questions about each step

1. How costly is a mistake here? A typo in a comment is cheap. A change to billing logic is not.
2. How easy is it to undo? A draft pull request can be closed. A released change is harder to take back.

Steps that are cheap and easy to undo can run without approval. Steps that are costly or hard to undo need a person.

A starting point most teams use

• Plan: a person approves it for new kinds of work, and skips it for work the agent has done well before.
• Build: no approval needed, the agent works on a branch.
• Review: automated, with a person reading the pull request.
• Merge: a person approves, always, for the areas that matter most.
• Release: follows your existing process.

Name the approver

An approval without a name attached waits forever. For each step that needs one, pick a person or a small group, and say how long they have. If nobody answers in that time, decide in advance whether the work waits or escalates.

Loosen approvals over time

Start strict. After a few weeks, look at which approvals were always granted without changes. Those are candidates to remove. Look also at the ones that were often rejected: they show where the agent or the ticket needs help.

Keep a record

Whatever you choose, the backlog item should show who approved what and when. That record is useful for your team, and it answers the questions customers and auditors ask.