Phased rollout

Adopt without a revolution

There is no need to design the perfect universal agent first. Make existing processes visible, then improve them using data.

Start with read-only code review

Reviewer.Agent receives the diff, requirements, and conventions but has no write or production access. It creates a structured artifact: regressions, architectural risks, what QA should check, and what a person should clarify. The team can immediately measure what the agent found, what it missed, and which findings create noise.

Move personal agent stacks into Multica

Sergey.Agent, Dima.Agent, and other current harness configurations are not forcibly standardized. They simply stop living only on laptops and become visible, runnable, comparable team objects.

Make harness development separate work

If a task was not completed in one shot and the developer changes a skill, a separate issue is created for the harness change. History, regression checks, rollback, ownership, and a team pipeline for evolving the agent stack appear—instead of oral advice to “try it this way.”

Derive a shared pipeline from measured results

The team compares similar tasks, attempts, human interventions, and metrics. Stronger profiles receive collective development; weaker ones die out. There will probably be no single agent for everything, but the number of profiles will shrink and settle around classes of tasks.

The working pipeline emerges from measurements

Easy bugs, for example, can go to Fast Fixer; complex tasks first to Planner.Agent and then Deep Coder; rare tasks with a high cost of error to Ultra Think. Reviewer.Agent can inspect code before human acceptance, while QA.Agent checks screenshots, scenarios, and regression risks. All of these names are examples, not a prescribed catalog of roles.

This is not a directive that “everyone works the same way.” The team first observes stacks that actually work, connects successful skills, and tests configurations on tasks. Only then does it agree which profile is better for each class of work.

As the system matures, a particular Jira issue increasingly becomes only a test of the production system. The core engineering work shifts toward developing the harness so the next instance of that task class is solved more autonomously, cheaply, and reliably.