We do this in a way that respects the visitor's privacy at the architecture level, and we charge for the work we do, not for permission to read the merchant's own data.
This document is the version of Auraflow we keep coming back to when we're deciding what to ship and what to leave on the table.
What we do
Auraflow sits inside a Shopify store and produces three things the merchant didn't have access to before.
Live intent intelligence. Every visitor on the storefront is observed in real time and classified across five archetypes: Researcher, Comparison shopper, Hesitant buyer, Bargain hunter, Loyalist. The classification happens server-side, in roughly four seconds from landing, without third-party cookies and without raw behavioural data ever leaving the visitor's device.
Smart Capture. When a visitor's intent crosses threshold, Auraflow fires a personalised offer with the product they actually engaged with, written in the merchant's brand voice, sent on the merchant's domain. Not a pop-up. Not "wait, 10% off." A specific moment for a specific visitor.
An agent layer. The merchant types in plain English. The agent picks the right tools, asks for approval where it should, and runs them across Klaviyo, HubSpot, GA4, and Shopify. The merchant's session holds the identity. The agent never operates with privileges the merchant doesn't have.
What we won't build
We've made a few choices early that close certain doors deliberately. Naming them matters more than naming the features we ship, because the doors we close are the shape of what's left.
We won't ship a "discount code" feature as a personalisation tool. Discount-coded visitors return less often than visitors who got a personalised capture moment instead. A discount buys the order in front of you. It doesn't earn the customer.
We won't pool merchant data into a shared model. Each merchant gets a model trained only on their own store's traffic. A supplement brand's bargain hunter behaves differently from a luxury watch brand's bargain hunter. Pooling them produces a model that's bad at both.
We won't be an OpenAI wrapper with a markup. The merchant brings their own AI key (Claude, ChatGPT, Gemini, Kimi). Prompts go from the merchant's browser to their provider. We never see them, never proxy them, never train on them.
We won't treat compliance as a marketing checkbox. The constraints the regulations describe are the constraints we built the architecture to. There isn't a separate "GDPR mode" that turns features off in EU traffic. The mode is on for everyone, because the architecture doesn't permit anything else.
The editing constraint The doors we close are the shape of what's left.
What we guarantee
These are commitments we will not negotiate as we grow. They are written into the architecture, not the marketing.
Postgres row-level security enforces it at the database. The database physically refuses to mix one merchant's rows with another's. There is no shared visitor table, no cross-merchant identifier, no representation of your data outside the scope of your store.
Per-store keys. Recovering them requires the merchant's own credentials. We can't read them if we wanted to, and we don't want to.
If anyone changes a single byte of the script that runs on your customers' devices, the browser refuses to run it. The trust chain is verifiable end to end.
We don't ship features that change merchant data behaviour without an explicit opt-in. Every default is set to the conservative position. You move the slider when you're ready, not before.
We charge for the platform we build. We never mark up the cost of the model you use through it. Bring your own key. Pay your provider direct.
Not now. Not later. Not in any form. The architecture isn't designed for it, and we couldn't do it without breaking the design.
What we're building toward
A Shopify store should know its high-intent visitor before they reach the cart. The merchant should be able to act on that knowledge from one place, in one sentence, without leaking data to four different vendors. The visitor should never feel surveilled, and the merchant should never feel surveilled by their tools.
That's the version of the product we're building. We're a long way from done.
The version available to merchants today is the foundation: classification, Smart Capture, the agent layer, and the integrations. The version we're building toward is one in which the merchant's entire customer relationship runs through a single intelligence layer that respects both sides of the storefront.
Who we are
Auraflow is built by Kosmatic Inc. We're pre-launch as of mid-2026, with a small team and a small set of merchants on the waitlist willing to test what we ship. We don't have the customer numbers other tools advertise. We're not pretending to. We're building the architecture first, because retrofitting it later is expensive.
We write down what we believe, then we ship the code that proves it. When the two don't match, we change the code.
The waitlist is open at kosmatic.com. Email reaches the team directly. We answer.
We don't run an automated AI support chatbot. We don't run a sales team. We run a product team, a few channels of operator conversation, and the conversation closes the loop on what we build next.
The shape of the product is the shape of what we're willing to commit to. This is the shape.
The Auraflow Team