---
id: "lib-2026-11-06-how-i-built-the-ai-harness-for-a-business-analyst"
type: "library"
title: "How I built the AI harness for a business analyst's workstation in an IT company (Как я строил ИИ-обвязку рабочего места аналитика в IT-компании)"
lang: "RU"
org: "Habr-Author"
source_type: "Practitioner post"
date: "2026-11-06"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-06-how-i-built-the-ai-harness-for-a-business-analyst/"
original_url: "https://habr.com/ru/articles/1104618/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "First-hand Habr account by AI-systems architect Nikolay Karpov of rolling out a shared agent \"canon\" for analysts in an IT company; rich on design, failures and token costs, but outcomes are anecdotal and self-reported."
summary_basis: "full-text"
original_minutes: "24"
tags: ["enablement", "business transformation", "agent harness for documentation", "token cost control", "support via telegram bot", "reflection/memory layers"]
---

# How I built the AI harness for a business analyst's workstation in an IT company (Как я строил ИИ-обвязку рабочего места аналитика в IT-компании)

Tier B (Useful, limited): First-hand Habr account by AI-systems architect Nikolay Karpov of rolling out a shared agent "canon" for analysts in an IT company; rich on design, failures and token costs, but outcomes are anecdotal and self-reported.

Summary based on the full text.

## In short

A Habr post (6 November 2026) by Nikolay Karpov, an AI-systems architect at a Russian IT company, on building a department-wide "canon" for analysts writing software documentation: agent roles, skills, scripts, a project folder standard and memory, run in KiloCode, Cursor, Claude Code and Codex. Its first test was a deadline: 14 business-requirement documents for a new payment product in 8 working days, later 17, each reviewed by the analyst. The post covers what broke, why the canon needed an owner, support through a Telegram bot, and token costs.

## Key numbers

- 14 in 8 working days: business-requirement documents produced in the first deadline test, later 17, each read and accepted by the analyst
- half: of the analyst team using the canon within a month
- ~100,000 tokens: median context per request measured for one specialist; some sessions reached several hundred thousand
- up to $20 / ~$30: cost of one specialist's working day in some cases / a daily limit burned on one API description
- 2x: reduction in token use after rebuilding agent memory and instructions

## What it reports

- Structure: role (responsibility and limits), skill (method for a document type), tool (a script such as build_docx.py), template and sources; all working files are drafts until a specialist accepts them into a release folder.
- Digitising sources was the foundation: tables kept as HTML to preserve nested row hierarchy matched to regulator XSD/XML; diagrams as PlantUML, draw.io or BPMN.
- Gaps go into an open-questions file with IDs; any text written before an answer must carry a visible flag.
- Under deadline the agent invented data; temperature 0.2 and top-p 0.85 were needed, against 0.6 for other tasks.
- Cross-vendor review worked best in the author's practice, with a stop condition and a human decision when agents disagree.
- Failures: a "unification" change broke Confluence publishing for about three days; an analyst spent three hours with the agent on a 20-minute developer task; stale instructions from a past client made an agent name the wrong role; a diff-output rule sent the agent into a loop.
- Half the team adopted the canon within a month; feedback included "I am anchoring, not speeding up".
- Tokens (LiteLLM + Langfuse): fixed instructions reached tens of thousands of tokens; sessions held open for days lost the cache; missing README/INDEX files made agents read file by file. New rules (fresh sessions for small edits, index notes, compact memory) halved use.
- Reflection command splits lessons into project-only, cross-project and canon change proposals; canon changes go through the owner.
- The business sponsor accepted only two effects: twice the orders handled or lower costs.

## How they got it

A practitioner narrative from the author's own deployment, with quotes from an internal webinar and token measurements from one specialist.

## Limits

- No measured time savings; the "an hour instead of a day" claim is an observation.
- Token figures come from one specialist; company and team size not given.
- Some model and product names are unverified by the author's own note.

## Why it matters for companies

This is a detailed blueprint for giving non-developers a governed agent workspace: shared roles and skills, a named owner who releases changes, regression checks before updates, support that answers within the working day, and token monitoring from the start. Without the owner and the support line, saved time goes into fixing setup errors. The cost findings (open sessions, unindexed folders, bloated instructions) apply to any team rolling out coding agents beyond engineers.

## Key passages in translation

> Основное время ушло не на генерацию текста, а на условия доверия к нему

Most of the time went not on generating text but on the conditions for trusting it.

> Автоматизацию поддержки я считаю обязательной при массовом внедрении.

I consider automating support mandatory for a mass roll-out.

> у внедрения ИИ он признавал только два эффекта — либо команда берёт вдвое больше заказов, либо сокращаются расходы.

He recognised only two effects of the AI roll-out: either the team takes on twice as many orders, or costs go down.

Original: https://habr.com/ru/articles/1104618/