Minas Sarkisyanwebkoth.com

Internal system · In production

Advertising management agents

Managing a trading company’s own advertising on a marketplace: an analytics portal, a service that executes decisions and eleven operator agents in Claude Code. The system calculates and prepares proposals overnight and the operator works through them in the morning. Changes from the agents reach the account only after a human confirms them; auto-pause and scheduled auto-apply are a separate contour, with time windows, a daily spend kill-switch and auto mode off by default.

The pain

Bids were moved on yesterday’s report and on a hunch. But «yesterday» does not show what actually happened, and a market-wide drop is easily mistaken for your own mistake.

Now

A decision is assembled in order: market regime, product health, the fair target DRR for this item, and only then the bid itself. Metrics come from a matured window; the DRR plan is ≤ 10 %.

Effect across the steps

03 · Precise decisions
A bid moves along a decision tree rather than on yesterday’s report
04 · From routine to automation
The overnight calculation and the morning summary run themselves; the decision stays with the human

What the business gets

  • A market-wide drop is told apart from your own mistake: the market regime is established before any bid is touched.
  • Metrics are counted on a matured window, so decisions are not made on statistics that have not filled in yet.
  • Campaigns spending without orders are found by the system, not by a human eye at the end of the week.
  • A bid from an agent never reaches the account bypassing a person, and the automatic contour is bounded another way: permitted windows, a daily spend kill-switch and «propose only» as the default mode.

From source to result

  1. Marketplace and stock data
  2. Scheduled overnight calculation
  3. Decision tree
  4. Queue of proposals
  5. Operator confirmation or a schedule window → the account

A fresh marketplace response is fetched before a bid is written: the database lags behind the account, and a decision on a stale row is a bid in the wrong place.

By hand, then one button

  1. 1.Collect yesterday’s spend across accounts
  2. 2.Calculate DRR for every campaign
  3. 3.Find campaigns spending without orders
  4. 4.Sketch bids in a spreadsheet
  5. 5.Type the changes into the account by hand

How it works

The order of the modules was chosen after a real collapse in orders: the marketplace’s own signals move sales harder than our bids do, and aggressive edits during a crisis only deepen the spiral. So the first step is the market regime, and in a crisis regime raises and new campaign launches are forbidden.

Duplicate statistics batches are cut off on the way in: without that, spend was overstated several times over and the whole decision tree counted on an invented number.

Some brands are declared untouchable: the agents change no bids, no pauses and no negative keywords on them. The filter is hard-wired into the pause and recommendation scripts, but not into the bid-apply path - there the rule rests on the operating procedure and the agent’s prompt. The repository’s own audit says so rather than papering over it.

Reading agents and writing ones are separated on purpose: the digest, the campaign check and the bid calculator never write to the account at all, and the writing commands are not on the allowed list, so the system’s confirmation prompt always comes up before them. The overnight contour is built differently: there is no human beside it, and instead of a confirmation it is held by permitted windows, a daily spend kill-switch and auto mode being off by default.

Who maintains it now

The engineer owns the engines and the agents. The decision belongs to the advertising operator: the system proposes, the human confirms.

Other cases for this step

Internal system · In production

Data platform

The number is verified against the source down to a single unit

The pain
Data went through four processing layers and nobody compared the result with what the marketplace shows. Decisions rested on a number with nothing to check it against.
Now
Orders, cancellations and stock reconcile with the marketplace down to a single unit, money down to the kopeck, and the check can be repeated any day with one command.
Verified against
Data marts
sales, stock, presence, P&L, reconciliation

The same system pays off across 2 more steps

Open the case

Own product · In production

Marketplace stores in Claude

An answer about the store - in words, without a dashboard

The pain
To understand what is happening in a store, a seller walks three marketplace accounts and merges reports in a spreadsheet. A dashboard answers only what was built into it.
Now
The seller asks in plain words - «what is running out», «is the advertising paying off», «how much will land on my account» - and Claude goes into the marketplace API with their key.
Coverage
Marketplace keys
Tabular report
downloaded for you and read as rows

measured in August 2026: 945 of 962 operations callable through the API catalogue

The same system pays off on one more step

Open the case

Open source · In production

Marketplace knowledge base for agents

The agent answers by the marketplaces’ rules, not from memory

The pain
When an AI agent designs logic against a marketplace’s rules, it leans on memory. Tariffs and limits change, memory does not, and errors surface in money, not at review.
Now
A knowledge base of three marketplaces sits next to the project as ordinary markdown files: one per API method plus the seller help. The agent reads the source, not a retelling.
The base
The build
Updating
one command, the git diff as the change report
Open the case

Internal system · Pilot

Marts on top of the data lake

Margin per product - and, separately, what does not land on it

The pain
Product economics were counted off the marketplace report. Cost price sits on logistics rows too, and there are far more of those - it came out an order of magnitude high.
Now
Two marts: one holds what honestly lands on a product, the other storage, intake, penalties and withholdings that do not spread across items. On screen they are a separate block, not profit that is absent.
The operation-type filter
What the dashboard answers from
The period ceiling

15 % of the source’s non-empty tables serve data older than a week, and the catalogue does not tell them from the live ones

Open the case
Type
Internal system
Status
In production
Rhythm
overnight calculation, morning review
Maintained by
an advertising operator
Replaced
a manual round of the accounts every morning
PythonFastAPIMS SQLPowerShellEChartsClaude Codecronsystemdnginx