Internal system · Pilot

The company’s agent platform

The agent platform of a company trading on marketplaces: a core with one shared agent loop, a tool registry with access modes, a dashboard over the database and a request flow with a mandatory audit. A new agent here is a file with a prompt, not a new service.

The pain

Repetitive manual work settled in chat threads: someone asked for it to be automated, the request got lost between people, and nobody saw the next team asking for the same.

Now

An employee files a request on a form, in the language of their own work. An agent is one file with a prompt and no code of its own, and requests are visible to all, so identical asks stop drifting apart.

What the business gets

The request is written by the person it hurts, in the language of their work, not in the terms of a developer’s ticket.
Requests are visible to every employee: someone else’s request shows what is already being automated, and that removes duplicates.
The audit is mandatory, so some asks are honestly closed by a script or split up instead of becoming an agent for the sake of it.
A new agent needs neither its own service nor code written for it - only a file and a release.
An agent cannot change data in an account: reading and notifications are all it has.

From source to result

An employee’s request
Audit and verdict
The agent file with its prompt
The tool registry
Scheduled runs and the log

Runs and model calls are written to the database, and the dashboard reads it directly: spend, model routing and task status live on the same screens instead of three separate consoles.

How it works

There are two levels of execution. The everyday «watch X, count Y, report to Z» is a file with a prompt; heavy data processing stays a pipeline in code. To the schedule and the dashboard the two are indistinguishable: one run log and one model-call log.

A broken agent file fails the core on start-up deliberately: falling over at release beats silently losing an agent from the schedule.

A tool error does not kill the agent: the model receives the error text and decides what to do next, while an oversized response is not truncated but returned as an error that forbids drawing conclusions from it: out of a broken fragment the model would compute a total and report a plausible wrong number as a success.

Having the model draft a config from the request was dropped on purpose: a request should be nothing more than a record in the database, visible to all. The implementation is still in the repository history and can be brought back if the decision changes.

Who maintains it now

An engineer. Agents are written by the IT team; employees order them on a form and use the results.

Other cases for this step

Internal system · In production

Product portal

Catalogue, labels and PDFs - one button

The pain: Every label was assembled by hand, in five steps through the external PLM. A typo in an SKU turned into a penalty and a return.
Now: The product catalogue, label printing, PDF generation and image conversion live in one portal. Five manual steps collapsed into a single «Print label» button.

Label printing: one button instead of five steps
Coverage: catalogue, labels, PDFs, conversion
Replaced: an external PLM system

The same system pays off across 2 more steps

Internal system · In production

Advertising management agents

The operator’s daily cycle runs itself

The pain: The morning started with a manual round of the accounts: spend, DRR, campaigns spending without orders, bids in a spreadsheet. It ate half a day.
Now: Calibration, the scanner and bid proposals run overnight; in the morning one command gives the operator the whole summary. The agents themselves never write into the account: a human confirms first.

Overnight cycle: calibration, scanner, bid proposals
Operator commands
Write into the account

The same system pays off on one more step

Own product · In production

Marketplace stores in Claude

Routine checks close with a question in chat

The pain: The daily checks - what is running out, what is blocked, what arrived in payouts - mean walking three accounts by hand. Nobody does that every day, and problems surface late.
Now: A check turns into a question in chat: Claude calls the marketplace methods it needs and answers to the point. A writing call does not go out first time: a preview first, the send on a second call.

Daily check: a question in chat instead of a round of accounts
A writing call
A read-only key

The same system pays off on one more step

mcp.hubmarket.ru

Internal system · In production

Warehouse stock sync

Warehouse stock reaches the store on its own

The pain: Warehouse stock and the online store’s catalogue lived apart: a buyer saw availability the warehouse no longer had, and fixing it meant doing it by hand, item by item.
Now: A run takes fresh warehouse stock and brings the store catalogue in line with it. The state is recalculated in full, so discrepancies never accumulate, and only the items that changed are written.

Catalogue: ~22,000 products
The run: a full recalculation, one command
Circuit breaker

Type: Internal system
Status: Pilot
On the schedule: one agent
Maintained by: the company’s IT team
Replaced: asking for automation in chat threads

Python 3.14uvFastAPIAnthropic SDKPostgreSQLNext.js 16React 19Base UIReact Flowcron