sales-skills/sales-atypica

atypica.AI Platform Help

atypica.AI (atypica.ai) is an AI research-agent platform that simulates consumers. You build AI Personas on a four-layer "subjective world model" (Expression → Story → Cognition → Behavior), run AI-moderated interviews and studies against them, and get an insights report in minutes — a synthetic-research alternative to a traditional agency or focus group. Its cluster edge is that persona construction and a flywheel (validate synthetic personas against real interviews) aim beyond plain LLM roleplay, plus ~10K interview-grounded "real-person" agents alongside the 300K synthetic ones.

Its signal is directional, not demand: personas model existing/social/ interview/training data, so they skew agreeable, generic, and Western-biased and can be confidently wrong. Treat any synthetic result as a hypothesis to disconfirm with real behavior, never a green light.

Step 1 — Gather context

If references/learnings.md exists, read it first for accumulated platform knowledge.

Ask only what you can't infer:

1. What do you want from atypica?
   • A) Build a persona / run a study — set up an AI Persona or an AI Interview / study, and read the insights report
   • B) Embed atypica in your own app (mint an impersonation login URL so a user lands in a study with no separate login)
   • C) Provision team access via the API (list / create / invite members)
   • D) Interpret a study/report you already ran, or decide whether to trust it
2. What's the research question and who's the audience? A sharp objective + a well-defined persona yields usable answers; a vague one yields generic filler.

Skip-ahead: if the user wants to compare synthetic-research/persona/idea tools across the market, or the validate-before-building method, that's a /sales-idea-validation question — route in Step 2.

Step 2 — Route or answer directly

| If the user's question is about… | Route to | |---|---| | Comparing synthetic-research/persona/idea tools, or the validate-before-building method | /sales-idea-validation {question} | | Running a real demand test (smoke-test page, waitlist, pre-sale) after synthetic signal | /sales-idea-validation or /sales-funnel {question} | | Analyzing real-customer NPS/CSAT/VoC feedback (post-launch) | /sales-customer-feedback {question} | | A census-calibrated demographic panel with a free-tier API, or a documented studies REST API | /sales-ditto or /sales-syntheticusers {question} |

When routing, give the exact command: "This is a {domain} question — run: /sales-idea-validation {original question}"

Otherwise, answer atypica-specific questions using Step 3.

Step 3 — atypica platform reference

Read references/platform-guide.md for the full reference — the three capabilities + flywheel, the module → automation-surface table (what's API- accessible vs UI-only), best-effort token/enterprise pricing, the data model (JSON shapes for the team/embedding API), and quick-start recipes.

For raw endpoints, auth, JSON schemas, and error codes, read references/atypica-api-reference.md.

Answer using only the relevant section — don't dump the full reference.

Step 4 — Actionable guidance

• A synthetic "yes" is not demand — say so every time. Whatever the user asks, make explicit that atypica's personas model existing/interview/training data, so they run agreeable, generic, and Western-biased and can be confidently wrong. Frame every study result as a hypothesis to disconfirm with a real behavior test (smoke-test click, reply, pre-sale) — keep the objections, segments, and language it surfaces (its real value), take the go/no-go from real strangers, and route the real test to /sales-idea-validation.
• The public API is a team + embedding API, not a studies API — never invent study endpoints. There is no documented endpoint to create a persona or run a study over HTTP; studies run in the app UI. Base https://atypica.ai/api, auth Authorization: Bearer <team-scoped key>. The only endpoints are GET /team/members, POST /team/members/create, POST /team/members/invite, and POST /team/members/:userId/impersonation. If the user asks to "run a study via the API," correct the premise and offer the embedding path instead.
• To automate/embed a study, use the impersonation login URL. POST /team/members/:userId/impersonation with callbackUrl: "/newstudy" returns a loginUrl you redirect/iframe so the user lands authenticated on the new-study screen with no separate atypica login. Honor expiryHours (default ~24) — mint a fresh URL per session, don't cache. The user must be a team member first (create or invite). Pull the exact request/response from the references.
• Present the accuracy and flywheel claims as best-effort, cite the source. The 85% human-likeness, 100× cheaper, and validate-against-real-interviews flywheel are vendor-reported; the four-layer "subjective world model" is a real differentiator over pure-LLM roleplay but calibrates who the persona is, not whether real buyers act. Say figures are best-effort and point to atypica.ai.
• Present pricing as best-effort — it's token-metered. Freemium includes 1,000,000 free tokens; there's an enterprise SOC2 tier. The /pricing page is JS-rendered — confirm current tiers on the live site before relying on them.
• Sharpen the persona and objective — output tracks input. A vague audience or question yields generic filler; recommend a specific objective and (where useful) importing real interview transcripts to ground a private persona library before running the study.

If you discover a gotcha or tip not in references/learnings.md, append it there with today's date.

Gotchas

Best-effort from research (2026-07) — pricing (token counts), the accuracy claims, persona counts, and the API surface move; verify at atypica.ai and atypica.ai/docs/api.

• Sycophancy / agreeableness bias. Personas skew favorable — they can approve a concept or price real buyers would reject. Never read a positive synthetic reaction as validation.
• Simulated ≠ real behavior. The four-layer world model matches how a persona is described, not the messy choices of a real person — and it can't surface a genuinely new unmet need. The "expression-behavior gap" is a calibration signal, not a fix for it.
• Western/English and identity-flattening bias. Outputs skew Western/majority and can flatten segments — be cautious generalizing across markets or narrow niches.
• The API can't run studies. It's a team-provisioning + embedding API only. Don't promise "run a study via the API" — automate by embedding via an impersonation login URL; studies execute in the UI.
• Impersonation URLs expire and are identity-scoped. They honor expiryHours (default ~24) and require a real team member (403 if the email domain isn't whitelisted for create). Mint per session; use invite for users on other domains.
• Vendor accuracy figures. "85% human-like", "100× cheaper", the flywheel validation — all vendor-reported. Cite them as claims, not proof.

Related skills

• /sales-idea-validation — The tool-agnostic validate-before-building method + the full synthetic-research/persona/validator tool landscape (use this to actually decide build-or-not; a synthetic "yes" is not demand)
• /sales-syntheticusers — Synthetic Users platform help (the pure-play interview-study peer with a documented public REST studies API [Python/TS SDKs, SSE streaming]; atypica's API is team/embedding-only)
• /sales-ditto — Ditto platform help (census-calibrated demographic panels with a free-tier studies API + official Claude Code skills; atypica has richer persona construction but no studies API)
• /sales-imario — iMario platform help (the reusable-persona canvas — a Synthetic Individual with cross-session memory across six jobs; atypica's flywheel validates personas against real interviews)
• /sales-societies — Artificial Societies platform help (the self-serve network simulator that predicts how a post/message spreads; atypica asks isolated personas, Societies models influence between them)
• /sales-customer-feedback — Real-customer NPS/CSAT/VoC strategy across tools (use once you have live customers; synthetic research is pre-launch only)
• /sales-funnel — Build the smoke-test / fake-door landing page that turns a synthetic hypothesis into a real demand test
• /sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do -a claude-code

Examples

Example 1: "atypica's synthetic consumers loved my concept — should I build?"

User says: "My atypica study says 85% human-like and the personas loved the idea. Green light?" Skill does: Explains atypica's personas model existing/interview/training data and skew agreeable, so an enthusiastic reaction is a directional signal, not demand, and flags the 85% figure as a vendor claim (calibration, not validity). Tells the user to mine the report for objections and language (the real value) and take the go/no-go from a real behavior test — a smoke test or pre-sale — routed via /sales-idea-validation. Result: The founder keeps the objections, runs a real pre-sale before committing.

Example 2: "Run a persona and a study from my script via the API" (developer/automation)

User says: "How do I use the atypica API to create a persona and run a research study programmatically?" Skill does: Corrects the premise — the public API is a team-provisioning + embedding API, with no endpoint to create a persona or run a study; studies run in the UI. Gives base https://atypica.ai/api + Bearer team key, and offers the real path: embed atypica via POST /team/members/:userId/impersonation (callbackUrl:"/newstudy") so the user lands in a study in your app. Points to references/atypica-api-reference.md; refuses to invent study endpoints. Result: The user embeds a study flow instead of chasing a nonexistent studies API.

Example 3: Embed a study in my product with no separate login (references/platform-guide.md)

User says: "I want users of my app to run an atypica study without logging into atypica separately." Skill does: Points to the impersonation login endpoint — provision/invite the user as a team member, then POST /team/members/{userId}/impersonation with expiryHours + callbackUrl:"/newstudy" returns a loginUrl to redirect or iframe; the user arrives authenticated on the new-study screen. Notes the token expires (default ~24h, mint per session) and a 403 means the domain isn't whitelisted (use invite). Pulls the Python snippet from the platform guide. Result: The user ships an embedded, no-extra-login atypica study flow.

Troubleshooting

"The personas agreed with everything — is that real signal?"

Symptom: Study answers are uniformly positive and agreeable. Cause: LLM-based personas exhibit sycophancy and model plausible agreement — the four-layer world model fixes who they are, not the agreeableness bias. Solution: Discard the "verdict," keep the objections and language surfaced, and validate with real behavior (smoke test, pre-sale). Sharpen the objective and persona (ground it in real interview transcripts) to cut generic agreement. Cross-check via /sales-idea-validation.

"I can't find the API endpoint to launch a study"

Symptom: The docs only show /team/members* — no way to create a persona or run a study. Cause: The public API is a team-provisioning + embedding API; studies are a UI operation, not an HTTP endpoint. Solution: Run studies in the app, or embed the flow with an impersonation login URL (POST /team/members/:userId/impersonation, callbackUrl:"/newstudy"). Don't invent study endpoints. See references/atypica-api-reference.md.

"My create-member call returns 403 / the impersonation URL stopped working"

Symptom: POST /team/members/create returns 403, or a saved loginUrl no longer authenticates. Cause: 403 = the email domain isn't whitelisted for the team; a dead login URL = the impersonation token expired (expiryHours, default ~24). Solution: For users on an unverified domain use POST /team/members/invite (existing registered users) instead of create; mint a fresh impersonation URL per session rather than caching it. See references/atypica-api-reference.md.