Open source · In production

Marketplace knowledge base for agents

An open knowledge base of three marketplaces for AI agents: a tree of markdown files in git, one file per API method plus the seller help articles. Not a service: the agent reads the files directly while designing an application’s business logic.

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.

What the business gets

A decision about application logic rests on the text of the rule, not on a retelling of it.
After an update, the git diff shows exactly what the marketplace changed in its rules.
The pipeline is deterministic, so a repeated build with nothing changed produces an empty diff.
It plugs into a project as a neighbouring folder: no service, no index and no vector database to stand up.

From source to result

Marketplace specifications and help
Deterministic build
Markdown with a link to the source
Indexes for the agent
The git diff as a report

A file is rewritten only when its content has changed, so the diff after an update is a list of real changes in the marketplace’s rules rather than noise from dates.

How it works

The original idea - a vector database, embeddings, a reranker and a web service - was dropped during review: an agent with a well-structured corpus does fine with file search and reading, and determinism matters more here than recall.

API documents are built from the specifications rather than scraped: two of the marketplaces’ portals are closed off by bot protection at the connection level, so the sources are an official repository and specification mirrors.

Help is taken from a curated list of sections - commissions, tariffs, penalties, returns, fulfilment schemes, card requirements - and tables are kept as tables. One marketplace’s help is behind bot protection entirely, so it is covered by API method descriptions alone; that is written down in the decisions rather than papered over.

Who maintains it now

Me. Open source, refreshed by one command from a working machine.

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

Internal system · In production

Advertising management agents

Bids move on data: the DRR plan is ≤ 10 %

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 %.

DRR
Decision order: market regime → product health → target DRR → bid
Metrics window

The same system pays off on one more step

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

mcp.hubmarket.ru

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

Type: Open source
Status: In production
Size: 1,628 files across three marketplaces
Maintained by: an engineer
Replaced: an agent guessing at the marketplace’s rules

PythonuvOpenAPIhttpxtrafilaturaMarkdownGit

GitHub