Who should hear the TiDB/sys9 pitch first?

The TiDB/sys9 pitch should not start as "we have a better database." The stronger version is: agent products are creating millions of small, durable, branchable states, and most stacks still treat those states as either app sandboxes or database rows, not one operating surface.

The outreach order:

Start with warm AI app references and agent app builders, then coding-agent platforms, then support/work-AI enterprises. Use TiDB for the live data and memory sale. Use sys9 for the forkable agent-runtime sale.

I turned the research into a public lab: TiDB/sys9 Prospect Radar. The lab ranks 20 prospects from public sources with a replayable Python script: python3 scripts/tidb-sys9-prospect-radar.py --write.

The correction: TiDB and sys9 are not the same pitch

TiDB is the database argument. PingCAP's AI pages frame TiDB around live data, transactional consistency, analytics, vector search, full-text search, hybrid search, and stateful agents. The agent-memory article is more concrete: keep text, vectors, metadata, and tenant state together instead of forcing agent memory into a fragile pile of stores.

TiDB X is the scale inversion argument. PingCAP's SCAILE Europe writeup describes a world of many tiny isolated databases, object-storage-backed durability, and compute that can scale down when the isolated state is idle. That matters when every agent branch, app preview, tenant, and workflow wants its own state.

sys9 is the agent-native stack. Its public surface names run9 for forkable sandboxes, smith9 for agent runtime, db9 for serverless Postgres, drive9 for shared files, mem9 for memory, task9 for queues, inbox9 and pulse9 for realtime, tape9 for logs, chord9 for teamwork, and owl9 for observability. That is not just storage. It is an operating substrate for agents.

What the combined pitch actually says

The combined story is a stateful agent substrate. TiDB handles durable live data, hybrid retrieval, transactional correctness, and multi-tenant scale. TiDB X makes the isolated database model plausible at agent-app volume. sys9 wraps the runtime side: fork the workspace, run the agent, persist state, queue work, observe the trace, and replay the branch.

That is why the best prospects are not "any company using AI." The best prospects are companies where many agents, many tenants, many generated apps, or many support conversations create a state explosion.

The paying customer and use-case lanes

Warm TiDB expansion: Dify and Atlassian are already public PingCAP stories. Dify is the cleanest AI-app proof because it reportedly consolidated massive database-container sprawl. Atlassian is the enterprise multi-tenant proof because Forge faced connection, metadata, and tenant isolation pressure at millions-of-table scale.
Existing AI app references: PingCAP's TiDB X/sys9 article names Kimi and Plaud as customer-experience anchors for AI-native workloads. They are high-value reference candidates before cold outbound.
Agent app builders: Lovable, Replit, v0, Bolt, Base44, and similar products create app branches, preview databases, auth state, files, and deployment handoffs. They should hear the sys9 runtime pitch first.
Coding-agent platforms: Cursor, Devin, Factory, and Amp need isolated workspaces, job state, logs, queues, memory, and rollback. They should hear sys9 as the agent OS layer before TiDB as the database layer.
Support and enterprise work AI: Sierra, Decagon, Intercom, Ada, Glean, Dust, and Harvey need live customer or enterprise memory, governed retrieval, tenant isolation, audit, and workflow state. They should hear the TiDB memory/live-state pitch first.

The first outreach stack rank

The lab scores each prospect on agent-runtime pressure, tenant database pressure, live-data memory need, SQL/vector fit, budget, partnership leverage, competitive gap, and warm path. The first run puts the outreach order here:

Moonshot AI / Kimi: use the warm AI-app reference angle and ask for a TiDB X agent-state architecture conversation.
Dify: expand the published TiDB consolidation story into branchable agent state for every app and tenant.
Lovable: lead with sys9 as the forkable generated-app runtime and hold TiDB as the durable state layer.
Replit: pitch every parallel agent branch as an isolated SQL-backed workspace with replayable state diffs.
Atlassian Forge: convert the multi-tenant TiDB proof into a TiDB X expansion story for app and agent lifecycles.
Decagon: lead with TiDB as live support memory across customer history, tool traces, and hybrid retrieval.
Cursor / Anysphere: lead with sys9 runtime primitives for remote coding-agent workspaces, queues, logs, and memory.
Sierra: benchmark cross-channel memory for chat, SMS, WhatsApp, email, voice, and ChatGPT handoffs.
Glean: pitch governed enterprise agent memory with live SQL facts plus vector/full-text retrieval.
Vercel v0: pitch app-generation database branches, preview data, and MCP-safe database inspection.

Three outreach scripts

AI startup / sys9 opener

Your agents are creating branches of apps, files, tool calls, and database state. sys9 makes that an operating substrate: forkable run9 workspaces, db9/TiDB-backed durable state, mem9 memory, task queues, and observable replay. Give us one branch-heavy workflow and we will model fork time, state isolation, memory, and replay as a packet.

Enterprise database / TiDB opener

Your AI agents need live customer or tenant state, not a split between transactional data, vector memory, and analytics. TiDB keeps rows, vectors, full text, metadata, and operational truth in one distributed SQL substrate. Give us one high-volume tenant or support workflow and we will show the SQL/vector/live-state model.

Warm reference expansion

You already have the customer story. The next story is agent state: millions of tiny isolated environments, branchable memory, and durable state without multiplying the ops surface. Co-author a narrow architecture note: existing TiDB proof first, then the TiDB X/sys9 extension.

Falsifiers before outreach

A prospect should drop in priority if the runtime/database substrate is already core IP, if the product is mostly prompt UX without many tenants or branches, or if there is no path to a technical benchmark. The worst version of this sale is a generic database replacement pitch. The useful version starts with the state explosion the buyer can already feel.