atypica.AI (atypica.ai) platform help — an AI research-agent platform that simulates consumers: build AI Personas from a four-layer "subjective world model", run AI-moderated Deep Interviews and studies against 300K synthetic + ~10K interview-grounded "real person" agents, and get an insights report in minutes. Its public API is a team-provisioning + embedding API (Bearer team key; impersonation login URLs to embed studies in your app), NOT a studies-execution API — studies run in the UI. Use when setting up an atypica study or AI Persona, running a concept/pricing/message test against synthetic consumers, embedding atypica in your product via the impersonation API, provisioning team members via the API, reading the 85%-human-likeness or flywheel claims critically, or deciding whether a synthetic 'yes' is real demand. Do NOT use for comparing synthetic-research/persona/idea tools across the market (use /sales-idea-validation) or analyzing real-customer NPS/VoC feedback (use /sales-customer-feedback).
Instrucciones de origen · Vista previa de solo lectura
name
sales-atypica
description
atypica.AI (atypica.ai) platform help — an AI research-agent platform that simulates consumers: build AI Personas from a four-layer "subjective world model", run AI-moderated Deep Interviews and studies against 300K synthetic + ~10K interview-grounded "real person" agents, and get an insights report in minutes. Its public API is a team-provisioning + embedding API (Bearer team key; impersonation login URLs to embed studies in your app), NOT a studies-execution API — studies run in the UI. Use when setting up an atypica study or AI Persona, running a concept/pricing/message test against synthetic consumers, embedding atypica in your product via the impersonation API, provisioning team members via the API, reading the 85%-human-likeness or flywheel claims critically, or deciding whether a synthetic 'yes' is real demand. Do NOT use for comparing synthetic-research/persona/idea tools across the market (use /sales-idea-validation) or analyzing real-customer NPS/VoC feedback (use /sales-customer-feedback).
argument-hint
[describe what you need help with in atypica]
license
MIT
version
1.0.0
tags
["sales","pre-launch","platform"]
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:
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
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 demand test (smoke-test page, waitlist, pre-sale) after synthetic signal
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.
