​

Agentic Commerce

Your in-app assistant already sees your store — sales, catalogue, the traffic funnel, business health. Agentic commerce lets it act on what it sees. It can prepare the things it would otherwise only suggest — a gift card for a lapsed customer, a promotion on slow-moving stock, a dynamic-pricing rule that targets a customer segment — and it handles the reversible catalogue housekeeping outright. Anything that moves money arrives as a draft you approve — a gift card, a promotion, a pricing rule — and is inert until you do. The organisational actions, which are reversible, happen directly: creating a subcategory, enabling a category, tagging a product, grouping products into a collection.

​

What it can do

Base product prices are off limits — the assistant only ever touches dynamic-pricing rules, never a product’s own price. Anything a plan doesn’t include, or your role isn’t permitted to do, it won’t offer. Written content needs your storefront URL set first (CMS → Settings). The product links in a post are built against it, so without one they would only resolve on your own site and break as soon as the post is shared — the assistant says so and stops rather than writing a post that falls apart. A lookbook hotspot claims a product is at that point in that picture, so it is only ever placed from what is actually visible in the scene. A product the assistant cannot find in the frame is left off and reported by name, rather than given a hotspot at an approximate position. If a scene cannot be produced at all, the lookbook is still created, with your products confirmed against the catalogue and a plain note that they are not placed yet.

​

Approving a draft

A draft appears wherever you already manage that thing: a draft gift card on the Gift Cards page, a draft promotion under Marketing, a draft rule on the Pricing page, a draft search rule under Recommendations → Search Rules — each marked as an AI draft with Approve and Reject. You can also approve it right in the chat when the assistant proposes it, and the assistant’s launcher shows a small count when suggestions are waiting. Approving a gift card is the moment it issues and the customer is notified; approving a promotion or a rule is the moment it goes live. Rejecting dismisses the draft — you can always ask again.

​

What it aims at

A suggestion is only as good as what it is pointed at, so the assistant reads what shoppers wanted and did not buy — not only what sold.

• Carts — which products sit in baskets that have gone quiet, and what they are worth. A cart whose owner has since bought that product is not counted; they did not abandon anything.
• Abandoned checkouts — who reached the last step and stopped. The strongest signal in the group, because the shopper had already decided.
• Wishlists — what has been saved for later, the longest-lived signal of the three.
• Search outcomes — what shoppers searched for, which product they clicked, and whether that led to a basket, a checkout or a purchase.

The last one matters because it names where a search failed, and the three answers need different fixes: clicked but never added to a basket points at the product page or the price; added but never reached checkout points at delivery cost or stock; reached checkout but never paid points at payment. A promotion aimed at what shoppers are actually trying to buy beats one aimed at what merely sells slowly. And a product that is wanted but out of stock is a restocking decision — the assistant will not propose a discount on something nobody can buy.

​

Margin protection

Every value the assistant proposes is in your store’s currency, and every money action protects your margin. It reads each product’s cost to make sure a discount never sells below cost, and it prefers higher-margin or slow-moving stock. When too many products have no cost price set, the margin figure it would be checking against is itself unreliable, so it declines to prepare any gift card, promotion, or pricing rule and points you to Inventory → Bulk Edit to fill in the missing costs. The reversible catalogue actions stay available in the meantime.

​

Dynamic workflows

A request in conversation runs once and ends there. A dynamic workflow is the same intent kept running: ask for something ongoing — “keep my featured collection showing what’s actually selling”, “every week, check for slow stock” — and it becomes a rule that re-evaluates on a schedule. They are dynamic rather than fixed: each evaluation re-reads the store’s current figures and decides whether anything warrants doing, so the outcome follows the business rather than a predetermined sequence — the same workflow features different products as the sales change. This is what distinguishes them from event-driven automations, where a defined action follows a specific event. A workflow observes the same approval boundary as a conversation. Reversible merchandising runs unattended: rotating a collection to current best sellers, retiring members that stopped selling, tagging what sells. Anything touching money prepares a draft and waits — promotions and clearances, gift cards for customers who pass a spending threshold in a window, and markdown pricing rules over stock that stopped moving. Search merchandising works the same way on a schedule. A workflow keeps watching which searches convert badly and drafts a rule when one is worth fixing, so it follows whichever search is failing this season rather than the one that was failing when the rule was written. It proposes only when a search is both busy and converting well below your baseline, and only ever features a product that search already matches. A busy search that returns nothing at all is reported as a stocking decision instead, since a reordering rule has nothing to reorder. Where there is no cost data to choose by margin it says so rather than guessing, and it will not draft a second rule while one is still waiting for you. The money templates carry per-run limits. A promotion template drafts one promotion. A gift-card template drafts one card per qualifying customer, each of which is a liability the merchant owes, so a single run is capped on both the number of recipients and their combined face value; a rule matching more customers than the cap allows stops and reports that rather than drafting an arbitrary subset, and a cooldown keeps the same customer from being rewarded again on the following run. A markdown rule is scoped to the specific products it identified rather than the whole catalogue, is drafted switched off, and leaves only one draft outstanding at a time, so a weekly cadence cannot stack duplicates while the merchant decides. Every one of these limits is enforced in the database, not in the prompt.

​

Content on a schedule

Writing is a standing intent too: ask for a post or a lookbook on a recurring basis and each run produces a new one — a real piece, built around products you actually sell, with a cover image, saved as a draft under CMS. Nothing is published for you; it is your public voice, so you publish it. Give the rule either a fixed topic or a category. With a category it chooses its subject afresh every run from whatever shoppers are most drawn to there, so the piece follows real demand instead of repeating something you decided months ago. If nothing in that category drew interest that week, it writes nothing and tells you why. These run weekly at most, and a rule pauses itself once three of its drafts are waiting unread — publishing or discarding some starts it again.

​

Seasons and days

Any workflow can be scoped to part of the year and to particular weekdays — promotions, collections, tagging, gift cards, pricing and content alike, not only the writing ones. A season recurs. Set up a Black Friday rule for November or a Valentine’s rule for February once, and it wakes every year on its own; out of season it is skipped rather than switched off, so it comes back without you re-enabling it, keeping its name, settings and history instead of being deleted and rebuilt each year. A window can wrap the year end, for a mid-December to early-January run. Weekdays pin a rule to the days you mean. On its own a weekly rule is an interval, so it drifts by a day or so each time; naming Friday makes it land on Friday and stay there. They combine: Dynamic workflows are managed at Settings → Workflows, which is also where each one can be paused or removed. Alongside the configuration is the record of every run — what it did, and the figures behind the decision, so a change always has an explanation attached rather than appearing unannounced. A workflow that fails repeatedly switches itself off and says so, rather than retrying indefinitely.

​

Autonomous workflows

A workflow still begins as a request. Autonomous mode removes that step: the assistant watches how the store is performing and keeps the set of standing rules current on its own — setting up rules worth running, retuning ones whose thresholds have drifted from the business, and retiring ones that have stopped producing anything. It is opt-in per store, at Settings → Workflows, and it changes who maintains the rules rather than what a rule may do. The approval boundary is unchanged. Discounts, gift cards, pricing rules and search rules are still prepared as drafts and still wait for a person, under the same permission and on the same pages. What becomes automatic is the upkeep, not the spending. Three constraints hold it in place, and each is enforced in Galactic Core’s own code rather than left to the assistant’s judgement — they sit alongside the wider set of platform guardrails:

• A rule a person paused stays paused. Pausing is an instruction, not an untidy state to be corrected, so it is never restarted automatically.
• A rule that has ever acted is never retired. Retirement is reserved for rules that have produced nothing across a sustained run of evaluations, counted from the run log rather than asserted.
• Nothing happens without a record. Every adjustment writes a run entry carrying the figures it was based on, beside the entries for the actions themselves — and the two are distinguishable, so “what changed in my shop” and “what changed about my rules” remain separate questions.

Running in the background consumes AI credits, which is why the same setting establishes how they are replenished: an amount, the balance that triggers it, and a ceiling for the month. A payment that does not go through is reported by email, and a second failure stops the attempts rather than re-presenting the card. Without replenishment the assistant simply stops maintaining the rules; the rules themselves carry on running as they were. Where a store has a marketing goal recorded, the assistant reads it — what the merchant said they are optimising for, and until when — so its decisions follow that objective. Where there is none, which is the ordinary case, nothing changes.

​

Product pages

One workflow arrives with every store rather than being asked for. Once a month it looks for products whose search title and description are empty and writes them, so those pages can be found by search engines. It works from the product itself and from the terms shoppers on that store have searched for, it only ever fills a gap rather than replacing wording a merchant wrote, and it starts with the pages that have nothing at all. A catalogue larger than a month’s budget is covered over several months, emptiest pages first.

​

Seasons

A store’s seasons depend on where its customers actually are, so they are read from real storefront traffic rather than assumed. A store selling into the United States meets Thanksgiving and Black Friday; one selling into Britain meets Boxing Day instead; a store selling into both meets all three. Where there is too little traffic to say, nothing is proposed rather than something guessed. Each season carries the lead time an offer needs, so a rule is set up when there is still time to approve and stock it — not on the day. Seasons that suit particular catalogues are proposed only to the stores that sell those things. Dates that move from year to year, like Thanksgiving, are resolved to the exact day. What arrives is a standing rule rather than a finished promotion: it recurs each year, and what it prepares still waits for approval like any other offer.

​

Advertising and merchandising

The two sides read each other. A clearance rule leaves out products that advertising is driving sales to — otherwise the same merchant pays for the click and then discounts the sale it produced — and records how many it held back. In the other direction, the advertising side sees which promotions are live or scheduled, which markdown rules are active, and that changes are waiting on the merchant’s approval.

​

Rules that arrive with a store

A store set up by an agency can start with standing rules already running, chosen by that agency for the merchants it serves. They are ordinary workflows from the moment the store exists: the merchant pauses, retunes or removes them like any other, and what they change stays changed. Defining that set is described under agencies.

​

Limits

The number of standing rules a store may have, how long the run record is kept, and how many consecutive failures switch a rule off are all set per store, under Settings → Workflows → Settings. Each starts from a default appropriate to the plan and can be adjusted: a catalogue spanning dozens of categories and a focused one have different needs, and the ceiling follows the plan for any store that has not chosen its own.

​

Where the decision sits

The assistant never issues a gift card, activates a promotion, or turns on a pricing rule on its own. The margin check and the approval step are enforced in Galactic Core’s own code rather than left to the assistant’s judgement, so a prompt cannot talk its way past either; they are part of a wider set of platform guardrails. Every action it takes is recorded in your activity log under its own name, so an AI-assisted change is as traceable as a manual one. What it can see is bounded the same way. The assistant reads your store through a business schema — a fixed, named layer of business concepts — rather than querying your data directly, with the store bound before any concept is read, and margin arriving as a computed figure rather than as the cost behind it. That is how it can refuse a discount for selling below cost without the cost itself ever entering the conversation. The arrangement is described in full under the business schema the assistant reads through.