Michelle Pokrass

Michelle Pokrass co-led OpenAI’s August 2024 Structured Outputs release, which lets developers specify the structure of model responses using JSON Schema. In September 2024, she was OpenAI’s API tech lead and a member of its API models team. She wrote the release announcement, whose core contributors also included Chris Colby, Melody Guan, Ted Sanders and Brian Zhang.[1][3][2]

Pokrass described Structured Outputs as a collaboration between engineering and research, involving API models, post-training and safety teams. Earlier JSON mode constrained responses to valid JSON, but could still produce unexpected keys or the wrong value types. The new approach combined training for format following with token masking, which excludes next tokens that would violate the supplied schema. Constraints alone, she explained, could yield legal but unhelpful output—such as a long sequence of whitespace. Training helped the model produce useful responses within those constraints.[3]

At OpenAI DevDay on October 1, 2024, Pokrass presented Structured Outputs with Atty Eleti. She explained the implementation; Eleti covered application examples and the research side. Simon Willison’s contemporaneous account describes her explanation of precomputing and caching a schema-derived index so that masks could be retrieved quickly during generation. The implementation also used a stack to support recursive schemas. That capability mattered for generated interfaces, where a component’s children can contain further components.[5][3]

Pokrass distinguished function calling from a structured response format: function calling generates arguments for actual tools or actions, such as querying a database or sending an email; a structured response format shapes an answer to the user. Developers had previously repurposed function calling to obtain formatted answers. She described the new response format as a direct way to meet that need, and emphasized that Structured Outputs worked in one generation rather than through a retry loop.[3]

Her schema-design decisions favored explicit contracts. The team required developers to supply additionalProperties: false rather than silently redefine JSON Schema’s existing default. It also required every key to be declared required; a nullable union, such as an integer or null, could represent an optional value while retaining the key. As she put it in the September interview, “One of our design principles is to be very explicit, and so developers know what to expect.” The supported schema dialect covered a subset of JSON Schema.[3]

Pokrass explained two related latency tradeoffs in September 2024. The team considered a separate endpoint for preregistering schemas and passing schema IDs, but kept schemas in chat completions to avoid another endpoint and additional integration complexity. It also deferred parallel function calling with Structured Outputs: changing a combination of functions could require a new combined-schema artifact, introducing delays that developers would find difficult to predict. These were decisions about the feature’s state at that time.[3]

A separate refusal field preserved the model’s ability to reject harmful requests while giving developers a clear way to handle a response outside their requested schema. Pokrass argued that a refusal did not fit neatly into HTTP’s client-error or server-error categories: it could follow a valid request and reflect intended model behavior. She discussed a possible range of model errors as a design proposal.[3]

In the October 2024 DevDay interview, Pokrass explained that building advanced voice mode had exposed the difficulty of delivering live conversation through request-response APIs, leading the team to a WebSocket API. She considered WebSockets a natural fit for bidirectional streaming. When Willison described connecting from a browser with an API key visible in source code, she advised against that arrangement for production.[4]

Pokrass praised the Assistants API’s hosted tools while acknowledging its setup burden. In September and October 2024, she criticized the number of requests needed to create an assistant, a thread and a run, and said the team wanted to make that sequence easier. “It shouldn't be so hard,” she said in October.[3][4]

Pokrass viewed the API as OpenAI’s broadest vehicle for distributing AGI because developers could reach niches and communities beyond its first-party products. She also argued that better AI tools would preserve the value of clearly specifying requirements: “Most of engineering is like figuring out the requirements and stating what you're trying to do.” She encouraged developers to build their own evaluations so they could test prompting choices and adopt new models with confidence.[3]

Before her Structured Outputs work, Pokrass worked on payments and rapidly growing backend systems. She described database troubleshooting skills from Coinbase and Clubhouse as carrying forward into her work at OpenAI.[3]

Pokrass is Canadian and attended the University of Waterloo, where she completed six internships. Her early work included animating bond yield curves in Visual Basic at a bank, an internship at Google, and a 2016 Coinbase internship working on ACH payment rails. She recalled being put on call at Coinbase and learning to manage production databases. A subsequent Stripe internship gave her experience with another side of payments.[3]

During an entrepreneurship co-op at Waterloo, Pokrass started Readwise with her roommate. She recalled working on it for about a year, while crediting Tristan and Dan as “the real founders” and describing her involvement as an interlude. She decided to return to Coinbase to develop further as an engineer because she did not yet feel equipped to be a CTO.[3]

Pokrass recalled joining Clubhouse as its second or third backend engineer while the service was growing rapidly. Reliability and notification speed were early priorities: she remembered notifications taking roughly ten minutes to reach everyone, long enough to undermine a live room before its audience arrived. Followers were stored in Postgres, and notification processing needed better batching, parallelization and job-queue infrastructure. She also recalled an appearance by Oprah overwhelming the service. She favored DynamoDB for scaling and described moving from Postgres to DynamoDB as requiring a different design mindset.[3]

Daily use of GitHub Copilot motivated Pokrass to join OpenAI before ChatGPT. She recalled an API team of only a handful of engineers. When ChatGPT launched, its accounts reused API account infrastructure, bringing Postgres and authorization-scaling problems. Scarce GPU capacity also required allocation decisions rather than the unrestricted autoscaling she had encountered elsewhere.[3][4]

Pokrass worked on and shipped the Whisper API, which she described as one of her first API launches. She also worked with the small team building the Assistants API ahead of the first DevDay in 2023. Recalling that launch, she said an outage roughly two hours before the live keynote demonstrations sent the team scrambling; they restored service, and the demonstration went well.[3][1]

In September 2024, Pokrass described the colleagues she most enjoyed working with as “low ego, user-focused, driven”—willing to do necessary work without pretension. She returned to Latent Space with Josh McGrath for an interview about GPT-4.1 published April 15, 2025.[3][6]