The intelligence layer is missing

Look at every wave of software in commerce SaaS over the last decade and the same shape repeats. Each wave built more of the execution layer. None of them built the intelligence layer.

Dashboards executed display. They surfaced the data, sorted it, charted it. Interpretation stayed with the merchant. Workflows executed automation. They moved a customer from one segment to another, fired an email when an event happened, triaged a return. Logic stayed with the merchant. Copilots executed drafting. They generated a campaign template, suggested a subject line, summarized a thread. Judgment stayed with the merchant. Agents executed action. They could perform the task; the merchant still had to decide what task to perform, in what sequence, with what tradeoffs.

Every wave shipped more hands. The expert kept supplying the head.

The intelligence layer is not the model. The model is rented. The intelligence layer is everything that has to wrap the model for it to operate inside a specific business — the data substrate, the formalized expertise, the decision history, the brand voice, the permissions, the action surface, the feedback loop. It is what converts raw foundation-model intelligence into operationalized judgment that can be trusted with real work in a specific vertical.

This layer exists today in every mid-market commerce SaaS. It is sitting on the company's servers and in its senior people's heads. It has never been delivered to the merchant because no form factor existed that could carry it. The Slack-resident teammate is one form factor. The prescription feed described in our Prescriptive Intelligence thesis is another. Both ship the same underlying intelligence layer. The wrappers differ; the layer beneath is identical.

The case for the next eighteen months is the case for shipping the intelligence layer in your vertical before someone else ships it in yours.

The wrapper sets the buyer's mental anchor

The wrapper and the capability are both required. The wrapper does work the capability cannot do on its own: it tells the buyer's brain what to compare the product to, and the comparison sets the price ceiling.

A feature gets compared to the next feature on a competitor's pricing page. Ceiling: $50–$200 per merchant per month.

A recommendation gets compared to the merchant's existing decision-making time. Ceiling: $200–$800 per merchant per month, which is where most operational mid-market SaaS plateaus.

An Employee gets compared to the merchant's next hire. Ceiling: $2,000–$10,000 per merchant per month. The merchant is picking between subscribe to this software and post the job rec, and the software wins on cost, ramp, and availability before the capability question is asked.

Same intelligence, three wrappers, twenty-fold price difference. The wrapper does not produce the intelligence. It produces the comparison that determines what the intelligence is worth.

Crazy, right?

The merchant's mental model already has the slot

Every operational business runs on roles. Merchandiser, retention specialist, email designer, returns analyst, influencer manager, paid acquisition lead. The merchant hires against those roles, evaluates against those roles, fires against those roles. An AI Merchandiser lands in a slot the merchant has already built cognitive infrastructure for. The buying decision compresses to is this Employee good enough to fill this slot for less than I would pay a person? — a question the merchant knows how to answer.

A recommendation feed asks the merchant to invent a new behavior pattern. A chatbot asks the merchant to invent a new ritual. These are the most expensive cognitive operations a B2B buyer can be asked to perform, which is why most intelligence features in SaaS today are adopted by under 10% of the user base regardless of the underlying model quality.

Employees inherit escalation for free

Everyone becomes a manager. Without getting paid manager salaries. Lol…

A human employee escalates to their manager when something is out of scope. The manager intervenes. The work continues.

The merchant has thirty years of organizational muscle memory around this pattern.

An AI Employee inherits the same pattern. The AI Merchandiser surfaces a $30K inventory commitment with margin uncertainty and routes it to the CFO for sign-off. The CFO sees a Slack message with the full reasoning chain, three options, the Employee's recommendation, a one-click approve button. He clicks. The work continues.

A chatbot cannot escalate because there is no role hierarchy. A recommendation feed cannot escalate because there is no concept of a task being out of scope. Only the Employee form factor inherits the entire escalation ladder for free, by mirroring the org chart it sits inside. The Employee can therefore be trusted with real work — not because the model is more capable than the model behind a recommendation feed, but because the wrapper produces a legible escalation path the merchant already understands.

Slack is the operating system of operational work

Sixty percent of mid-market commerce ops happens in Slack already. Sales, ops, CX, marketing, retention — all coordinating in shared channels, all @ mentioning each other, all running async standups and incident response and weekly reviews in the same surface. Teams covers most of the rest.

An Employee in Slack inherits the notification model, the @ mention pattern, the channel-context behavior, and the shared-history affordance the merchant's team is already trained on. Zero retraining. Salesforce internally runs Agentforce in Slack across 76,000 employees with 86% sustained adoption — numbers that occur only on top of behavior already established. The Employee rides Slack the way iOS apps rode the iPhone keyboard.

Every AI Employee is built on three substrates

Strip the wrapper from the picture and three substrates carry the rest of the work. They are what make the Employee credible, defensible, and pricable. They are also what foundation model providers cannot replicate inside your vertical, regardless of model quality. The substrates are the uncopyable delivery layer.

Proprietary data

Klaviyo has fourteen years of email performance data across 193,000 brands — open rates, click patterns, send-time effects, subject-line outcomes, conversion correlations across billions of consumer interactions. Loop Returns has 100M+ returns and 200M+ shoppers across 5,000+ Shopify brands, plus 1,000+ carrier integrations annotated with outcomes. Yotpo sits on 300M+ reviews from 15,000+ brands. Triple Whale tracks $82B+ in annual GMV across 50,000+ brands. Recharge sees subscription patterns and churn signals across thousands of merchants in every consumable category.

An Employee trained on this substrate is structurally better than any generic AI marketer wired into the same APIs. A horizontal AI player can read the API; they cannot read what worked across fourteen years of priors. That asymmetry is exactly what the model behind the Employee converts into judgment.

It is also why why not just build on top of OpenAI's agents directly fails the CTO's pressure test. OpenAI does not have access to the SaaS's proprietary substrate. The SaaS is not going to expose it. The Employee has to live where the substrate lives.

Formalized tribal knowledge

The most underused asset in the building and the one most engagements spend the most time on.

Every commerce SaaS has accumulated thousands of pages of unstructured operational context — internal SOPs, customer success playbooks, support ticket transcripts, founder explanations of how the product is supposed to work, escalation patterns from hard accounts, decisions made on edge cases, the senior retention strategist's mental model of when this pattern shows up in the data, the right move is usually X, except when Y, then Z.

None of it is structured. Most of it lives in Notion, Google Docs, Slack threads. Some of it lives only in two or three people's heads and dies when they leave.

Our open-source harness ingests this material via a YAML pipeline and consolidates it into a single canonical operational document the Employee reasons against. The same harness defines what the Employee is allowed to do — which actions auto-execute, which require approval, which trigger escalation, which are off-limits per merchant configuration. Permissions and knowledge live next to each other because both are operational context.

Check it out here:

Ionio-io/managed-ai-employees Open source harness →

This is what turns a generic AI Returns Analyst into one that knows we always offer store credit before refund for orders over $200, except for sale items, except for top-loyalty-tier customers who get the refund without question, and we always flag anything over $500 to the ops lead before resolving. None of that is in any foundation model. All of it sits in the SaaS's operational documentation, scattered across systems. The harness brings it together.

Brand authority in a category

The right, in the merchant's mind, to ship a credible Employee in this vertical. The substrate no engineering effort can manufacture.

Klaviyo has it in email. The merchant's brain has spent a decade categorizing Klaviyo as the company that runs my email, then a further few years categorizing it as the company that defines what running email is — to the point where the merchant's next hire's resume will list “Klaviyo” as a skill, recruiters will filter inbound on “3 years of Klaviyo experience,” and an entire ecosystem of Klaviyo Experts, Klaviyo agencies, and Klaviyo certification programs has grown up around the product.

The merchant does not buy Klaviyo software at this point. They subscribe to Klaviyo as a category the way SEMrush and Ahrefs subscribers buy into those products. The same dynamic exists for Recharge in subscriptions, Loop in returns, Yotpo in reviews, Gorgias in support. The depth of category authority is uneven across verticals; the pattern is consistent at the top.

At that depth, a $1,000–$2,000/month AI Employee is trivial to position. The merchant is buying Klaviyo expertise as a colleague, and they already pay for Klaviyo expertise in the form of consultants, agencies, and certified hires. The Employee is a more efficient delivery wrapper for an expense the merchant is already running.

Run the same thought experiment with Gorgias shipping an AI Email Designer. The merchant has to mentally re-categorize Gorgias from support vendor to marketing vendor. Re-categorization is the most expensive cognitive operation in B2B. The merchant says interesting and clicks away. Same product, different brand, different outcome.

Authority is perishable. Every quarter a vertical incumbent waits to spend it, three things happen. A competitor in the same vertical ships first and starts to claim the category language — the way Klaviyo did with Marketing Agent in September 2025, leaving Omnisend, Sendlane, Drip, MailerLite structurally in catch-up posture for four quarters running. Horizontal AI platforms — Lindy, Relevance AI, Ema, Dust — chip at the edges with generic Employees that do some of what a vertical incumbent could do, worse but available. Foundation model providers extend downstream — OpenAI Workspace Agents, Anthropic's Claude skills, Google Gemini Enterprise — each reducing the set of jobs a vertical SaaS can still credibly own.

The authority leaks a quarter at a time. The CEO who waits eighteen months because the technology will be better then has by then lost the asset they were waiting on, and will compete on technology against players who own both.

This is parallel infrastructure, not a feature

(or: why internal teams might struggle to build this)

The most common failure mode in this space is the one the CEO is about to fall into. Read the document. Forward it to the CTO. Tell them to figure out the AI Employees roadmap. Move on.

Six months later: a feature that technically works in a demo, has 8% adoption, generates no measurable lift on either ARPU or NRR, absorbs every quarterly review under the heading AI initiative — in progress.

An AI Employee is not a feature inside Klaviyo. It is a harness over Klaviyo.

The feature team's work — what they ship sprint after sprint — sits inside the product. New flow builders, new segmentation tools, new template editors, new attribution dashboards. They are building parts of the product itself. The Employee is a completely different shape: a colleague that uses the product's features, makes decisions across them, reasons over the substrate, talks to the merchant in Slack. The Employee operates on Klaviyo. The feature team operates in Klaviyo. These are different layers of the same system, and they cannot be built by the same team using the same process.

This is why internal teams struggle to ship the Employee. The work shape is unfamiliar. Feature teams have not built harnesses before — they have built features.

The skills are adjacent but not identical: agent orchestration patterns, permission models per merchant, knowledge ingestion pipelines, white-label deployment topology, validation frameworks for non-deterministic systems.

Each one is its own specialty. The team that ships a returns flow in two weeks needs three months to ship the first version of a returns Employee, and the first version usually does not work.

The technical aspect of harness-building is real but partially commoditizing. Open-source frameworks and reference implementations — including the one we have published — have lowered the floor. The durable advantage now is sequencing experience: knowing which corners to cut, which abstractions to ship first, where to use foundation models and where not to, how to structure the tribal knowledge harness, what the validation framework needs to cover, how to white-label without bleeding the SaaS's brand into the merchant experience. Teams that have shipped this multiple times know the sequence. Teams that have not are learning from scratch on the production version, which is where the 70% internal-AI-failure rate comes from.

The harness

Read the thesis to here and the natural CTO question is: show me what is actually in the harness. The honest answer is that four primitives — wired in a specific order, with a specific permission model around them — carry the entire AI Employee.

The reference implementation is open-source. The four primitives are these.

One — the teammate surface. A webhook host that receives Slack events (or Teams, or in-product), verifies the signature, and routes each @ mention or DM to the agent.

In the reference implementation this is a Next.js route handling Slack's standard event subscription model — app_mention, message.im, message.channels — with HMAC verification on every payload.

This surface is what makes the Employee feel like a colleague.

The Vercel Chat SDK handles that streaming-into-one-message pattern, which is what turns AI response into colleague typing in real time. Get this wrong and the Employee posts walls of text into the channel like a chatbot. Get it right and the merchant's team forgets which colleagues are human.

Two — the agent loop. The Claude Agent SDK runs the loop. Per-merchant context, per-merchant memory, isolated subprocess. The merchant's Employee never sees another merchant's data, never sees another merchant's decisions, never sees another merchant's brand voice — even though every Employee runs on the same harness, the same model, and the same SaaS infrastructure. Each invocation is a fresh subprocess with that merchant's permissions, that merchant's MCP server set, and that merchant's accumulated memory loaded from the canonical operational document.

Three — MCP, the substrate connector. This is where the SaaS's proprietary data layer plugs in. Every SaaS's existing API surface gets wrapped once as an MCP server, and the Employee reads and writes through it for the rest of the harness's life.

The merchant's Notion is one MCP server. The merchant's Shopify is another. The SaaS's own substrate — Klaviyo's fourteen years of email performance data, Loop's 100M+ returns history, Yotpo's 300M+ reviews — is the third.

Swap notion for klaviyo, shopify, loop, yotpo. Anything you want.

This is what reusability across vertical SaaS looks like at the code level — and it is also why the why not just build on top of OpenAI's agents objection collapses on inspection. The SaaS owns the data; the SaaS publishes the MCP server; the harness routes through it. A foundation model provider extending downstream does not get to skip that step. They can read the public API. They cannot read what the SaaS chooses not to publish, which is most of the substrate that matters.

Four — the permission gate. Every tool call routes through a canUseTool function before it executes. The default disallow list hard-denies destructive primitives — shell, file write, file edit, notebook edit, kill-shell. The allow list is small, explicit, and per-merchant configurable. The gate is what makes the Employee trustworthy with real work.

Without it, an AI Employee is a remote code execution surface attached to untrusted Slack input. With it, the Employee inherits the same approval ladder the merchant's organization already runs on, mirrored in code.

UI/UX design for this

The four primitives are the engine; none of them are what a human looks at. The Employee works in Slack, but it gets hired, governed, and measured here — the only screen a non-engineer ever touches.

• The hiring page. A wizard that treats standing up an Employee like onboarding a person — pick a role, connect data and tools (the MCP primitive, made clickable), drop in the SOPs and watch them read back as plain-English rules, set the guardrails (primitive four, as Off / Needs approval / Auto). This is where the buyer files the product under next hire, not next feature.
• The dashboard. One page where the Employee becomes a colleague you manage — impact priced against a human hire, an approvals inbox with one-click sign-off (escalation-for-free), the task board and activity feed, and what it's learned: the accumulated SOPs and decisions that make leaving expensive.