How to Productize an AI Agent Kit for Ecommerce

We productized an AI agent orchestration starter kit for localized ecommerce by shipping a working demo stack with mocked platform data and gating all platform adapters behind a signed LOI and deposit. That let sales run next week while engineering focused on adapters only when a prospect was real. This guide shows how we packaged it and the exact decisions that made it fast to demo and safe to scale.

AI agent starter kit for ecommerce: a prebuilt, multi-agent workflow with a branded UI, orchestration, vector memory, and mock data that proves value before any store-platform connector is written.

We designed and shipped this kit with Alex Jang for Korean ecommerce brands. The architecture is live as a demo build: adapters for Cafe24, Coupang, Smartstore, Sabangnet, and Amazon KR are created per prospect after LOI and deposit. That constraint is what keeps delivery time predictable and sales honest.

The problem it solves

A localized ecommerce agency needs to show agent orchestration that actually works: catalog Q&A, campaign planning, ops checklists, and reply drafting in the local language. Building five separate platform adapters before the first signed pilot stalls sales and burns engineering time on the wrong targets.

| Workflow | Manual per-prospect build | Productized starter kit | |---|---|---| | Demo timeline | 3 to 6 weeks to wire a platform and data | 1 to 3 days to stand up a branded demo with mock data | | Scope control | Adapters grow with every sales call | Adapters gated behind LOI + deposit and a defined adapter spec | | Engineering reuse | One-off code per platform | Shared orchestration, memory, and UI reused for every client | | Sales risk | Demos slip when platform access stalls | Demos run without any platform access | | Cost to change direction | High: rip and replace connectors | Low: swap mock dataset and persona, adapters untouched |

How the automation works

The kit is a thin product on purpose: a branded Next.js app, an orchestration layer, a vector-backed memory, and a persona library. It runs on mocked ecommerce data until a prospect signs: then we snap in a single adapter for that platform and tenant. No endpoints or secrets are touched before that point.

• Advisor and sub-agents: an advisor persona coordinates four Daily Ops sub-agents. We keep roles and tools declarative. Personas are a config, not code.
• Orchestration: jobs run through a serverless event orchestrator. Each job is idempotent and emits state so we can demo step-by-step plans or one-click execution.
• Memory: Neon Postgres with pgvector stores briefs, SKUs, campaigns, and prior plans for retrieval. We keep embeddings and raw text separate.
• AI gateway: requests flow through a gateway so we can change models without code churn and centralize cost controls. Anthropic lists Fable 5 at 10 dollars per million input tokens and 50 dollars per million output tokens (source: https://www.anthropic.com/news/claude-fable-5-mythos-5), which keeps demo runs inexpensive.
• Adapter boundary: a narrow PlatformAdapter interface hides each platform's specifics. We do not build an adapter until LOI and deposit clear.

Step-by-step: how to build it

1) Define the agent organization as code

Keep the org declarative so you can swap personas and tools per market without edits to business logic.

// src/agents/registry.ts
export type AgentDef = {
  name: string
  role: string
  tools: string[]
  language: string
};
 
export const advisor: AgentDef = {
  name: "Advisor.Brizzolara",
  role: "Owns planning. Calls DailyOps agents. Signs off deliverables.",
  tools: ["search", "kb.retrieve", "planner"],
  language: "ko-KR", // localized output
};
 
export const dailyOps: AgentDef[] = [
  { name: "Ops.Catalog", role: "SKU QA + spec lookup", tools: ["kb.retrieve"], language: "ko-KR" },
  { name: "Ops.Campaigns", role: "Offer and channel plan", tools: ["planner", "kb.retrieve"], language: "ko-KR" },
  { name: "Ops.Service", role: "Reply drafts from policy KB", tools: ["kb.retrieve"], language: "ko-KR" },
  { name: "Ops.Analytics", role: "Simple cohort and trend readouts", tools: ["kb.retrieve"], language: "ko-KR" },
];

Gotcha: do not let personas drift. Store persona prompts and tone in versioned files so sales can pick a voice at demo time without surprises.

2) Stand up the vector memory and schema

Use Postgres for durable state and pgvector for embeddings. Keep embeddings in their own table and reference by foreign key.

-- db/schema.sql
create extension if not exists vector;
 
create table knowledge_base (
  id            uuid primary key,
  tenant        text not null,
  doc_type      text not null,    -- policy, sku, campaign, faq
  locale        text not null,    -- e.g. ko-KR
  title         text not null,
  body          text not null,
  created_at    timestamptz default now()
);
 
create table kb_embeddings (
  kb_id         uuid references knowledge_base(id) on delete cascade,
  provider      text not null,    -- model family identifier
  embedding     vector(1536) not null,
  primary key (kb_id, provider)
);
 
create index on knowledge_base (tenant, doc_type, locale);

Gotcha: do not mix locales in the same retrieval set. Index by tenant and locale so the advisor never blends English and Korean snippets.

3) Wire an event-first orchestration

Every visible action in the UI emits an event. Orchestration fans out sub-jobs and collects results for the advisor.

// src/orchestration/plan.ts
import { inngest } from "../lib/inngest";
 
export const advisorPlan = inngest.createFunction(
  { id: "advisor.plan" },
  { event: "advisor/plan.requested" },
  async ({ event, step, db }) => {
    const { tenant, briefId } = event.data;
 
    // fan out to Daily Ops
    const [catalog, offers, service, analytics] = await Promise.all([
      step.run("catalog", () => step.sendEvent("ops/catalog.requested", { tenant, briefId })),
      step.run("campaigns", () => step.sendEvent("ops/campaigns.requested", { tenant, briefId })),
      step.run("service", () => step.sendEvent("ops/service.requested", { tenant, briefId })),
      step.run("analytics", () => step.sendEvent("ops/analytics.requested", { tenant, briefId })),
    ]);
 
    // assemble plan draft
    await db.insert("plans").values({ tenant, brief_id: briefId, status: "draft" });
    return { ok: true };
  }
);

Gotcha: make every step idempotent. Demos get clicked repeatedly. Use deterministic IDs per brief so replays update rather than duplicate.

4) Route model calls through a gateway

Keep the model swappable and centralize cost controls and headers. Aliases let you flip models without code changes.

// src/lib/llm.ts
export async function chat(messages: Array<{ role: string; content: string }>) {
  const resp = await fetch(process.env.AI_GATEWAY_URL + "/chat/completions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.AI_GATEWAY_KEY}`,
      "X-Model": "advisor-default", // alias resolved at the gateway
    },
    body: JSON.stringify({ messages, temperature: 0.3 }),
  });
  if (!resp.ok) throw new Error(`LLM error ${resp.status}`);
  const data = await resp.json();
  return data.choices[0].message.content as string;
}

Gotcha: never hardcode vendor model names in app code. Use a gateway alias so procurement and performance changes do not trigger redeploys.

5) Seed mock data and a demo harness

Give sales a switchable dataset per platform so demos feel real in seconds.

// scripts/seed-mocks.ts
import { sql } from "../src/lib/db";
import café24 from "./mocks/cafe24.json";
import coupang from "./mocks/coupang.json";
 
async function seed(tenant: string, dataset: any) {
  for (const doc of dataset) {
    await sql`
      insert into knowledge_base (id, tenant, doc_type, locale, title, body)
      values (${doc.id}, ${tenant}, ${doc.type}, ${doc.locale}, ${doc.title}, ${doc.body})
      on conflict (id) do nothing;
    `;
  }
}
 
await seed("demo-cafe24", café24);
await seed("demo-coupang", coupang);
console.log(" seeded");

Gotcha: keep mock corpora under a demo license and scrub product names to avoid implying vendor endorsement.

6) Lock the adapter boundary and ship stubs

Ship the interface and one proof adapter that throws until enabled. This makes the scope visible without the work being done.

// src/adapters/types.ts
export interface PlatformAdapter {
  name: string;
  // Read-only methods used by agents
  getCatalog(input: { tenant: string }): Promise<Array<{ sku: string; title: string }>>;
  getOrders(input: { tenant: string; since: string }): Promise<any[]>;
  // Write methods remain optional and toggled per tenant
  draftReply?(input: { tenant: string; orderId: string; body: string }): Promise<{ id: string }>;
}
 
// src/adapters/cafe24.ts
export const cafe24: PlatformAdapter = {
  name: "cafe24",
  async getCatalog() { throw new Error("Adapter not enabled. LOI required."); },
  async getOrders()  { throw new Error("Adapter not enabled. LOI required."); },
};

Gotcha: show the adapter toggle in the admin UI. When a prospect signs, flipping the toggle should be the only visible change before keys are added and tests run.

Where it gets complicated

• Adapter sprawl: building five connectors up front burns quarter time. We codified a narrow PlatformAdapter and refuse to implement one until a prospect signs and provides test credentials.
• Locale and tone: we set language at the agent level and keep tone files in version control. Mixed-language drafts were the first thing that tripped us up before we enforced per-tenant locale.
• OAuth and key hygiene: our first Gmail OAuth refresh token expired mid-sprint. We added a key-rotation checklist and a preflight that blocks deploy when required secrets are missing.
• Mock realism vs truth: mock SKUs and policy docs must be believable without leaking client IP. We created a writer's room for brand-safe names and seeded policies from public templates.
• Long jobs and retries: orchestration must be idempotent. We fingerprint briefs and plans so replays update drafts and UI stays stable during a live demo.

What this actually changes

For Alex Jang's localized ecommerce offer, we moved sales from platform-by-platform scoping to a single, repeatable demo that shows the exact value props prospects care about: catalog-aware replies, campaign planning, and ops checklists in Korean. The adapter work only starts after LOI and a deposit, which prevents speculative builds and channel drift. Model costs for demos stayed modest because requests route through a gateway and can target efficient models. As a reference point, Anthropic lists Fable 5 at 10 dollars per million input tokens and 50 dollars per million output tokens (https://www.anthropic.com/news/claude-fable-5-mythos-5), so a handful of demo runs cost pennies. The structural shift is what matters: sales can proceed on a fixed kit, and engineering effort is reserved for signed work.

Frequently asked questions

How do you demo real workflows without platform adapters?

We ship a branded UI, agent orchestration, and a vector-backed KB seeded with believable mock data. Demos run on that stack. The adapter layer is stubbed and toggled off until LOI and deposit. Once signed, we implement exactly one adapter for the prospect's platform and tenant.

What happens when a prospect uses a platform you have not seen?

We keep the adapter boundary narrow and documented. After LOI, we map fields and auth with the prospect's sandbox, write the adapter behind that interface, and run shadow-mode tests. The kit does not change. Only the adapter is new.

How long does it take to stand up the first demo?

One to three days in most cases. The kit is prebuilt: we customize branding, seed a localized mock KB, select a persona, and deploy. Adapters follow only after LOI.

Can non-technical teams operate the kit?

Yes. The sales-facing parts are UI driven: choose persona, pick dataset, click Run Plan. The admin panel exposes an adapter toggle and environment checks. Engineering is only needed when enabling a new adapter.

What does this cost to run monthly?

Infrastructure and model costs for demos are low. Requests route through a gateway so we can select efficient models. As a public reference, Anthropic lists Fable 5 pricing on their site. Real cost depends on demo volume and becomes part of adapter scope once signed.

How do you handle Korean language quality?

Language is set per agent, and we store tone and style in versioned files. The KB is localized. We run a review pass with a native speaker during the initial demo setup to confirm voice and terminology before sales starts.

If you want to package your own localized agent offer this way, we can stand up the same kit and hand you the adapter boundary and sales demo in under a week. See our overview of custom AI integration, read how we think about model choices in Claude Fable 5 for Business, and if you are ready to scope your kit, book a 15-minute call.