---
title: "Your next customer might not use a browser."
url: "https://mercantir.com"
description: "Mercantir is an open retail operating system built on Open Mercato: orders, stock, customers and product knowledge in one place, structured so agents can query it.
"
---

Pre-launch · open source

# Your next customer **might not use a browser.**

Mercantir keeps orders, stock, customers and product knowledge as one system rather than four, built on the Open Mercato framework. The product data is structured so that a question can be answered precisely — by a person today, and by whatever is asking on their behalf later.

[Join the waitlist](https://mercantir.com/contact)[Read the blog](https://mercantir.com/blog)

-   Orders, stock and customers in one place
-   Product knowledge, not product pages
-   Open source, your infrastructure

The problem

## Three things retail systems make unnecessarily hard

None of them is selling. All of them are what has to be true before selling works.

### One question, four systems

Can I sell this, where is it, and when does it arrive. Answering it means the shop system, the warehouse system, the ERP and somebody who remembers what was ordered in March — and the answer is a best guess with a confident tone.

### Product data written for a page

Catalogue copy is written to be scrolled past by a human. Ask it a specific question — will this fit that, is it suitable for this use, what is the difference between these two — and there is nothing structured to answer from.

### The storefront is the least differentiated thing you own

Every retailer has a competent shop. It is a commodity, it is where most of the software budget goes, and it is not where anybody wins. What is scarce is knowing your own stock, margin and product truthfully.

How it works

## One record, real product knowledge, any channel

The order matters: the third only works because of the first two.

1.  01
    
    ### One record
    
    Orders, stock, movements and customers in a single system rather than synchronised between several. Most retail data problems are synchronisation problems, and the cheapest fix is having less of it to synchronise.
    
2.  02
    
    ### Product knowledge
    
    Structured attributes, compatibility, use cases and the relationships between items — not just a description and a photo. This is what turns a catalogue into something that can answer a question rather than display a result.
    
3.  03
    
    ### Any channel, including new ones
    
    Shop, marketplace, phone order, counter, wholesale. And the emerging one where a customer sends something to ask on their behalf, which is early, unsettled, and worth being ready for rather than surprised by.
    

What it does

## Six parts of a retail business

The modules a retailer actually runs on, in one system rather than four with an integration budget between them.

### Order management

Every order from every channel in one place, with its history, its exceptions and its actual margin. Not one system per channel and a spreadsheet to reconcile them.

### Stock and warehouse

What you have, where it is, what is reserved and what is on its way. Accurate enough to promise from, which is a higher bar than accurate enough to report from.

### Customer record

Orders, contacts, returns and the awkward history. A customer view that excludes returns describes a different customer from the one you actually have.

### One data platform

The numbers reconcile because they come from one place. Most retail reporting arguments are two systems disagreeing, not two people.

### Recommendations from context

What is being looked for, what it is for, and what the customer already has — rather than what other people also bought. The second is easy and the first is worth something.

### A catalogue an agent can query

Structured, machine-readable product knowledge with clear stock and pricing semantics. Useful today for search and support; necessary later, when the thing asking is not a person.

## Agentic selling, and what we will not claim

There is a genuine shift coming in which software acts on a buyer's behalf — comparing, asking and eventually purchasing. It is worth building for. It is also early, the standards are unsettled, and a great deal of what is being sold as agentic commerce today is a chatbot in front of a normal checkout. So here is the boundary between what we are building and what does not exist yet.

-   **We are building the data layer.** A catalogue with structured, queryable product knowledge and honest stock semantics. That is useful whether or not the agent channel arrives.
-   **The protocols are not settled.** Agent-to-agent commerce standards are early and competing. We will implement them when they stabilise and say which ones.
-   **No payment or authorisation claims.** Who is allowed to buy what, on whose authority, and how a dispute is resolved are unsolved questions and we are not pretending otherwise.
-   **Not a chatbot on a checkout.** Wrapping a conversational interface around an existing shop is a different and much smaller thing, and it is what most current announcements describe.

## Built on Open Mercato

The commerce foundations — catalogue, orders, stock, the module structure — come from the Open Mercato framework rather than being written again from nothing. That decision buys years of solved problems and means the parts a retailer depends on are not ours alone to maintain, which is a better position for a customer than a private codebase.

-   **Not written from scratch.** Retail has a long tail of solved problems, and rewriting them is how a small team spends three years reaching parity.
-   **No partner status is claimed.** We build on the framework. We are not an affiliate, reseller or certified partner, and if that ever changes it will be stated here plainly.
-   **Contributing back where we can.** Improvements that belong upstream should go upstream rather than into a private fork that eventually cannot be updated.
-   **Replaceable, including us.** Building on a public framework means another team could pick up your deployment, which is the practical meaning of not being locked in.

Where we are

## No retailers running on it yet

Software that has not survived a peak week in a real shop should say so before it says anything else.

1.  Now
    
    ### A reference catalogue and real orders
    
    Orders, stock and product knowledge running against actual movements, at our own risk, so the failure modes we find are ours.
    
2.  Next
    
    ### The first retailers
    
    A small number, chosen for fit rather than size, set up with help and watched through a full season including the week everything goes wrong at once.
    
3.  Later
    
    ### The agent channel, when it is real
    
    Implemented against whichever standards actually settle, described precisely, and only after the parts a retailer needs today are proven.
    

FAQ

## Frequently asked questions

What is Mercantir in one sentence?

An open retail operating system built on Open Mercato that keeps orders, stock, customers and structured product knowledge in one place, so a question about a product can be answered precisely by whoever or whatever is asking.

Does it replace my e-commerce platform?

Not necessarily, and often it should not. The shop layer is a commodity that most retailers already have working. What is usually missing is one truthful record underneath it, which is where this sits.

Are you an Open Mercato partner?

No. We build on the framework and intend to contribute back, and we are not an affiliate, reseller or certified partner of anyone. If that changes it will be stated on this page rather than implied by a badge.

What does selling without e-commerce mean?

That the transaction does not have to go through a storefront. Wholesale, counter, phone, marketplace and eventually an agent buying on a customer's behalf. Each needs the same underlying truth about stock, price and product, which is the part being built.

Is agent-to-agent buying actually working today?

No, not in any settled way. The standards are early and competing, and the hard problems — authorisation, payment, disputes, returns — are unsolved. What is available now is preparing the product data, which is useful for search and support regardless.

Do you handle payments?

Payment providers are integrated rather than replaced. Handling money has regulatory obligations that a retail operating system should not casually take on, and any provider integration will be named rather than described in general terms.

What about the shop floor and POS?

Stock and orders are shared, so a counter sale and an online order draw on the same truth. A full point-of-sale application is not built yet and will not be claimed before it is.

What will it cost?

The software is open source, so self-hosting costs infrastructure and your time. A managed option will be priced per business rather than per user or per order, because charging a retailer more for selling more is a strange thing for an operations system to do.

## Tell us what your stock data is really like

The waitlist form goes live soon. Until then the blog explains what is being built and which parts of the agentic story do not exist yet.

[Contact](https://mercantir.com/contact)[Read the blog](https://mercantir.com/blog)

No form yet, no data collected — just come back.