What does the commerce engine actually do?
The commerce engine is an AI business analyst that runs on a brand's own commerce data. It connects to the store read-only, copies every order, product, variant, customer, inventory level, discount, refund and tax line into its own database every fifteen minutes, and computes every business metric itself. Around that core it joins the systems a retailer actually runs on, such as support tickets, returns, warehouse packing, in-store footfall, email marketing, search and social, so each system's data can be read against sales.
The result is one place where a question that used to need six reports has one answer, priced in dollars, with the evidence attached. A store owner asks which products lose money after returns and shipping, and gets a ranked list with the arithmetic shown, not a chart to interpret. On ftes.ai, the e-commerce Digital FTEs are the named roles that do this work, and the engine is what they do it on.
What the commerce engine is not
It is not a customer-support chatbot. There is a chat analyst inside it, but the chat is one surface for interrogating an analytics engine, not the product. It is not a thin AI layer over a store admin either: the engine holds its own database, its own scheduler, its own run ledger and its own analytics code, and the store admin is only ever a read-only source.
And it never changes commerce data. Prices, inventory, orders and customers in the store stay exactly as the store holds them. The only things that ever leave the engine are pieces of content and messages that a human explicitly approved: a manager email, a vetted marketing list, an article on the storefront blog, an approved social post, an ad proposal a person signed.
The three laws are the whole architecture
The engine is built on three promises. The backend calculates: revenue, margin, cover, return rate, conversion, tax and landed cost are all computed by a deterministic, unit-tested analytics engine using set-based SQL against the engine's own database, so the same number appears on every page. The AI interprets: agents receive figures that already exist and turn them into verdicts, narratives, drafts and recommendations, and no AI in the product can produce a number of its own.
A human approves: every action that leaves the platform is shown in a Review & Send screen first, unattended sending is an explicit switch that is off by default, and every send is logged and later scored. A fourth promise follows from those three, which is honest data. When a figure cannot be computed, the page says why rather than showing a zero, and test orders and catalogue errors are excluded and disclosed.
How the engine works from connection to decision
The store connects read-only, and other systems are added on an Integrations page as needed with write-only secret fields or OAuth. A scheduler pulls new and changed records every fifteen minutes; heavy sources run on their own nightly schedules; inventory updates in real time by webhook. Every run is logged, and a run ledger shows what ran, when it last succeeded and what it produced.
The analytics engine then calculates every metric with set-based queries, from dashboard KPIs to true profit per SKU after every deduction, days of cover, conversion per trading hour, tax per jurisdiction and landed cost per line. AI agents read those figures and write the morning brief, the executive report, page commentary, chat answers, draft manager emails, articles and posts. The owner approves, sends, publishes or skips, and a Results ledger measures what each action changed.
Which surfaces does it ship today?
The Command Center is where every day starts: a Morning Brief, a Dashboard with a money-at-stake strip and a net-sales bridge, chat with the analyst, and a scheduled Executive Report. Merchandising holds the product analyst with its landed-cost engine, the inventory analyst, and Foresight. Operations turns the transaction record into worklists: orders, warehouse packing, returns analytics, discount monitoring and sales tax reporting.
Customers and Support covers the money finder and win-back list, support team performance and store traffic. Growth is the brand visibility engine with its Brand Brain, the organic social manager and the performance advertising control room. Outcomes and Platform closes the loop with Results, AI performance, System, Integrations, Settings and in-app documentation. Each is a page in the engine and each is staffed by roles from the e-commerce org chart on ftes.ai.
Who is the commerce engine for?
It is built for brands roughly one to fifty million in revenue, typically apparel or lifestyle, usually running both an online store and physical shops. The owner wants four decisions with the money attached before the shops open, instead of four tools to open. The e-commerce manager wants sales, products, inventory, customers, discounts and refunds watched in one place. The operations manager wants stock, fulfilment and availability. The buyer wants to know what to reorder, transfer, mark down or drop.
The segment's defining problem is that its tooling computes revenue, not profit, and the enterprise systems that compute true margin start far above this price point. The engine exists to put fully-loaded contribution margin, cash locked in stock, realised discount and a measured record of advice in front of a brand that size, on its own data.
What is the next step for a brand that wants it?
Connecting the store is the whole first step. The history backfills, the sync starts every fifteen minutes, and the first Morning Brief is written from the store's own numbers. Other systems are added when the brand wants them, one at a time, and every one of them shows its health on the Integrations page and its runs in the run ledger.
On ftes.ai the way in is the e-commerce Digital Workforce: hire the roles that work on the engine, starting with the ones whose findings you want first, and review their proposals in the workspace. The org chart lists every role by department, with what it owns, what it never does, and the one number it is judged on.