AI’s third era: the rise of persistent AI coworkers | Tara Seshan (OpenAI’s product lead)

Why does it matter? Because the AI product rules most teams follow were obsolete before they wrote them.

Tara Seshan runs product for Codex and ChatGPT Work at OpenAI — the fastest-growing AI tools for knowledge workers on earth. She came up through Stripe as one of the first five PMs, absorbed a repeatable playbook for finding product-market fit from inside Sutter Hill's incubation machine, and now operates at the exact frontier where models change faster than most roadmaps do. What she's learned cuts against almost every standard PM instinct: the planning horizon most teams use is wrong, the way they design AI products for knowledge workers is wrong, and what product management even means is shifting faster than the job descriptions have caught up.

• The only viable AI product planning horizon is two to three months — not today, not a year out. • Knowledge work AI must show process and reasoning in real time, not just deliver a polished output. • Writing-as-thinking should never touch AI; writing-as-reporting should be fully automated. • The most valuable new PM skill is ambition elevation: raising the possibility ceiling for everyone around you.

Build for today's models and you fail. Build for next year's models and you also fail. The only viable window is 90 days.

"You fail if you build for where the models are now. You fail if you build for where you think the models will be in a year. Both outcomes are equally wrong." Seshan doesn't qualify this. The failure modes are symmetric, and most product teams are committing one or the other without realizing it.

Products tuned to current capabilities become obsolete within months. Products designed for where models will be in a year get blindsided — the specific capabilities that arrive aren't always the ones predicted, and they arrive at a pace no annual roadmap can track. The only viable alternative is a two-to-three-month window combined with a single directional prior: models are going to get dramatically better, so every product construct needs to get out of the model's way rather than constrain it. "I need to get out of the way of the model in terms of the product constructs that I create. How do I ensure that this is right for the model in two to three months time?"

At OpenAI, this is operationalized through close communication between product and research. Research teams have focused agendas — improving model capabilities in specific ways, in identifiable windows — and staying tied to that agenda is the only legitimate input to a near-term roadmap. The planning artifact isn't a strategy doc; it's a maintained conversation.

For teams outside OpenAI, the implication is direct: annual AI roadmaps are a category error. The cadence has to reset to quarterly at most, anchored by what model improvements are genuinely plausible in the window you're shipping into.

A polished deck can lie. Knowledge work AI that only shows output will never earn user trust.

Ninety percent success in a spreadsheet — and you still can't tell if the reasoning was sound. That is the verification problem Seshan says forced a fundamental rethink in how ChatGPT Work gets designed.

"Coding is so output oriented that when you ask it to do a coding task, you can verify whether it did the task correctly or well via tests. You can try it out and see if it works." The feedback is tight, objective, and fast. Knowledge work has no equivalent. A financial model can look complete while resting on a flawed assumption. A competitive analysis can feel thorough while missing a critical source. The polished final artifact gives almost no signal about whether the underlying process was trustworthy.

"Knowledge work is different in that I can't simply look at the deck in the end and see the numbers... and actually believe that. I really need to think about the process and the inputs and the reasoning and how it went along the way." This is now a design constraint, not just a philosophy. Seshan describes a sustained product effort to make ChatGPT a collaborator rather than a delivery machine — showing in-progress work, surfacing citations as they appear, letting users track the model's reasoning in real time rather than simply receiving a finished artifact.

Whether the thread interface that works well for coding is even the right surface for knowledge work at all is an open question Seshan names explicitly. The underlying principle is settled: process transparency is not a feature addition, it is a prerequisite for trust.

The moment you hand your thinking to AI, you stop thinking. The moment you hand-write your own status updates, you waste time.

Seshan draws a line that most people collapse into a single policy. Writing-as-thinking and writing-as-reporting are not the same activity, and automating both — or protecting both — is equally wrong.

Writing-as-reporting: the weekly status update, the launch announcement, the meeting summary. She automates all of it. The cognitive value of producing it manually is close to zero, and the models do it faster and more consistently.

Writing-as-thinking: the brief arguing why you should build this product, the analysis of what is actually broken in the current strategy, the spicy take on where the market is heading. "Writing is thinking is something I never will automate. I really strongly believe that the act of going through and outlining something, turning it into some level of prose, cutting it and editing it, continuing to iterate on it is one of the most important steps for me to get my ideas in line."

The practice she actually runs: "I start myself and I end myself. I might use AI in the middle to research specific elements or drop in some data or push back on some ideas." The opening is hers. The close is hers. The cognitive work is always hers.

Her anti-atrophy rule: if she is asking someone to read a document, she needs to have invested at least as much time writing it as everyone who will read it combined. Not perfectionism — a forcing function against outsourcing thought.

The one-person-one-agent era is already feeling like a problem. What comes next is teams steering shared agents together.

Inside OpenAI, people were posting screenshots of their Codex threads on Slack so colleagues could see what they had built. That is the current state of collaborative agent work: a screenshot.

Seshan names the structural gap directly. "A lot of my work with agents thus far has been one-on-one... that is potentially divorced from what my colleagues are doing with their agents." Each person runs their agent in parallel, building separate outputs, then stitching them together through Slack, documents, and meetings. The agent collaboration is siloed even when the human collaboration is not.

The direction she sees coming is different. "Ideally, work feels like a multiplayer game where all of us together are getting stuff done, steering our agents as our agents continue to take care of more and more of those rowing tactical tasks." Shared context. Coordinated handoffs. Mutual visibility into what each person's agent is actually producing.

The tooling for this does not exist in mature form. But the workflow design decisions are being made right now, which means teams building deep habits around solo agent work are creating patterns they will later have to unlearn. What does shared agent context look like? How do you review a colleague's agent output? What does a handoff between agents even mean? These are the next-order interface questions, and nobody has answered them yet.

The PhD-thesis strategy doc is theater now. Find the eigenquestion and test it as fast as possible.

At Stripe, long-form reasoning was a competitive edge. Payments is an established market; the person who thinks more rigorously than everyone else wins, and skipping that analysis shows up as carelessness. Seshan was trained to prize those documents.

At OpenAI, the same instinct became a liability. "Rather than writing out some long reasoning doc almost like a PhD thesis of what I think should be the plan for the next end amount of time — instead it's like how do I get to something I can try out and test with users as fast as possible."

The AI product market is too emergent and too fast-moving for long-form prediction to be worth much. The antidote is not less thinking — it is more pointed thinking. Seshan uses the frame of the eigenquestion, borrowed from Shashir Mehrotra: "What is that specific most important thing to test, and everything else, like any other grand strategy you concoct, is not relevant."

"Being prolific and being more like empirical is way more important than being maybe more academic or theoretical." This cuts across every function at OpenAI. Engineers, designers, data scientists, and EMs have all moved to the hypothesis-test-refine loop. The PM's distinctive contribution in this environment is sharpening what the question actually is — not building the most elaborate answer to a question that will be wrong by the time you finish writing it.

Expanding what your teammates believe is possible is now a core PM competency.

The people who extract the most from AI are not the ones automating what they already did. They are the ones using it to do things they previously could not — closing the gap between what is in their head and what they can actually ship.

Before AI, the unicorn hire was the person who combined strong product sense with the ability to code, design, and build. That full-stack capability compressed translation layers and accelerated every feedback loop. Now, Seshan argues, AI gives everyone access to a version of that superpower. The question shifts from capability to ambition.

"Elevating others' ambitions or reminding them of what's possible here is a huge part of the product management role." When a teammate presents a scope, a timeline, or a first version, the job is to ask: is the possibility ceiling meaningfully higher? Couldn't we try this faster? Couldn't we do this at 10x scale?

OpenAI formalizes this as a standing question — "Is this maximally accelerated?" — alongside another: "Are you mainlining it yet?" meaning, are you using the product so deeply in your own work that your feedback is grounded in daily practice rather than observation from a distance.

"The hardest part about doing this is simply just expanding your thinking. Actually, the capabilities have expanded so dramatically — is really expanding your thinking of what's possible in an unreasonably short time frame." The capabilities are there. Imagination is the bottleneck.

Nail the pitch before you touch the product — the Sutter Hill lesson most founders skip.

Product-market fit gets all the attention. What Seshan says she consistently underrated — until Sutter Hill — is what comes before it.

"I really underrated product marketing fit. The idea that the way you talk about the product and the way you market it can precede actually even building the product." At Sutter Hill, Mike Speiser has found product-market fit repeatably across companies that became category-defining. The playbook is not luck. One non-obvious piece of it: the positioning narrative is a hypothesis, and it should be tested before any product shape is committed to.

"You should go pitch 100 people. Figure out how to refine that pitch as much as possible. Get the marketing narrative of why this thing is transformative right, and then and only then go commit to — okay, this is exactly the product shape." The pitch is the cheapest test available. If you cannot make people feel the transformation in a conversation, the product you plan to build is probably wrong.

Most teams treat positioning as a post-build problem — something to hand off to marketing once the product exists. The Sutter Hill model inverts the sequence entirely. The narrative comes first, because it determines what to build.

A cloud agent locked out of your Google Docs is no more useful than a brilliant new hire locked in a room.

Imagine onboarding a talented new colleague and refusing to give them access to Slack, email, the company database, or any shared document. They would accomplish nothing, regardless of how smart they are.

"How can agents talk to all these third-party systems that have all of your data? A colleague who you hire who you lock into a room, never give them access to Google Docs and Slack and the company database, would not be that useful to you. Similarly, a cloud agent that is similarly isolated will not be that effective."

Local agents sidestep this by default — everything on your machine is already accessible. Cloud agents have to earn that access, system by system, through infrastructure that takes real work to build. "A huge part of making these agents useful... is really tactical — data access, cloud infrastructure, and reliability pieces that feel much more prosaic than some of the broader intelligence questions, but matter in some ways just as much for end effectiveness."

Teams spending cycles on prompt engineering while their agent cannot see their project management system are optimizing in the wrong order. Map the integrations first.

The persistent co-worker era is close — and the interface for it does not exist yet.

Seshan maps three eras of AI products: chat, then coding agents, then what comes next — persistent AI co-workers who feel like teammates, working alongside humans over time, syncing at natural cadences, checking in on progress, picking up where they left off. The intelligence for that third era is nearly there. The product design is not.

Nobody has solved shared agent context, collaborative steering, or what it looks like when a team can see and build on each other's agent work in real time. Those interface decisions are being made now — mostly by default, through the solo-agent habits everyone is building today.

The teams that think carefully about collaborative workflow before the tooling catches up will define what work looks like next.

---

Topics: AI product strategy, product management, agentic AI, knowledge work, OpenAI, Codex, ChatGPT, startup strategy, writing frameworks, product-market fit, go-to-market, future of work