Developer Support Moves From Chatbots to Three Roles for AI Agents

Two years ago, "AI in support" meant a chatbot with buttons that answered from a template and annoyed users. In 2026, developer support teams are building a different setup. It is not one smart bot but three groups of agents with different jobs. The first digs through logs and code, the second gathers context for the engineer, and the third opens a Pull Request with a fix on a human's command. A recent Habr article describes the trend. Its announcement includes no efficiency measurements, so what follows covers the architecture and the logic of the approach, not proven percentages of savings.

Three roles instead of one bot

The main change is the division of labor. The classic bot tried to close a ticket on its own, and it broke down on complex cases: it had to understand the product, read a stack trace, and pick an answer all at once. Now each task goes to a narrow agent.

• The diagnostic agent reads CI logs, error traces, and commit history, and looks for the probable cause of a build failure.
• The preparation agent collects the SDK version, environment, reproduction steps, and related tickets for the engineer.
• The execution agent prepares a patch and opens a Pull Request, but only after an explicit command from a human.
• The control layer includes review, test runs, and a log of each agent's actions.

The third role is the most telling. The agent does not merge changes itself. It proposes them as a PR, and the decision stays with the engineer.

Why developer support specifically

It is a convenient environment for agents. Requests arrive with structured data: configs, versions, traces. The task has a verifiable result, because a build is either green or red. And the repository gives the agent both a source of truth and a sandbox where an error can be caught before production. Ordinary customer support has almost no such feedback, and the "correctness" of an answer has to be judged indirectly.

There is also the economics. A support engineer spends most of their time not on fixing but on gathering context: clarifying the version, asking for logs, finding a similar case. Agents take over this routine first, and the benefit is visible even without automated PRs.

Where the risks are

A chain of agents widens the surface for errors. The diagnostic agent can confidently name the wrong cause. A patch can pass the tests and still break behavior the tests do not cover. Logs often contain tokens and keys, and the agent needs access to both them and the repository. That is why a setup with a human at the last step is more of a necessary condition than caution for its own sake.

Where a team should start

It makes sense to start with a diagnostic agent in read-only mode, with no right to change anything. Write permissions should come later and only for narrow classes of problems: a broken dependency, a flaky test, a configuration error. Before launch, the team needs to agree on metrics in advance, otherwise there will be nothing to evaluate with:

• the share of tickets where the collected context turned out to be correct;
• time to the first substantive response;
• the share of PRs accepted without edits;
• the number of repeat requests on the same issue.

Separately, secrets should be masked before logs reach the model, and PRs should be created in isolated branches. If a chain of agents does not reduce the share of repeat requests, it only speeds up the process itself, not the resolution of problems.