Core-Behavior Synthetic Training
Ship an AI feature by naming its 3-4 core behaviors and teaching them with model-generated data
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 90%
A repeatable method for building an AI product feature without waiting on human-labeled data. You decompose the feature into a small set of core behaviors, then teach each one by sampling synthetic training examples from a model, measure with robust evals, and after launch re-shift the synthetic distribution to match how real users actually behave. Karina Nguyen used exactly this to build ChatGPT Canvas and Tasks at OpenAI.
Origin
Described by Karina Nguyen (Research at OpenAI, ex-Anthropic) as the process she used to build Canvas and Tasks; she credits the underlying craft of debugging and shaping model behavior to her early days at Anthropic.
Core principles
- 01A feature is not a monolith — it is a handful of nameable core behaviors, each independently teachable and measurable.
- 02Synthetic data (sampling from the model) is preferred over human data because it is cheaper, more scalable, and generalizes across diverse coverage.
- 03One model can simulate the user side of a conversation to generate training examples for another.
- 04Real user feedback after launch is used to shift the synthetic distribution, not to start over.
- 05Every behavior must be tied to an eval so progress is measurable, not vibes.
How to run it
- 1
Decompose the feature into core behaviors
Write down the small set of behaviors the feature must perform. For Canvas this came down to three: when to trigger (and not trigger) the surface, how to edit the document on request, and how to make comments on a document.
Pro tip Include the negative case explicitly — 'when NOT to trigger' is as much a behavior as 'when to trigger'.
- 2
Generate synthetic examples by sampling from a model
For each behavior, produce training data by prompting a model. Use one model to simulate the user side — e.g. have it write a document, then inject a user prompt like 'critique this piece of writing' — and teach the target model the desired response.
Pro tip Set an intentional starting bias you can correct later (Canvas was first biased toward full rewrites because their quality was higher), then shift it as feedback arrives.
- 3
Teach the decision boundaries inside each behavior
Behaviors have sub-decisions — e.g. within 'edit', whether to rewrite the whole document or make granular targeted edits; within 'trigger', whether user intent is document iteration vs. a quick answer. Encode these as part of the training.
Watch out A behavior taught in isolation can conflict with another — teaching the model it has no physical body while also teaching it to 'set an alarm' made Claude over-refuse. Check for cross-behavior contradictions.
- 4
Measure progress with robust evals
Attach an eval to each behavior so you can tell whether a new model is improving. This is the objective anchor that turns the 'art' of training into something trackable.
- 5
Re-shift the synthetic distribution from real usage
After launching (e.g. beta to GA), learn from how users actually behave and shift your synthetic sets to match that distribution. This is the improvement loop.
Pro tip Instrument the product to capture user conversations and feedback from day one so you have material to reshape the distribution.
In the wild
Nguyen pitched Canvas to move ChatGPT from chatbot to collaborator. The team reduced it to three core behaviors — trigger/don't-trigger, update-the-document-on-request, and make-comments — and taught each synthetically, using o1 to simulate user conversations and produce documents to comment on. They biased early toward full rewrites for quality, then shifted based on user feedback.
→ Canvas shipped as OpenAI's first project where researchers and applied engineers worked together from the start of the product cycle; roughly a 4-5 month zero-to-one.
For Tasks the team designed a tool spec — what information the model must extract from a prompt like 'remind me to go to lunch at 8am tomorrow' — and built deterministic evals (if the user says 7pm, the model must output 7pm).
→ Tasks went from zero to one in about two months.
Common mistakes
Teaching behaviors in isolation without checking for conflicts
Contradictory lessons collide at inference time. Anthropic taught Claude it had no physical body while separately teaching function calls like setting an alarm, so the model got confused about whether it could act and would over-refuse. Always test whether a newly-taught behavior contradicts an existing one.
Skipping evals and shipping on intuition
Without an eval per behavior you cannot tell whether a new model is improving or regressing, and optimizing one behavior can silently damage other areas of intelligence. Progress becomes unmeasurable guesswork.
Is it for you?
Best for
Product teams and AI PMs building a discrete LLM-powered feature who want to move fast without waiting on expensive human-labeled datasets
Not ideal for
Domains requiring genuine expert knowledge (specific chemical or biological facts) where you must tap real human experts rather than sample from a model
From the transcript
“the way you synthetically train the model is basically figuring out like what are the most core behaviors that you want that this product feature…”
“for Canvas, for example, uh it was it came down to like three main behaviors”
“we would use a one model to produce to like simulate like user conversation”
“it all came down to like measuring progress via very robust evals”
“when we launched from beta to GA”
From the episode
OpenAI researcher on why soft skills are the future of work
Karina Nguyen (Research at OpenAI, ex-Anthropic)