Finuslugi launches overnight AI agents that found losses across 1,600 registrations without any alerts

The nastiest production problems don't look like outages. The main dashboards are green, alerts are silent and the service is up, but at one step of the user journey the share of failed operations or the response time is growing. For the system as a whole everything is fine, while for a specific person the product is broken.

Every week, the Finuslugi registration team manually walked the same route: Grafana, then logs in OpenSearch, then a search for the problematic business operation and the related code. This took four to eight hours a week, and that was before the engineer even started thinking about what to fix. The team decided to automate exactly this part: not decision-making, but gathering facts and preparing a hypothesis.

How the overnight loop works

On a schedule (in Multica this is Autopilot), the system creates a task, which OpenCode picks up. From there a lead-agent takes over: via MCP, it reads the catalog of business operations and the control rules for each one in Confluence. In the base scenario for Prometheus there are 21 such operations. The lead-agent hands them out to seven child agents, three each, and they check their sections in parallel.

Diagnosis is deliberately split into two stages. In the first, a collector agent works within a single observability loop and answers a narrow question: is there a deviation, and how serious is it? It compares the facts against the SLA and baseline and assigns a status of OK, WARNING or BREACH. The output is a short card: operation, actual value, SLA, baseline and supporting data. Only WARNING and BREACH go on to the analyst-agent. It opens the related repository and formulates a hypothesis about the cause.

If the deviation is confirmed, Multica assembles a draft Jira task. It contains the business operation, metric values, the SLA violation, technical context, the cause and a proposed fix. The key word here is "draft": an engineer moves the task into the backlog after checking the conclusions.

Why you can't just feed the model all the logs

The temptation is understandable: "look at all the services, metrics, logs and code and find something suspicious." In practice, such a request runs into execution time, context size and answer quality. The more heterogeneous the data, the harder it is to tell what a hypothesis rests on.

So the SLA and observability data narrow the search first, and a subtask becomes both a unit of parallelism and a context boundary. This brings several practical benefits: deterministic calculations are not mixed with LLM reasoning, a failed part can be restarted separately, and quality is checked at the level of a specific role and artifact.

Three sources, three layers of problems

The system was built up step by step, and each source answered its own question.

• Prometheus shows where something changed: failrate, latency and SLA compliance per operation. The first version, built on metrics and code, found problems in roughly 1000 registrations.
• OpenSearch explains what exactly happened: HTTP codes, error messages, stack traces. This added about 600 more registrations. If the cause lies in another team's service, the agent can go into that adjacent team's repository, provided it has access; the link is determined by Feign calls.
• Sentry brought a new class of signals: frontend errors and page load speed. A page with no errors that takes a minute to load doesn't work for the user, and backend failrate won't show it.

After each round of fixes, results plateaued until the next source was connected. The authors state their conclusion plainly: the gains came not from the model's "smarts" but from a wider field of view.

Limitations and what to do in practice

Failrate can't be treated as a single formula. 500s and 401/403/422 have different semantics, expected errors such as an expired session have their own acceptable level, and some operations have their own exceptions. The agent is useful only to the extent that the team has precisely described the operations, SLA, baseline and the meaning of the signals. AI does not replace an observability model; it relies on one.

The diagnostic loop itself becomes a production system, so it needs monitoring too: run stability, false positive rate, usefulness of reports. Also review the path by which the agent reached its conclusion. A false positive means the SLA or formula needs refining. Not enough data: improve observability or the context-gathering skill. Wrong repository chosen: improve the dependency research skill. Noisy report: tighten the contract.

If you want to replicate the approach, don't start with the agent. First formalize what counts as a problem and what to compare signals against, otherwise the LLM will simply reproduce your uncertainty. Fix the final report as a contract: operation, severity, facts, impact, code, hypothesis, confidence level, next action.

The team plans to shorten the path from hypothesis to fix: standard fixes and MRs instead of a Jira draft. But the closer an agent gets to changing production, the more important human review, access control and reproducibility become. For now, what wins is not an autonomous "AI engineer" but narrow roles, clear boundaries and a human at the decision point.