Avito's BI Team Builds Dashboards With an Agent in 8–10 Days Instead of 20
Avito's Real Estate BI team connected an agent to Redash and Trino through MCP servers. It finds tables, writes SQL and builds charts. Each chart comes out decent, but the dashboard as a whole is a set of pictures with no focal point. The agent even found the answer to the client's main question, but didn't realize it was the answer and left it off to the side. Humans had to set priorities, colors and comparisons by hand.
AI-processed from Habr AI; edited by Hamidun News
Colleagues increasingly bring BI developers dashboards built with AI. They have lots of charts, all detailed, but it's unclear where to look or what conclusion to take away. Ira Kulbyakina from Avito's Real Estate team worked out why this happens and showed, with an example, how to bring such a dashboard to a working state. According to the authors, with an agent a complex dashboard takes 8–10 days to build instead of 20.
Where the agent helps and where it doesn't
Dashboard work usually goes like this. First you gather requirements, then you work through the data: which tables are current and how to calculate the metrics. Then you write SQL and visualization code and manually wire filters to every chart. The agent takes over these technical steps. Avito built MCP servers for Redash and for its Trino-based warehouse. Through them the agent searches for tables, pulls data, writes queries and builds charts. People still check the sources and calculations themselves.
Problems start when the agent is asked to assemble a whole dashboard from charts. For the model, each chart is a separate task with its own query, visualization type and colors. Errors inside a single chart (different scales on one panel, a sum instead of an average, a forgotten previous period) are easy to catch with rules. Screen-level decisions are harder: which color is tied to which metric, what each number should be compared against, what matters most and what should not be on the screen at all.
The experiment: a call center dashboard
The colleague reconstructed the technical spec from an existing dashboard for the call center that connects new-build buyers with developers. The author then built a new dashboard with a different agent that had not seen the original version. The client's main question ("Why did the number of target transfers drop?") was not singled out in the spec, so the agent had to work out on its own that it was the main one.
The first version looked complete: seven cards, a trend chart, a waterfall, sources, cities, a heatmap, workload and a table. But it did not do its job. Then came the edits:
- Trend. One chart with shares and counts on a single panel was split into five. The previous period was shown as a dashed line, and incomplete weeks were shaded gray, otherwise the end of the month would have looked like a collapse.
- Heatmap. September has five Tuesdays and five Wednesdays, and four of every other day, so call sums distorted the picture. The team replaced the sum with an average, added a legend and moved the numbers into a tooltip.
- Sources and cities. These became tables with a bar, a value and the change versus the previous period, with "Total" as the first row.
- Employees. They were grouped by team, small rows were collapsed into "Other", and everyone was colored the same so that no team would look like a laggard because of red.
- Consistent metrics. The share of non-target transfers is used everywhere, instead of target transfers in one place and non-target in another.
The agent did not do the most important part on its own. The answer to the client's question came from the waterfall, which shows each factor's contribution to the change in target transfers. The agent built it, but placed it off to the side at half width and did not realize it was the answer. Humans had to move the waterfall under the cards at full width and highlight the single large contribution: −63 target transfers due to the growing share of non-target transfers. There were actually more tasks, and fewer target transfers, precisely because the share of non-target transfers grew.
Rules worth adopting
The author compiled her conclusions into a list that can be turned into a skill for an agent:
- Comparisons must be fair: one scale per chart, incomplete periods marked, an average instead of a sum when periods have different numbers of days.
- A number without a comparison baseline means nothing. 82,3% needs the previous period next to it.
- Don't duplicate what is already shown: if numbers sit above the bars, no axis is needed.
- Everything needed for reading is labeled: period, comparison baseline, units.
- Color is tied to meaning across the whole screen. Green and red are only for "better/worse" evaluation, while growth in call volume is neutral and gray.
What this means
The limitations deserve a separate mention. The whole article rests on a single dashboard with synthetic data. The final time-savings figures are not disclosed in the available portion of the text, so "8–10 days instead of 20" should be read as the team's claim, not an independent measurement. The authors still check sources and calculations manually.
The practical takeaway is simple. You can hand the agent data search, SQL and filter routine, but prioritization and visual hierarchy are better stated explicitly. If you turn the dashboard rules into a skill, the agent will make fewer typical mistakes from the first iteration. And the question "what matters here and why" must still be asked by a human.
- Nov 12, 2026AI agent went from WordPress to an executive's drive, and the defense caught 14 of 15 steps
- Nov 12, 2026Google launches Gemini Decision 1: video and PDF decisions for $0.10 per 1M tokens
- Nov 12, 2026ElevenLabs adds NVIDIA's Nemotron: voice agents 70% cheaper than other open models
- Nov 12, 2026How to Run an AI Agent in a VM While Keeping the Model on the Host GPU: A Setup with Strata
Key Questions Answered
Where the agent helps and where it doesn't?
Dashboard work usually goes like this. First you gather requirements, then you work through the data: which tables are current and how to calculate the metrics. Then you write SQL and visualization code and manually wire filters to every chart. The agent takes over these technical steps. Avito built MCP servers for Redash and for its Trino-based warehouse. Through them the agent searches for tables, pulls data, writes queries and builds charts. People still check the sources and calculations themselves.
What are the key details on The experiment: a call center dashboard?
The colleague reconstructed the technical spec from an existing dashboard for the call center that connects new-build buyers with developers. The author then built a new dashboard with a different agent that had not seen the original version. The client's main question ("Why did the number of target transfers drop?") was not singled out in the spec, so the agent had to work out on its own that it was the main one.
What are the key details on Rules worth adopting?
The author compiled her conclusions into a list that can be turned into a skill for an agent: Comparisons must be fair: one scale per chart, incomplete periods marked, an average instead of a sum when periods have different numbers of days. A number without a comparison baseline means nothing. 82,3% needs the previous period next to it. Don't duplicate what is already shown: if numbers sit above the bars, no axis is needed. Everything needed for reading is labeled: period, comparison baseline, units.
Build & Ship Production AI Agents Without Boilerplate Code
Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.