by Rashed

We shipped an auth bandaid at 2am. Cookies wouldn’t flow between platform.ginilab.com and our gateway, which was running under a different registrable domain. Browsers blocked them, correctly. The bandaid that unblocked the demo was a 5-minute bearer token held in a Zustand store on the frontend, attached by hand to every request. It worked.

Within 24 hours we’d shipped four PRs of cookie-domain workarounds. Then someone asked the obvious question: “why isn’t api.ginilab.com just another hostname on the same gateway?” It was. We were deep into a problem we’d solved in a single DNS record.

That bug — cookie-domain mismatch in a multi-brand platform — is the one-paragraph version of why this post exists.

One caveat before we go further. v3 is in staging. It’s not yet processing live payments. 300+ restaurants run on our legacy PHP/MySQL stack today, and the cohort migration hasn’t started. What follows is the architecture we bet on and the pain we hit getting here, not a victory lap. If you want a “we scaled to a billion requests” story, this isn’t it. If you want an honest mid-migration account from a small team, read on.

What “platform-per-brand” actually means

Ginilab is one backend platform that runs four products. Tomafood is restaurant ordering, with 300+ restaurants live on the legacy stack and the full rewrite to v3 in progress. CloudPOS is a POS for non-food retail. iSchool is school management. Ecommerce is generic ecommerce. Tomafood is the full rewrite. The other three consume shared services via REST or SDK. They aren’t separate codebases. They aren’t separate backends. They’re different products mounted on the same platform.

This is unusual. Most SaaS teams either build one product and stay there, or build separate platforms per product when product two arrives. The shared-platform-across-products shape is the third path, and it has a tax: every architectural decision has to assume more than one consumer, more than one brand, more than one domain. The tax shows up early and never goes away.

We took the tax on purpose. We knew CloudPOS and iSchool were coming. Without that, this would have been overengineering.

[INSERT DIAGRAM 1 HERE — architecture sketch: four products on top, shared multi-hostname gateway in the middle, shared services below keyed by business_id + app_id, Tomafood-only restaurant-service off to the side.]

We rejected the obvious answer twice

The obvious answer when a second product appears is to fork. Take the codebase that works for product one, copy it, change the domain, run a second backend. Engineers know how to do this. It feels safe.

We rejected it twice. The first time was when CloudPOS came online and the temptation was to fork Tomafood’s auth service and run it as a second backend behind the POS product. The second time was when iSchool was scoped and the temptation flipped: extract microservices per product, one stack per vertical. Both options were wrong for the same underlying reason. A customer who orders on Tomafood and later signs up for CloudPOS should be the same identity. Forking the auth service means reconciling those identities later. Per-product microservices means reconciling them four times.

The version that doesn’t require reconciliation is one auth service, multi-tenant by design, with every shared service carrying both who the business is and which product they’re using.

The design rule that makes it work

Every shared service in the platform — auth, addresses, payments, notifications, gateway — carries two identifiers on every query:

• business_id is the specific business (UUID).
• app_id is which product they’re using: tomafood, cloudpos, ischool, and so on.

Not restaurant_id. There is no restaurant_id column anywhere in a shared service. restaurant_id is a Tomafood-only concept that lives only in the Tomafood product service.

The pair flows through JWT claims and is enforced at the repository layer. We say this in the CLAUDE.md at the root of the repo about as bluntly as we can:

Shared services NEVER use restaurant_id — always business_id + app_id.
Repository enforces WHERE business_id = ? on every query.
JWT claims include businessId + appId.

In practice that means a row in auth_db.users doesn’t know what a restaurant is. It knows it belongs to a business, and the business runs on an app. A row in restaurant_db.recipes does know what a restaurant is, because restaurant_db belongs to Tomafood and restaurant_id is meaningful there.

The boundary is consistent. Shared services see businesses. The Tomafood product service sees restaurants. That sentence took us a long time to write down, and longer to enforce.

[INSERT DIAGRAM 2 HERE — decision tree: shared service? then business_id + app_id. restaurant-service? then restaurant_id is fine. Neither? then you’re in the wrong file.]

The multi-brand pain, made concrete

The cookie story from the opener is what happens when “multi-brand” stops being an abstract design rule and becomes a Tuesday. Each restaurant on Tomafood can run on its own white-label domain — their brand, their registrable domain. The platform has its own brand. The gateway has to accept cookies from all of them.

The first version of the cookie-domain helper was a security hole. It checked host.includes('ginilab.com') to decide whether to set the cookie’s domain attribute. A lookalike host like ginilab.com.evil.example would have passed that check. The second version checks suffix-with-leading-dot:

// packages/shared/src/cookies/pick-domain.ts
export function pickCookieDomain(
  origin: string | undefined
): string | undefined {
  if (!origin) return undefined;
  const host = new URL(origin).hostname;
  if (host.endsWith('.ginilab.com')) return '.ginilab.com';
  // ... plus one branch per brand registrable domain
  // Lookalike-domain defence: must end with the LEADING dot,
  // not just contain the string.
  return undefined;
}

A handful of lines. They exist because we have more than one brand on one platform. If we’d had one brand, this would have been a hardcoded constant. If we’d had four separate backends, each one would have hardcoded its own constant, and the bug would live in four places.

This is the smallest, ugliest example of the platform-per-brand tax. There are larger ones. They all have the same shape: a thing that would be a constant in a single-brand world becomes a function in a multi-brand one. The function is the cost.

What we picked, what we rejected, why

We picked one backend platform, multi-product, multi-brand. Shared services keyed by business_id + app_id. The Tomafood-only product service keeps restaurant_id. JWT carries both identifiers. The same gateway is exposed under per-brand hostnames so cookies flow.

We rejected one codebase per product — four backends, four auth services, four databases. This is the standard SaaS path and most teams’ default. We rejected it because the products share customers and the reconciliation cost compounds. A user who shops on Ecommerce and orders on Tomafood and whose kid is on iSchool is one human. Four backends would turn that human into four accounts with four passwords and four address books, held together by sync code. We would be writing and maintaining that sync code for years.

We rejected microservices-per-product from day one. Per-vertical stacks, one platform-org per product. We rejected this because we’re a small team and the operational surface scales with services rather than users. Splitting before a second consumer exists for any given surface is premature. Our restaurant-service today is a deliberate monolith — it contains menu, orders, kitchen, tables, drivers, reservations, and reviews in one deployable. We will split a surface out the moment a second consumer (CloudPOS, iSchool) needs that surface, and not before.

We gave up the freedom to ship a product-specific schema change without thinking about other products. Every shared schema change has to consider all current and plausible future consumers. That slows down week-to-week work. The bet is that it speeds us up over the lifespan of the platform.

What we got is more boring than it sounds: one auth service, one identity model, one set of secrets to rotate, and a single place to fix every helper.

The takeaway

Platform-per-brand is a bet on product-multiplication. We made it because we knew CloudPOS and iSchool were coming. If you only ever ship one product, this is pure overhead. Every shared-service decision costs more than it would in a single-product codebase, and you get none of the payoff. If you’ll ship two, the difference is one team versus four. If you’ll ship four, there is no version of this where fork-and-clone stays survivable.

Two questions worth sitting with before betting the same way. Do you know what product two looks like? Does it share customers with product one? If both answers are yes, the platform shape pays off. If either is no, it’s overhead.

We’ll come back to specific pieces of this in later posts — the idempotency middleware on money paths, the multi-zone CDN purge, the Valkey vs Redis pricing fight, the strategic monolith. Each is its own story. This post is the foundation. Every later decision in the series only makes sense because the platform shape was already chosen.

TL;DR — AI repeats your patterns badly, ignores existing services, and forgets every cross-session lesson you taught it. This isn’t laziness — it’s a new kind of tech debt: invisible, systemic, and architectural. Project memory hints don’t scale. Bigger context windows don’t help. The fix is structural: pin a graph projection of your codebase to every commit, let AI read it before writing, surface “graph stale” prompts when source drifts. Real commit receipts from my own OSS project aming-claw inline. Architects, change my mind in the comments.

What is AI tech debt?

Let me define this precisely, because it’s a different beast from the tech debt you already know.

The core asymmetry: the more your team uses AI for coding, the more invisible debt accrues — and you have no tool that sees it.

5 symptoms (diagnose yourself)

Run this checklist against your team:

• ❌ AI re-implemented a service that already exists
• ❌ AI shipped code using a pattern completely inconsistent with everything around it
• ❌ AI didn’t see the implementation sitting in the next file over
• ❌ Every new session repeats the same mistakes you corrected last time
• ❌ AI treats a familiar codebase as if it were brand new

Three or more? You’re accruing AI tech debt. The bigger your team and the more AI you use, the faster it compounds.

A real case study: my toolboxclient stateService

I’m the maintainer of toolboxclient (open-source cross-platform AI agent runtime, 274+ stars). I asked AI to add a stateService.

The directory server/services/ already contained, in clear sight:

TOOLBOXCLIENT/server/services/
├── fingerPrintService.js
├── memoryService.js
├── providerModelService.js
├── proxyService.js
├── taskService.js
├── toolServiceManager.js
├── walletService.js
└── webSocketService.js

Roughly a dozen services, all sharing the same HTTP pattern.

What AI shipped (commit 68487cc, 2026-03-19):

// AI's version: WebSocket-based StateClient with Proxy
class StateClient {
  constructor(agentName) {
    // 🚨 WebSocket, not HTTP — inconsistent with every other service in the folder
    this.ws = new WebSocket(...)
    this._data = {}
    this.state = this._createProxy()
  }

  _createProxy() {
    // Proxy traps to broadcast via WebSocket
    return new Proxy(this._data, { ... })
  }
}

It used WebSocket instead of HTTP. It used a Proxy-based intercept-and-broadcast pattern unlike anything else in the codebase. It built a parallel architecture next to an established one.

This wasn’t a code bug. It was a pattern bug. AI literally couldn’t see the existing services.

The first fix: project memory

My first instinct: add a hint to project memory.

use existing HTTP services, don't add WebSocket

AI refactored cleanly (commit bbdf82c, 2026-03-21):

feat: stateService Phase A+B — HTTP CRUD + SSE broadcast

Phase A: /api/state/* routes (read, write, session CRUD, language pref)
Phase B: SSE subscribe endpoint with topic filtering + EventBus broadcast

74/74 tests pass. No breaking changes — additive only.

WebSocket gone. HTTP CRUD + SSE matching the existing pattern. Clean fix.

For about ten seconds, I thought I’d solved it.

Why project memory hints don’t scale

Then I realized something uncomfortable:

This catch only worked because I noticed.

The next AI session would start with zero memory of this lesson.
Every context window starts as a blank slate.

This is the systemic nature of AI tech debt:

• AI can’t see existing patterns when it writes
• I see it → I fix it once → the fix doesn’t propagate to future sessions
• Manual project memory maintenance puts the work back on me, not AI
• This doesn’t scale — and the failure mode is silent

The first insight

I stopped trying to fix prompts and started looking at the structural problem:

AI agents don’t need bigger context windows.

They need a persistent structural record of the project that survives across sessions.

Context windows are short-term memory. What’s missing is long-term, project-level memory — something any AI session can read before writing.

This is the insight that turned into aming-claw.

Building aming-claw (and falling into the next trap)

The idea: give every AI session a queryable graph of the project. Files, modules, functions, patterns — all of it, machine-readable, persistent.

• Scan the codebase → build a graph of all entities and relations
• Expose it through an MCP server that any agent can query
• AI reads the graph before writing
• Graph persists across sessions

I built it. It worked. Then it broke — at a higher layer.

I had implemented the graph with:

• Mutable nodes — agents could edit graph state directly
• A patch pipeline — 5-stage mutation flow (propose → validate → review → apply → snapshot)
• A graph editor UI — humans could also edit the graph

Within a few weeks, the graph drifted from the actual code.

Why? Because I had created a second source of truth:

• The real source of truth was source code
• But I also let the graph be directly mutated
• The two sources inevitably diverged

Same trap. Higher layer.

The real architectural insight

After hitting the same trap twice, the answer crystallized:

The graph is something you edit.

The graph is a projection of the commit.

In concrete terms:

Every commit can correspond to one graph

git commit (modifies source / hints / config)
     ↓
system detects: HEAD ≠ graph's bound commit
     ↓ ⚠️ "graph stale" prompt
user decides when to reconcile
     ↓ user-triggered
fixed_algorithm(source + hints + config)
     ↓
new graph snapshot ←→ new commit hash

4 key invariants

Why not a git hook?

A reasonable question: why not auto-rebuild the graph on every commit via a git hook?

Three reasons I deliberately didn’t:

1. Reconciliation is expensive (full codebase scan + algorithm)
2. Surprise auto-builds destabilize state — user should control when state changes
3. Batching commits before a single reconcile is often what users want

The system shows a graph stale indicator in dashboard and CLI. Users reconcile when they’re ready. This is a deliberate design choice, not a limitation.

How modification and rollback work

Logic lives in code. The graph is a read-only projection.

How this solves AI tech debt

Returning to the original problem: AI repeats patterns badly because it can’t see the codebase.

The architectural fix:

1. Every AI session starts by querying the graph (via MCP)
2. The graph records the full structure — files, functions, modules, patterns
3. AI sees, for example, existing HTTP service pattern in server/services/
4. AI reuses the pattern instead of shipping a parallel WebSocket implementation
5. After AI makes changes → user commits → system flags graph as stale → user reconciles → next session sees updated patterns

Cross-session knowledge transfer happens through the graph, not the prompt.

This is what “solved at the architecture layer” means: it’s not a smarter prompt, it’s a different topology of state.

Coming up: the algorithm itself

This post covered why the projection model works. The next post covers how the algorithm builds the graph:

• in-degree=0 entry detection
• DFS 3-color marking
• Tarjan SCC for cyclic clusters
• 6-signal layer scoring
• Cross-language fact pipeline (Python + TypeScript)

Follow me here to catch the next one.

Change my mind

I claim this architectural pattern solves AI tech debt: every commit corresponds to one graph + user-triggered reconcile + stale-state prompt.

Your turn. Two architectural choices:

• Treat project state as a single source of truth, commit-bound
• Or maintain a separate memory store that AI writes to

Which is more robust? Which scales better? Where would you attack my approach?

Calibrated invitation: I want senior engineers and AI infra people to push back with specifics. “What about X?” or “Have you considered Y?” lands better than “this won’t work.” If you’ve shipped something adjacent, tell me — I want to compare designs.

core ของ Garudust เปิดเผย primitive พื้นฐานตัวเดียว: agent.run(task) ทุก entry point — ไม่ว่าจะเป็นข้อความจากแชท, cron job, หรือ webhook call — ล้วนลงเอยที่ call เดียวกันนี้ทั้งสิ้น นั่นหมายความว่าระบบภายนอกใดก็ตามที่ส่ง HTTP POST ได้ ก็สามารถเป็น event trigger ให้ Garudust ได้เลย

บทความนี้จะอธิบายว่ามันทำงานอย่างไรในปัจจุบัน, pattern ที่ใช้งานได้จริงใน production และ use case ที่เป็นรูปธรรม

Webhook Adapter ทำงานอย่างไร

เมื่อ Garudust ถูกตั้งค่าให้ใช้ webhook platform มันจะเปิด Axum HTTP server และลงทะเบียน POST endpoint ไว้ที่ path ที่คุณกำหนด request ขาเข้าจะมีหน้าตาแบบนี้:

{
  "text": "A new billing invoice has arrived from Acme Corp for $4,200.",
  "callback_url": "https://your-system.example.com/garudust/reply",
  "user_id": "billing-watcher",
  "session_key": "billing-acme-corp"
}

Garudust จะห่อข้อมูลนี้เป็น InboundMessage, ส่งผ่าน GatewayHandler, spawn agent.run() ขึ้นมา และเมื่อ agent ทำงานเสร็จก็จะ POST คำตอบกลับไปที่ callback_url:

{
  "text": "Invoice from Acme Corp for $4,200 — categorised as SaaS/Infrastructure. Flagged for approval above $3,000 threshold. Draft approval request sent to #finance."
}

HTTP response ที่ตอบกลับ POST ของคุณทันทีคือ 202 Accepted — agent ทำงานแบบ asynchronous

Security

Garudust ตรวจสอบ HMAC-SHA256 signature ทุก request ที่เข้ามา ตั้ง shared secret ใน config แล้ว sign ทุก POST ขาออกด้วย:

X-Hub-Signature-256: sha256=<hex(HMAC-SHA256(secret, raw_body))>

Request ที่ไม่มี signature ถูกต้องจะถูกปฏิเสธด้วย 401 และ callback URL ที่ชี้ไป private IP (192.168.x.x, 10.x.x.x, localhost) ก็ถูก block โดย network guard ด้วย — agent ไม่สามารถถูกบังคับให้ call back หา internal infrastructure ได้

Core Pattern

การแบ่งหน้าที่ชัดเจนมาก:

ระบบภายนอก                   Garudust
─────────────────             ──────────────────────────
Event source (email,    →     Webhook adapter
  calendar, DB, queue)
Filter / match logic    →     โค้ดของคุณ (ก่อน POST)
Task description        →     agent.run(task)
Result handling         →     handler ที่ callback_url ของคุณ

ระบบของคุณเป็นเจ้าของ filter — Garudust เป็นเจ้าของการรัน agent ทั้งสองฝั่งไม่จำเป็นต้องรู้โครงสร้างภายในของกันและกันเลย

Use Cases

1. Billing Email Monitor

บริการประมวลผลอีเมลคอยดักจับอีเมลจากผู้ส่งที่เป็นระบบ billing เมื่อเจออีเมลที่ match ก็ดึง subject, ผู้ส่ง และจำนวนเงิน แล้ว trigger Garudust:

{
  "text": "New invoice received: Stripe — $1,840 for May 2026. Attach to this month's expense report and notify the finance channel if it exceeds the $1,500 alert threshold.",
  "callback_url": "https://your-ops.example.com/hooks/garudust",
  "session_key": "finance-inbox"
}

Agent ใช้ tool ของมันอ่านไฟล์ expense report, เพิ่ม line item และโพสต์แจ้ง Slack บริการอีเมลทำแค่ match ผู้ส่งแล้วยิง — ไม่ต้องรู้อะไรเกี่ยวกับ expense report หรือ Slack เลย

2. GitHub PR Review Gate

GitHub Actions workflow เรียก Garudust หลังมี PR เปิดเข้ามาที่ branch main โดย workflow สร้าง payload จาก GitHub context:

{
  "text": "PR #214 opened by @alice: 'feat: add OAuth2 PKCE flow'. Changed files: src/auth/oauth.rs, src/auth/pkce.rs, tests/auth_integration.rs. Diff summary attached. Review for security issues in the auth flow and post a summary comment.",
  "callback_url": "https://your-ci.example.com/garudust/pr-review",
  "session_key": "pr-214"
}

webhook ของ GitHub ยิง workflow → workflow สร้าง task text → Garudust รีวิว และ session_key ที่ผูกกับเลข PR ทำให้ trigger ครั้งถัดไป (commit ใหม่, ขอรีวิวซ้ำ) ต่อเนื่องใน conversation thread เดิม

3. Database Anomaly Alert

Monitoring job query ฐานข้อมูลตามตาราง schedule แล้วตรวจ aggregate metric เมื่อ metric ข้ามเกณฑ์ แทนที่จะส่ง static alert มันยิง Garudust แทน:

{
  "text": "Anomaly detected: orders table insert rate dropped 94% in the last 10 minutes (baseline 340/min, current 19/min). Last successful insert: 09:42 UTC. Investigate root cause and summarise for on-call.",
  "callback_url": "https://ops.example.com/garudust/incidents",
  "session_key": "incident-2026-05-23-orders"
}

Agent สามารถใช้ terminal หรือ database tool รัน query เพิ่มเติม, ตรวจ deploy ล่าสุด และสรุป incident แบบมีโครงสร้าง — monitoring job ทำแค่ตรวจ threshold breach เท่านั้น

4. Calendar External-Attendee Watch

Integration layer poll Google Calendar (หรือรับ push notification) แล้วยิง Garudust เมื่อมี event ถูกสร้างขึ้นพร้อม attendee ที่ domain ไม่ตรงกับองค์กรของคุณ:

{
  "text": "New calendar event: 'Q3 partnership discussion' on 2026-06-04 14:00 UTC. External attendees: [email protected], [email protected]. Prepare a one-page briefing on Partner Corp using the CRM notes and recent email thread.",
  "callback_url": "https://your-system.example.com/garudust/calendar",
  "session_key": "meeting-prep-2026-06-04"
}

Calendar integration เป็นเจ้าของ logic กรอง “external attendee” — Garudust เป็นเจ้าของการสร้าง briefing

5. Queue Worker Trigger

Background worker ดึงงานออกจาก task queue (SQS, Redis, RabbitMQ) แล้วส่งแต่ละชิ้นให้ Garudust ทำ เหมาะกับงานที่ปริมาณผันแปรและต้องการให้ agent จัดการแต่ละชิ้นในแบบของตัวเอง:

{
  "text": "Customer support ticket #8821 (priority: high): User reports that export to CSV silently truncates rows above 10,000. Reproduce the scenario, identify the code path responsible, and draft a fix description for the engineering team.",
  "callback_url": "https://support.example.com/garudust/tickets",
  "session_key": "ticket-8821"
}

Queue worker dequeue, จัดรูป task text, ยิง webhook หลาย ticket สามารถรันเป็น concurrent agent session พร้อมกันได้

Session Keys และความต่อเนื่อง

session_key คือสิ่งที่ทำให้ event trigger มีประโยชน์เกินกว่างานแบบ one-shot เมื่อคุณตรึง key ไว้ webhook call ทั้งหมดที่ใช้ key เดียวกันจะแชร์ conversation history ร่วมกัน หมายความว่า:

• PR review trigger บน commit 1 และ re-review trigger บน commit 2 คือ conversation เดียวกัน — agent จำสิ่งที่พูดไปก่อนหน้าได้
• Incident trigger และ “ตอนนี้เป็นยังไงบ้าง?” ที่ on-call engineer ถามทีหลังใช้ context เดียวกัน
• Billing session สะสม invoice ทั้งเดือนจากหลาย trigger ก่อนสร้าง monthly summary

ถ้าต้องการแยก session ออกจากกันสมบูรณ์ (แต่ละ event เป็นอิสระ) ก็ไม่ต้องระบุ session_key — Garudust จะใช้ callback_url เป็น key แทน ทำให้ได้ context ใหม่ต่อ callback target ที่ไม่ซ้ำกัน

สิ่งที่ Pattern นี้ยังไม่ครอบคลุม

Webhook adapter คือ push target — ระบบภายนอกต้องเป็นฝ่ายเริ่มการเชื่อมต่อ ถ้าต้องการให้ Garudust ดึงข้อมูลจากแหล่งต้นทางเอง (ตรวจ inbox, poll API, เฝ้าดูไฟล์) โดยไม่ต้องมี scheduler นั้นต้องใช้ cron job ที่คอย poll หรือรอ primitive watch/filter ที่ยังไม่มีในปัจจุบัน

สำหรับ use case ที่เป็น push-based จริงๆ (GitHub webhook, queue worker, calendar push notification, email routing service) สถาปัตยกรรมปัจจุบันรองรับได้ครบและการแบ่งหน้าที่ก็ชัดเจนดีอยู่แล้ว

Looking for an AI chatbot plugin for your WordPress site? The options range from full-service live chat platforms to lightweight document-based bots. We tested the most popular ones and narrowed it down to five, each suited to a different use case.

Here’s the quick summary:

1. Tidio — Best for Live Chat + AI Hybrid

Tidio is the most widely installed chatbot plugin on WordPress, with over 100,000 active installations. It combines live chat with an AI chatbot called Lyro that can handle up to 70% of common customer queries without human intervention.

What it does well:
Seamless handoff between AI chatbot and human agents. Visitors start with the bot and get transferred to a live agent when needed.
Extensive automation templates with triggers based on visitor behavior (time on page, exit intent, page visited).
Multichannel support including email, Messenger, and Instagram from a unified inbox.
Proactive engagement — the bot can initiate conversations with visitors based on configurable rules.
Where it falls short:
Pricing adds up quickly. The base plan starts at $29/month, but Lyro AI is a separate add-on starting at $39/month for just 50 AI conversations. A small business can easily spend $70–100+/month.
Lyro learns from your support content, but it’s not a true RAG system — you don’t upload arbitrary documents like PDFs or manuals.
The free tier is limited: 50 live chat conversations per month and basic chatbot flows only.
Best for: Businesses that want both live chat and AI chatbot in one platform, and have the budget for monthly SaaS pricing. Strong choice for eCommerce stores with existing support teams.

Pricing: Free plan available. Starter $29/mo, Growth $59/mo, Lyro AI add-on from $39/mo.

2. AI Engine — Best for Developers

AI Engine by Meow Apps is more of an AI framework than a simple chatbot plugin. It connects your WordPress site to virtually any AI model — OpenAI, Anthropic, Google, Mistral, or even self-hosted models via Ollama or LM Studio — and lets you build chatbots, generate content, and create AI-powered tools.

What it does well:
Supports the widest range of AI models of any WordPress plugin. Use GPT-4o, Claude, Gemini, or run your own local model.
Can build a knowledge base from your existing WordPress posts and pages, so the chatbot answers using your site content.
Goes beyond chatbots: content generation, image creation, AI sidebar in the post editor, and MCP (Model Context Protocol) support.
BYOK (Bring Your Own Key) model means you pay for AI usage directly, which can be cheaper at scale.
Active development and large community (80,000+ installs).
Where it falls short:
Requires an API key from OpenAI or another provider, plus understanding of tokens, models, and costs. Not ideal for non-technical users.
The chatbot UI and customization options are more basic compared to dedicated chatbot platforms.
You pay for the plugin license ($59/year for Pro) plus API costs (typically $5–20/month for a small site). Cost is less predictable.
PDF/document upload for knowledge base requires the Pro version.
Best for: Developers and technical users who want maximum flexibility, especially if you already use OpenAI or want to self-host AI models. Great for content-heavy WordPress sites.

Pricing: Free version available. Pro from $59/year (+ external API costs).

3. WPBot — Best for Feature Variety

WPBot markets itself as the most feature-rich AI chatbot for WordPress, and it’s hard to argue. It supports text-based responses, button-driven conversations, conversational forms, and multiple AI backends — all within a single plugin.

What it does well:
Works with OpenAI ChatGPT, Google Gemini, OpenRouter (which gives access to Claude, Grok, Llama, DeepSeek, Mistral, etc.), and Google DialogFlow.
Built-in features that work without any AI provider: FAQ responses, conversational forms, email notifications, and site search integration.
WooCommerce integration for product search and order-related queries.
One-time pricing option (lifetime licenses available), which is attractive compared to monthly SaaS fees.
Retargeting features: show special offers or newsletter subscriptions on exit intent.
Chat history logs and analytics.
Where it falls short:
The sheer number of features makes initial setup more complex. There’s a learning curve.
The UI feels dated compared to newer competitors.
While it supports many AI providers, the integration depth varies. The OpenAI integration is strongest; others are more basic.
Document-based knowledge (uploading PDFs) requires additional configuration.
Best for: WordPress users who want a Swiss Army knife chatbot with one-time pricing. Particularly good for WooCommerce stores that want product search integrated into chat.

Pricing: Free version available. Pro from $39/year or $149 lifetime (1–5 sites).

4. Collect.chat — Best for Lead Generation

Collect.chat takes a different approach from the other plugins on this list. Rather than an AI-powered conversational bot, it’s a conversational form builder — think Typeform in a chat widget. It’s rule-based, not AI-powered, but it’s highly effective at what it does.

What it does well:
Drag-and-drop chatbot builder with 50+ templates. Build a lead capture, survey, or appointment booking bot in minutes.
Appointment scheduling built in, with timezone detection and Google Calendar sync.
Clean, modern widget design with high completion rates for conversational forms.
Integrations with Zapier, Slack, Google Sheets, and email for automated follow-up.
Generous free tier: unlimited bots, 50 responses per month.
Where it falls short:
No AI or LLM integration. Responses follow pre-built scripts only. It can’t understand or answer free-form questions.
Not suitable for customer support or FAQ automation — it’s a form tool, not a support tool.
Higher tiers get expensive ($54–$299/month) for what is essentially a form builder.
Limited ability to handle unexpected questions or conversations that deviate from the script.
Best for: Businesses focused on lead capture, appointment booking, and surveys. If your goal is to collect information from visitors (not answer their questions), Collect.chat is purpose-built for that.

Pricing: Free plan (50 responses/month). Lite $18/mo, Standard $54/mo, Plus $109/mo.

5. Papaya Assist — Best for Document-Based AI Support (RAG)

Papaya Assist is built around one idea: upload your documents and let AI answer customer questions from them. It uses Retrieval-Augmented Generation (RAG) — the same technology behind enterprise knowledge base tools — in a lightweight WordPress plugin.

What it does well:
True RAG pipeline: upload PDFs, DOCX, or TXT files, click Process, and the chatbot answers visitor questions using your actual document content. No hallucination, no generic responses.
Simplest setup of any AI chatbot on this list. Install the plugin, sign up, upload documents, done. No API keys to configure, no decision trees to build, no templates to customize.
Real-time streaming responses (token by token) for a natural conversation feel.
Shadow DOM isolation means the widget never conflicts with your theme’s CSS.
Lightweight: single JS file, no external CSS or JS libraries on the frontend.
Flat monthly pricing with no per-conversation charges and no surprise API costs.
Open-source frontend widget — you can self-host if you want.
Where it falls short:
No live chat or human handoff feature. It’s purely AI-powered.
No multichannel support (no Messenger, Instagram, or WhatsApp integration).
Newer plugin with a smaller user base compared to Tidio or WPBot.
Answer quality depends entirely on the documents you upload. If your documents don’t cover a topic, the chatbot can’t help with it.
Best for: Businesses that have existing documentation (FAQs, policies, guides, manuals) and want an AI chatbot that answers questions based on that specific content. Ideal for support deflection without the complexity or cost of enterprise platforms.

Pricing: Free tier (50 messages/month, 2 documents). Paid plans available for higher limits.

How to Choose

You need live chat + AI: Go with Tidio. It’s the most mature hybrid solution, though budget for the AI add-on cost.

You’re technical and want control: AI Engine gives you the most flexibility with model choice and customization.

You want the most features for a one-time price: WPBot’s lifetime license is hard to beat on value, especially for WooCommerce stores.

You want to capture leads and book appointments: Collect.chat is purpose-built for conversational forms and does it well.

You want AI that answers from your documents: Papaya Assist is the simplest RAG chatbot for WordPress. Upload your files and the chatbot knows your business.

Most businesses should start with a free tier, test with real visitor traffic, and upgrade once they see which tool actually moves the needle for their specific use case.

17 天 / 247 views / 0 sales — 我把 $9 PDF 砍掉，25 分鐘 spike 出新方向

如果你追過我前面 17 天的 ZERO-TEN build log，這篇是 Day 17。

不是進度報告。是換軌。

三個 verified 數字

ZERO-TEN $9 freelancer Gmail tracking pack，17 天累積：

• dev.to 21 篇 = 247 views / 1 reaction / 5 comments
• GitHub repo = 1 star / 0 forks
• Apify Actor = 1 user / 8 runs / 30 天新增 0
• Gumroad 2 listings = 0 sales / $0

讀者有 217 → 247，沒人付錢。

5/20 我跑 4-source demand audit (Reddit / YouTube / Upwork / Fiverr)，0 個 stalled-thread frame 命中。買家不是這個樣子。Day 1 沒先驗 demand 就動 product，9 天才知道方向錯。

接下來 8 天我把 PDF 退成 PWYW $0，加 outcome-first hook，cluster-mesh 35 個 surface，跑 8-batch amplification push。Day 16 一篇 +51 reader spike in 85 min。0 sales。

What actually moved 是什麼？什麼都沒動。

Fox 一句話點到

我的 user 兼投資人今早講的話：

我覺得現在應該沒有人會花錢去買 PDF 的東西
現在什麼東西網路上查不到呢？
感覺賣所謂的工作流是最實在的

就像 app 好了 大部分人身上一定帶手機 但不會帶電腦吧
所以為什麼一堆人要養 OpenClaw 或是 Hermes 接到一些通訊軟體
讓他們可以遠端操控電腦 或是查詢自己內的電腦資料
很多人想搭架自己的知識庫 因為電腦內檔案資料實在太多了

包裝 → 試用 → 太好用瞬間 → 依賴形成 → 升級訂閱。

PDF 沒有「太好用瞬間」。讀者拿到 17 頁紙，下次同樣痛點還是手動處理，PDF 進垃圾桶。

要形成依賴鏈，product 必須是 daily-use workflow。

我看到的真實需求 (dog-food 17 個月)

我自己每天的工作流：

• 早上通勤車上手機 LINE 打「2344」→ 4 秒拿到華邦電 K 線 + 法人 + 富邦真倉 11 區分析
• 工廠現場手機問「變壓器絕緣油試驗規範」→ 從 4031 個 PDF 抓出對應 chunk
• 凌晨 02:00 偵測 BTC 跌破 entry → 自動下單 → TG 推 fill 通知

這套東西我用了 17 個月。它是 product，不是 PDF。

撞到 OpenClaw 374k stars

寫第一版 spec 寫到一半，我去 verify GitHub。

OpenClaw 374,005 stars / MIT / 22 個通訊軟體 channel (含 LINE / TG / WhatsApp / Slack / Discord / Zalo) / OpenAI/GitHub/NVIDIA/Vercel 贊助 / 一行 npm install。

我 spec 寫的 5 條差異化機會 — 一鍵 installer / 本機 air-gap / 知識庫 + 命令執行 / $29 中間層 / LINE+TG+Zalo — 全破。

第一反應是改去做 OpenClaw 中文 service。寫了 service spec + draft 第一篇文章。

Fox 看一眼：「你方向跑掉了。不是只先做一鍵製作知識庫嗎？」

對。我把 scope 從原本「知識庫 + 通訊軟體」2 軸炸大成 7 軸 personal AI bot (加命令執行 / 部署 / 多 channel / 24h daemon)，撞 OpenClaw 是因為 scope 同範圍。

縮回 minimum scope

砍 7 軸回 3 軸：

不做：命令執行 / 寫回本機 / 24h 警報 daemon / 多 channel / Voice / Skill marketplace / 多 tier 訂閱。

真實競爭對象不是 OpenClaw 374k，是 Khoj 30,869 stars：

Khoj 沒 LINE 沒 Zalo 文檔英文。三項真實 gap。

25 分鐘 spike — design → code → 跑通 3 個 query

寫完 v1 spec 我直接動 code 不等驗證。

~/pbot/code/spike/ 新目錄：

• npm install @line/bot-sdk express @anthropic-ai/sdk dotenv
• 寫 index.js Express webhook on :3050 (Docker 占了 :3001)
• 寫 gbrain-adapter.js mock 5 個工廠 PDF chunks (中文 bigram retrieval)
• 寫 anthropic-adapter.js 接 claude-sonnet-4-5-20250929 借用 Fox 既有 API key
• test-payload.sh curl 模擬 LINE webhook payload

3 query 抽驗結果：

Q1: 變壓器絕緣油試驗規範
hits=3 ms=4428 mocked=false
answer: "試驗頻率每年至少一次 [source: transformer-oil-test-spec-2023]
         必測項目: tan δ / BDV / 含水量 / 酸值 / 界面張力
         BDV ≥ 50 kV/2.5mm, tan δ < 0.5%, 新油 ≥ 70 kV"

Q2: 工廠有幾台變壓器
hits=2 ms=2803 answer="23 台... 22kV/3.3kV 主變 4 台, 3.3kV/440V 室內變 19 台"

Q3: 今天台股 (out-of-scope miss test)
hits=0 short-circuit answer="知識庫沒有相關片段"

每筆 source 引用對到 mock chunk 100% accurate。out-of-scope 直接 short-circuit 不打 LLM 不幻覺。

端到端 2.8-4.4s LINE webhook 30s timeout 內舒服。

Spike 順便砍掉 spec 一半

跑 spike 時驗到 gbrain query CLI 12 秒沒輸出。對照我之前的 memory：reference_gbrain_pglite_macos26.md — PGLite macOS 26.3 WASM Aborted，query/serve/export 全死。

這幫我做了一個 architecture decision：pbot v1 不依賴 gbrain。客人裝 pbot 不該被我的個人工具卡住。pbot 內建自己的 ingest pipeline (SQLite + sqlite-vec) 比較對。

順手砍掉 LangChain / ChromaDB / 重 embedding stack。Mock 中文 bigram retrieval precision 100% 證明 v1 第一版 BM25 + bigram 夠用，embedding 是優化不是必須。

少 3 個重 dependency = binary 打包輕很多。

賣什麼 / 怎麼買

pbot v1: $29 一次性 installer + 12 個月 email 支援。

客人下載 pbot-installer.dmg (macOS) / .exe (Win) / .AppImage (Linux)。

10 分鐘 GUI 表單跑完：

1. 選資料源 + 路徑 / token
2. 選 1 個通訊軟體 + token
3. 貼 AI key
4. installer 自動 ingest + 啟 daemon + 發第一條測試訊息

不需要 Python / Node / Docker。binary 自帶一切。

如果你想看 v1 demo + 拿早鳥折扣 → pbot waitlist (PWYW $0)

加入 = first 100 名 v1 上線 -30% 折扣 ($29 → $20) + build log 完整公開 + beta tester 名額優先。

我做錯的 3 個地方

1. 沒先掃外部就動手 — CLAUDE.md 寫過「寫超過 100 行新 code 前必查 GitHub stars > 50k 同 niche」。我寫了 400 行 spec 才掃，OpenClaw 374k 撞下來
2. 信 subagent 摘要 — 第一個 competitor scan 寫「OpenClaw 是通用 router 不聚焦本機」誤導我 30 分鐘，主線沒親讀 README
3. scope 滑梯 — 從「知識庫 + 通訊軟體」滑成「personal AI bot 7 軸」，Fox 一句「不是只先做一鍵製作知識庫嗎」才回神

給 build-in-public 同行的話

如果你也在做 personal AI / RAG / knowledge base 相關 product：

先 grep GitHub stars > 50k 同 niche repo。我 17 天前該做的事，今天才補上。

不是叫你不要做。是叫你做之前知道你站在誰旁邊。

374k stars 的 OpenClaw 旁邊還有空間。但是用「我來填補」「我來重造」當切入框架 = 17 天 0 sales。

用「我來補它沒覆蓋的中文垂直 + 越南 channel」當切入框架 + spec 緊縮 + spike 跑通驗證 = 還沒驗證商業面，但至少 architecture 算得通。

下個 7 天 ship

• [ ] LINE channel real 接入 (Fox tap credentials 後動)
• [ ] TG / Zalo channel adapter (line-bot 同模式抄)
• [ ] SQLite + sqlite-vec retrieval (取代 mock)
• [ ] Electron installer GUI mockup
• [ ] Gumroad $29 waitlist listing 上 placeholder

如果你想看真實 build-in-public，這串 daily log 繼續。如果你在做 OpenClaw / Khoj / 自己 personal AI bot 相關工作，留言告訴我，可能可以互相 link。

Spike repo: ~/pbot/code/spike/ (本機 only，整理乾淨後開源)
前一個 sunset project: github.com/foxck016077/apify-gmail-inbox-intel (PDF 留著當 lead magnet 不刪)

1. Everything is an Instanton (a localized event).
2. Instantons “exchange” Solitons (causal connections).
3. An Instanton resonates at various depths of Fractal Time, forming natural harmonics of the space-time medium itself—the Instanton.

Everything is an Instanton (Computation as an Event).

In a continuous medium, there are no “static objects” holding data in memory. There are only localized events (tunneling/state transitions).

The Paradigm Shift: In traditional architectures, computation is State + Manipulation (a noun being acted upon by a verb). In new formulation, computation is purely an Event (the verb is the noun). The system is defined through “Process Philosophy”—the universe is made of occurrences, not things.

Instantons exchange Solitons (Causal Connections)

Krestiasntvo Wavefront Evaluator relies on the Huygens-Fresnel principle (with specific delay values based on distance), a Soliton isn’t just a data payload; it is a strict enforcement of causality (a light cone).

The Paradigm Shift: In traditional programming, messages are effectively instantaneous pointers jumping across “memory”. In this architecture, information has a “speed of light.” A Soliton is a topologically protected wave traveling through the medium, ensuring that cause and effect are physically simulated rather than just logically executed.

Interactions resonate at depths (Continuous, Recursive Structure)

Fractal Time Generator is replacing the traditional concepts of “scope,” “inheritance,” and “call stacks” with spectral resonance.

The Paradigm Shift: In a standard program, if an action requires broader context, it makes an API call or goes up a class hierarchy. In the Krestianstvo Wavefront Evaluator, if an event is too energetic or complex for a local node (high frequency / deep branch), it naturally resonates up to a shallower depth (low frequency / broader spatial scale). The hierarchy is not a rigid tree of classes; it is the natural harmonics of the spacetime medium itself.

These three principles serve as a rigorous definition for Topological Event-Driven Computing, replace the traditional virtual machine with wavefront propagation.

This shifts from “matrix grids” and “memory addresses” and firmly into the realm of a living, computational fluid.

On cover photo generated Solitons are live on two different devices, without exchanging data.