Bret Taylor: Building AI products and adaptable organizations

Bret Taylor, Sierra co-founder and OpenAI board member, talks with Shane Parrish about building AI products and organizations that can adapt. The useful thread is accountability: generating more code or delegating more decisions does not remove responsibility for whether the resulting system works.

Based on English auto-generated captions, without an original-audio check. Company practices and results are Taylor's account, not independent product evaluations. Forecasts reflect this conversation; the date above is the video's YouTube publication date, not a verified recording date.

Building AI products that complete work

• Shift effort from producing code to verifying its behavior. Taylor argues that AI can multiply code volume without removing security flaws or functional bugs. Human reviewers still have to reconstruct what that code does. He proposes exploring languages designed for safety and reviewability, formal verification—checking specified properties through mathematical reasoning—and extensive tests as parts of a new programming system. This is a research direction, not a demonstrated system or measured productivity gain. 27:35–35:45(opens in a new tab)
• Automation still needs an accountable operator. For Taylor, the person producing a system remains responsible for security, reliability, intended behavior, and appropriate limits on autonomy. Using AI to supervise other AI may help, but does not make switching on an unattended system the goal. 45:17–48:25(opens in a new tab)
• Sierra links pricing and delivery to completed tasks. Taylor says Sierra charges a negotiated amount when a customer's agent resolves a problem and helps deliver a working agent rather than only handing over software to configure. His rationale is that software completing work has a different value proposition from software helping a person do it. This describes Sierra's model in the interview, not a claim that outcome pricing suits every product. 25:28–27:35(opens in a new tab)
• A workflow needs more than a model response. Taylor uses a shoe return to illustrate the surrounding work: checking eligibility, choosing an in-store or shipping route, and arranging the return. He argues that coordinating those steps can matter as much as the model itself; putting more information into a model's context window is not the whole product. 1:23:50–1:25:55(opens in a new tab)

Choosing the scope of an agent

Taylor distinguishes personal agents that must work across many services, role-specific agents such as coding or legal assistants, and customer-facing agents representing a company. He expects personal agents to be harder to trust because they must handle many services and private information. For narrower roles, he argues that limiting the decisions an agent may make allows stronger safeguards; that is not proof of reliability. 1:46:37–1:50:16(opens in a new tab)

For a branded agent, customers can describe a problem in their own words rather than navigate a fixed menu. The company still decides which requests it can fulfill. Taylor argues that representing the brand raises the reliability bar. 1:50:16–1:54:20(opens in a new tab)

Taylor also says Sierra lets companies define the customer experience separately from the underlying models, so changing models need not mean rebuilding that experience. This is his vendor proposition, not an independently verified guarantee. 1:53:18–1:55:19(opens in a new tab)

Keeping an organization responsive

• Founder accountability is not permission to micromanage. Taylor supports leaders examining small decisions when necessary, while warning that a company cannot scale through one person's judgment alone. Employees need authority and accountability, not incentives to guess what will please the leader. 15:20–19:20(opens in a new tab)
• Make acquisition expectations concrete before closing. Beyond the story of why two companies belong together, Taylor wants agreement on control, team structure, and what success will look like. He favors those conversations after agreement on the main terms but before the transaction is completed, while both sides still have room to negotiate. 06:00–12:19(opens in a new tab)
• The Google Maps rewrite depended on accumulated understanding. Taylor recalls replacing a slow implementation over a weekend, followed by roughly a week of bug fixing. He already knew the product and the decisions that had made it cumbersome. A working, faster prototype helped colleagues judge the result rather than defend their existing code. This is Taylor's retrospective account, not evidence that large rewrites are generally quick or safe. 1:30:05–1:36:14(opens in a new tab)
• Internal incentives can drown out customers. Taylor describes two sources of stagnation: processes accumulating after individual failures, and internal success stories becoming more influential than customer evidence. His response is direct customer contact and leadership support for removing obsolete processes, acknowledging that removing a process can reintroduce risks it once controlled. 1:54:20–2:02:34(opens in a new tab)

Applying the discussion carefully

Editorial implications: for an AI product, define what counts as a completed task, which decisions the agent may make, and how a person will verify the result. For the team building it, distinguish evidence of customer value from code volume or internal confidence. These are practical interpretations of Taylor's argument, not a validated deployment checklist.