The first artifact from a Salesforce org took weeks of admin setup. Kriyo paints it in the first call.

The incumbent sells a data-management layer on top of Salesforce — a wrapper over the org’s own objects that streamlines jobs Salesforce technically supports but makes cumbersome: document merge against Contact and Account records, mass personalized email, bulk edit, dedupe. Its users are institutional organizations — nonprofits running campaigns over hundreds of thousands of Contacts — and the tooling predates the AI era by a decade.

The product is powerful and correspondingly deep. Operating it takes an explainer YouTube series, and in practice a Salesforce admin or solutions engineer in the loop for even small changes: a new report type, a new field mapping, a new team’s view. Salesforce lets you drill down feasibly; drilling up — a custom cross-object cut of your own org data — means someone builds Reports & Dashboards for you.

Archetypes are illustrative composites of the team roles the insider described (pre-sales, strategy/product, compliance) — not interviewed individuals. No quotes here are verbatim.

Before a prospect sees anything real, someone has to stand the product up in their org: connected-app auth, permission sets, field-level security, object mappings — work that lands on a Salesforce admin and was reported to take one to two weeks. Only then does the first usable artifact exist. Salespeople can’t show value on the first call, so evaluation stalls exactly where intent is highest.

The same tax recurs after the sale. Strategy, product, and compliance each need their own view of the org, and each view is another configuration project. The insider described the company converting users slowly and churning them quickly — while leaning on institutional clients for top line and trying to backfill with volumes of smaller ones. Churn has many causes I can’t claim to own; the first-touch-point delay is the one this product is aimed at.

Setup duration and churn pressure: as reported by the insider about their company; directional, not measured by me.

Kriyo inverts the interaction. Instead of chat describing data, the chat renders it: a prompt like “show me open pipeline by stage” is classified for intent, grounded in the org’s actual schema, compiled to SOQL, executed, and streamed back as a working dashboard — generative UI, not generated prose.

The rendering is deterministic by construction. The model can’t emit arbitrary HTML; it composes only components registered in a Zod-typed catalog (createCatalog — Card, Grid, Metric, Chart, Table, …) and binds them to data through JSON Pointer paths (/stats/amountSum, /charts/byStageName_Amount_sum). The catalog is the guardrail; the same registry renders every dashboard, so output quality doesn’t drift with the model’s mood.

Because each conversation persists its dashboard snapshot, every chat is a per-team interface: pre-sales bookmarks their pipeline view, compliance bookmarks theirs — customized by typing intent, not by filing an admin ticket. Filters and actions (apply_filter, export_report) are part of the catalog, so the artifacts stay interactive, not static charts. You can watch three of these conversations replay end-to-end in the live demo.

The dashboard below is mounted by this page using the same DataProvider → Renderer stack and componentRegistry as the chat route. Its /stats and /charts bindings were computed by the production DataAnalyzer over the snapshot — the only difference from a live session is that the Salesforce round-trip is canned.

The end-to-end MVP — pipeline, streaming UI, chat routes — was built over one weekend, roughly six months before this page (repo inception Jan 16, 2026).

A Salesforce org is not an open database. Each person who logs in sees a different slice of it, shaped by their profile, permission sets, sharing rules, and field-level security. So the pipeline builds every query against what the current user can actually reach. When they lack access to an object or field the dashboard needs, the answer is not a blank chart. It is a card that names the missing object, field, and permission, so they know exactly what to ask their admin for.

When a query fails, the system reads why before deciding what to do. Every Salesforce error gets matched against a nine-class taxonomy in lib/salesforce/error-taxonomy.ts. A misspelled field and a governor-limit timeout are different problems, so they get different fixes: regenerate with the right field names, shrink the query, back off, or stop. Each class carries its own correction note into the next prompt, and the whole loop is capped at three tries against the org.

Here is exactly what retries, why, and how far:

Scaling this to real enterprise load leans on patterns that predate AI: cache-aside for metadata, token-bucket rate limiting tied to the org’s API budget, circuit breakers and bulkheads per tenant, and retrieval to keep generation grounded.

The labels mean what they say. Implemented is in the repo now: the error taxonomy, tiered retries, parser pre-flight, schema cache, and few-shot store. Designed is the hardening plan, built on ordinary system-design practice: OAuth 2.0, cache-aside, token bucket, circuit breaker, bulkhead, and RAG-style retrieval.

No outcomes are claimed here — this is the instrumentation plan. Baselines are the reported status quo; targets are what the design is built to hit.

GTM is a hypothesis attached to a proposed solution — a wedge argued from the reported problem, not a motion that has been run. The call-1 experience itself is reproducible right now in the demo.