The AI workflow is your new SOP — and your new liability
Every serious cross-border operation I know is running five to fifteen AI workflows nobody wrote down. A support prompt lives in a Google Doc, a review-classification script lives in a consultant’s private repo, and a refund-approval guard lives in a group-chat thread from March. That is not an AI problem; it’s an operations problem. The moment you automate a refund decision or a marketplace complaint reply, you have written a policy in code, whether you admit it or not. That’s why an open-source DSL called Finyuus from Mnexium AI caught my attention. It treats AI logic the way mature commerce teams treat SQL: as a versioned, reviewable asset that doesn’t live inside application code. For cross-border sellers, this is the difference between an automation you can audit and an automation that will eventually audit you.
What Finyuus actually is, and why the “DSL” word shouldn’t scare you
A domain-specific language is just a small language built for one job. Finyuus’s job is to compose AI workflows: prompts, tool calls, retries, guards, approval waits, and child workflows. The maker, Marius Ndini, founder of Mnexium AI, says he built it after maintaining 300-line system prompts in the same codebase as an iPhone app’s buttons and screens. Every small behavior change meant rebuilding and redeploying the whole app. His parallel: applications talk to databases through SQL, so data logic lives independently from app code. Finyuus wants the same separation for AI logic.
Technically, Finyuus is an indentation-based DSL. If you’ve used Python, you’ll feel at home; if you’re a marketer, you’ll wonder why everything is whitespace-sensitive. It’s backed by Temporal for durable execution — retries, cancellation, long-running waits, and child workflows — and Langfuse for tracing and cost reporting. Workflows are stored as text, so they get version history, pull requests, and readable diffs, something visual builders lose at scale. It’s open source and runs locally via Docker, with the infrastructure services bundled in.
The last detail is the one that matters most to e-commerce. Finyuus includes guards and human approvals as part of the workflow definition, not as an afterthought. In cross-border operations, that’s the difference between an AI that suggests a $50 refund and an AI that executes a $50 refund. The workflow file can say “wait for approval” before the refund API call, and an auditor can see that in a diff. The maker’s bigger vision is that enterprises will form AI teams the way they once formed data teams with SQL: people who write, version, and operate AI workflows as a discipline, not as a side project.
How it differs from the tools you’re already using
Most sellers I meet are running AI workflows in one of two buckets.
First, visual automation tools: Zapier, Make, and n8n. They’re excellent for connecting a form to a spreadsheet, but they become unmanageable when a workflow needs branches, retries, and human approval gates. And a visual builder cannot give you a meaningful diff. Your “review” of a changed workflow is a screenshot in a Slack channel. One commenter on the launch thread put it well: keeping workflows as plain text is his favorite part because pull requests and diffs are hard to give up once a project grows. Visual tools feel easy on day one and expensive on day ninety.
Second, code libraries: LangChain-style frameworks. They give you full power, but AI logic gets tangled into application code. The maker’s critique is that a Python workflow can import anything, call anything, branch on anything, so there is no bounded surface to review. Finyuus’s DSL is constrained enough to parse a workflow and statically extract “these tools, these guards, these approvals” without executing it. For an operator who needs to audit AI behavior written by someone else — a contractor, a former employee, an agency — that static analyzability is genuinely valuable.
Finyuus positions itself between those two bad options: a constrained text format with a real execution engine underneath. The maker’s complaint about workflow tools is that they are locked in and difficult to productionize. For a seller, that’s the difference between a demo automation and an operation you can hand to the next employee without a week of context.
The SQL analogy cuts both ways
The “SQL for AI” framing is smart, but it’s also a warning. SQL won because it was one language across every engine. Finyuus’s DSL runs on exactly one runtime. The maker seems to understand this; he said that even if this DSL doesn’t win, it would be good to have something like it for LLMs. That is the right ambition and the wrong pitch for a seller who needs stability. You don’t want to build your refund-policy automation on a language that might not exist in two years. But you do want to build the discipline it represents.
What cross-border sellers can borrow from Finyuus this week
Treat prompts like purchase orders
The most transferable idea is separation. You don’t need a DSL to separate AI logic from app code. You need a rule: no production prompt changes outside a pull request. If you use Shopify for your DTC store, create an ai_prompts folder in your repo and treat every prompt change like a theme change. That gives you version history, blame, and a way to roll back when a support bot starts saying something unhinged. The same discipline applies to listing copy, review responses, and ad creative generation.
Put human approval gates where money moves
Finyuus’s guards and approval waits are the most commercially relevant part. In cross-border e-commerce, money moves in refunds, price changes, repricing rules, and ad budget increases. An AI agent should be able to draft a refund, but a human should approve it above a threshold. That is not just risk management; it is the paper trail you will need when a payment processor or marketplace asks what happened. Every serious automation should have an approval owner, not just “an admin.”
Why Amazon sellers should care more than Shopify ones
On Amazon Seller Central, the cost of an automation mistake is not a bad customer experience; it’s a policy violation. One automated message that admits a product defect, one repricer that drops below the minimum, one review-response template that asks for a removal — each can get you suspended. You need to show the exact prompt version, the exact inputs, and the approval step. Shopify merchants own the storefront and can apologize and fix. Marketplace sellers are renters, and the landlord audits with bots. That asymmetry is why Finyuus’s versioning and governance model matters more than any visual builder’s convenience.
You should also instrument every workflow for cost and traceability. You need to answer three questions for every AI run: what did it see, what did it decide, and what did it cost? Langfuse is one way, but the habit matters more than the tool. Without traceability, you are flying blind. With it, you can turn AI operations into a line item you can optimize, not a mystery expense.
Where the math breaks
I want Finyuus to succeed, but I wouldn’t build my entire operations stack on it today. The first problem is infrastructure weight. One commenter made the point bluntly: Temporal, ClickHouse, MinIO, Langfuse, and Redis to run a prompt is not something anyone spins up on a Tuesday afternoon. The maker’s answer — it’s one Docker command, not five manual installs — is fair but misses the adoption point. The first evaluation happens in ten minutes. If the first ten minutes are Docker pulls, the evaluator is gone. The maker later published a standalone CLI on npm, which is a good sign, but it should have been the first thing users hit.
The second problem is lock-in. A DSL that only runs on one runtime is a bet. The maker himself concedes that a thin Python wrapper gets you 80% of the value with zero learning curve for a small team. The DSL only pays off when you have reviewers, auditors, and enterprise-scale teams. Most cross-border sellers are not there yet. If you adopt Finyuus now, you are betting that the tool survives long enough to justify the learning curve.
The third problem is the missing enterprise layer. SSO/SAML and security are not built yet. The maker says he would shift focus to SSO as soon as one customer needs it. That is a sensible startup strategy, but for a brand with thirty people on tools, or a marketplace seller who needs to show compliance, the absence of SSO and security review is a blocker, not a nice-to-have. One commenter was right: the SSO/SAML gap might matter more than the language question.
My honest judgment
Finyuus is not ready to become the default AI workflow layer for cross-border e-commerce. But it is a useful mirror for how weak most sellers’ AI governance is. The launch thread is unusually honest: the maker defends static analyzability, concedes the Python-wrapper argument, accepts the infra-weight critique, and then ships the CLI. That responsiveness is rare. If Finyuus survives, it will be because it treats AI workflows as regulated text, not as magic buttons. If it doesn’t, the discipline it’s pushing for will still be the right answer.
What I’d watch / test next
This week, do three things. First, inventory every AI workflow your operation depends on. Write each one as a plain-text markdown file with four sections: trigger, prompt, tools and actions, guards and approvals. Put them in version control. That is 60% of Finyuus’s value with zero infrastructure. Second, if you have any technical person on the team, spend ten minutes with the Finyuus CLI and its docs and try to encode one real workflow — ideally a refund-approval flow. Third, watch whether Finyuus ships a zero-infrastructure mode and SSO/SAML. The maker has already published the CLI in response to feedback; the next test is whether the first-run experience outlives the second run.
