Tara Seshan on ChatGPT Work and Codex: What happens when AI becomes a persistent coworker?

How persistent AI colleagues differ from chat and one-off agents

Seshan distinguishes three kinds of working relationships: a single Q&A exchange, a one-off task, and an ongoing project. They can coexist; what matters is whether the AI can retain context over time, keep working, accept human review and correction, and operate in a shared workspace with multiple people. The interactive diagram below places all three relationship types across the same set of dimensions; click each phase to compare time scale, context, human involvement, and scope of collaboration.

“Persistence,” then, requires at least five conditions:

1. A sustainable runtime. Tasks can continue on-device or in the cloud, without stopping just because a chat session ends.
2. Usable project context. It can read files, historical decisions, data, and relevant business background.
3. Controlled permissions. Email, documents, code repositories, and financial systems each have clearly defined access boundaries.
4. Enough reliability. Long tasks can recover from failures, critical actions can be inspected, and results can be traced.
5. A collaborative interface. People can see progress, step in mid-task, and bring another colleague into the same work.

Seshan stresses that these are “unremarkable” pieces of infrastructure. Making the model smarter alone still leaves you with a clever temp worker that has no computer, no files, and no way to deliver reliably. OpenAI’s product positioning for ChatGPT Work likewise includes working across apps and documents, sustained execution over hours, and going from a goal to a finished artifact, and she notes it builds on Codex’s underlying technology. See the OpenAI product announcement.

ChatGPT Work and Codex: the same execution engine, different front doors

At the time of the interview, users saw several names: Chat and Work inside ChatGPT, plus standalone Codex. Seshan’s explanation is straightforward: these entry points primarily serve people at different levels of familiarity.

Work runs on Codex’s execution engine underneath. According to Seshan, asking Codex to build a financial model doesn’t inherently produce worse results than using Work; the difference is mostly in which details the product surfaces to the user. OpenAI’s help center similarly describes Chat, Work, and Codex as different modes of working, with the long-term direction being to reduce the burden of choice for users. See the OpenAI help center.

The endgame is not getting a billion users to learn what a model, a harness, or a work tree is. Users only need to describe the goal; the system picks the appropriate model, tools, and execution environment, then presents the right kind of control panel for the task. Having multiple entry points is a transitional product decision, not a permanent cognitive load we should accept forever.

From rowing to steering: how people and AI should divide the work

Seshan uses the phrase “from rowing to steering” to describe the shift for product managers. Rowing means personally pushing every execution step forward. Steering means deciding where to go, why to go there, how to tell when you’re off course, and when it’s time to change direction.

When agents can write code, do research, generate models, and build pages, the boundaries between engineering, product, and design get thinner. One person can now span what used to be several specialized roles to get more of the job done. But thinner boundaries don’t mean accountability disappears. Teams still need clear owners for three questions: Is there someone who needs this product? Does it meet the quality bar? And who answers for the final outcome?

Thinner role boundaries also abstract away parts of older craft skills. Seshan doesn’t offer an easy answer: product managers may no longer hand-polish certain traditional deliverables, and engineers will miss the flow of handwriting code. New professional capabilities will shift from executing a specific task to choosing problems, orchestrating tools, judging quality, and owning results. How to balance cross-functional efficiency with deep skill development in one’s home discipline remains an open question.

When everyone on a team has access to similar models and tools, differences come down to these abilities:

• Direction. Choosing which problem is worth solving, and rejecting tasks that look doable but don’t add value.
• Taste. Judging what combination of experience, expression, and detail makes a finished work. Seshan compares software to film: a bigger budget doesn’t automatically produce a better movie.
• Communication. Turning vague feelings into clear positions that others can understand, question, and refine together.
• Accountability. Owning the correctness, impact, and follow-up of results, and not blaming the model when things go wrong.
• Relationships. Helping teammates trust each other, learn together, and push the bar higher.

That last point connects to what Seshan keeps returning to: ambition. Many teams use AI to automate old tasks—write weekly reports faster, produce the same analysis you could already produce, but quicker. The high-performing users she observes instead re-estimate the size of what’s possible: Can one person now build what used to take a small team? Can a team compress months of exploration into weeks and reinvest the saved execution into bigger problems?

This isn’t a demand to speed up all work indefinitely. It reveals a new constraint: as execution costs fall, the ceiling on what an organization can achieve depends more and more on what its people believe they can do. Part of the PM’s job shifts from pushing deadlines to helping the team raise its sense of what’s attainable.

How OpenAI designs products ahead of rapidly evolving models

Traditional software treats the underlying platform as a relatively stable constraint. Teams know roughly what databases, browsers, and devices can do, then optimize features within those bounds. Frontier AI products face a moving floor: something unreliable today may become viable in a few weeks, and a patch designed around today’s limitations can be dead weight by launch.

Seshan says OpenAI’s internal working window is two to three months.

• Designing only for the current model means teams often pour engineering into the exact spot the model “just barely” works. By the time the product ships, a stronger model has already eaten that difficulty.
• Designing for capabilities a year out assumes too much; you can’t validate with real models and real user behavior, so vision easily becomes speculation.
• Two to three months lets the product team consult the research roadmap and prepare new interaction and execution frameworks well ahead of time, while still getting observable feedback fast enough to act on it.

This time window can’t be applied mechanically at every company. OpenAI has direct access to the model research roadmap and uses internal builds heavily; outside teams don’t have that same visibility. What does transfer is the method: write product judgments as falsifiable hypotheses, then create evidence as quickly as possible.

Seshan borrows the “eigenquestion” concept from Coda co-founder Shishir Mehrotra: find the one question whose answer makes a large set of downstream questions clearer at once. Then build a prototype, put it in front of real users, watch what they do, and revise the hypothesis. Product managers used to spend weeks writing a full spec; the more effective communication artifact now is often a clickable mock, a runnable prototype, or a set of experiment results already in hand.

This also explains OpenAI’s speed. There’s no “secret strategy document” governing everything, Seshan notes. Team members are expected to find problems like founders, use their own products continuously, and close the loop between internal experience and external market feedback quickly. Speed comes from turning uncertain judgments into checkable reality faster, without dropping quality control.

That speed carries clear trade-offs. Seshan says mature software teams used to wait until every interaction was fully polished before shipping; when both models and user habits are shifting quickly, and the team is confident the product is a step-change, shipping early and iterating on real feedback often beats waiting for perfection. This doesn’t mean abandoning usability—it means asking whether the product creates enough of a difference before spending time polishing every corner.

Verifying an AI colleague’s work means more than checking the final output

Porting coding agents to knowledge work means confronting a key difference in how you verify results.

Code has strong outcome checks: does it compile, do tests pass, does the UI run, does performance meet the bar? Tests don’t guarantee the product is right, but they eliminate a large set of wrong answers fast.

A financial model, a market research deliverable, or an executive presentation has no equivalent “pass” button. Numbers in a spreadsheet can be beautifully formatted but cite the wrong source. A slide deck can read smoothly yet omit the counterexample that would change the conclusion. A report’s last page says “90% success rate,” but the reader can’t judge from that single digit alone whether it’s trustworthy.

Verifying knowledge work requires a longer chain of evidence:

1. Is the context complete? Which emails, documents, data sources, and prior decisions did the agent actually see?
2. Are the inputs reliable? Is it using primary sources, secondary summaries, or unchecked web snippets?
3. Can the process be intervened in? Can a person stop the agent when it’s heading the wrong way, add constraints, or narrow the scope?
4. Are intermediate artifacts reviewable? Are key assumptions, citations, calculations, and discarded options visible?
5. Can the final result be traced? Does every important number or judgment have a source and an owner?

This doesn’t mean exposing the model’s private chain of thought. What needs to be exposed is evidence of the work: what was cited, what was executed, how the artifact evolved, and where human confirmation is needed. The more independently a persistent colleague can act, the more important it is to let people stay informed and in control without much overhead.

Starting with writing: what to hand to AI, and what to keep for yourself

Seshan’s line on AI writing is more specific than “use it or don’t.”

“Writing to communicate” covers weekly reports, status summaries, meeting prep materials, formatting conversions, and reorganizing known content. The goal is accurate transmission of existing information, which makes it a good fit for letting the model do the heavy mechanical lifting.

“Writing to think” happens when the position isn’t yet formed. Outlining, drafting a first version, cutting weak sentences, and spotting gaps in the argument—these actions are the thinking. If the model generates the full text up front, you may get a fluent document while skipping the process of forming the judgment itself.

Her personal rule: thinking-heavy writing starts with her and ends with her. AI can search for sources, pull data, raise counterarguments, and attack assumptions in between; the final structure and wording still go through her own judgment. She also keeps a collaborative practice: bring a document to the people who need to be involved when it’s about 70% done, leaving room for them to question and shape it. A fully polished artifact tends to bounce new ideas off rather than inviting them in.

She also applies a strict personal accountability rule to documents and meetings: if she asks several people to read a document, she reads it at least as many times herself; if she calls a meeting, she prepares for it roughly the same total hours as all attendees combined. The point isn’t to tally time mechanically—it’s to avoid using AI-generated material to offload the burden of understanding and review onto others.

The same distinction applies to other kinds of work:

Seshan mentions using Sites to build team games, travel itineraries, and internal dashboards, and Visualize to turn data into a narrative. These examples make the point that the default deliverable in knowledge work doesn’t have to be a document or a slide deck. A one-off need can become a small, shareable tool with a database behind it. AI colleagues expand the range of forms you can produce; people still decide what deserves to be expressed.

At Sutter Hill, she also picked up a more upfront kind of validation: testing for "product-marketing fit." Before building out the full product, teams pitch what it solves and why it changes the game to a broad set of potential users, then watch which framing lands and makes people want to stay engaged. In this view, narrative isn't wrapping applied after the product is done — it's a cheap discovery instrument. Once models make prototyping cheap, positioning, prototypes, and real feedback can all feed into the same validation loop from much earlier.

Six protocols for working with persistent AI colleagues

Individuals and teams don't need to wait for some fully matured "third phase" before restructuring how they work. A complex task can be reworked around six explicit agreements right now:

1. Write goals, not just actions. Besides "put together a report," clarify what decision it supports, who it's for, and what done actually looks like.
2. Provide the necessary context. Keep source material, past decisions, and constraints together in the same project so the agent doesn't have to fill gaps with guesses.
3. Build in checkpoints. For longer tasks, lock down research scope, structure, or samples before letting the agent scale up the execution.
4. Require evidence of work. Save sources, calculations, edit history, and anything unverified so the final output is traceable.
5. Keep a single accountable owner. The agent can execute, but the person who approves publishing, payments, external communication, or high-risk calls needs to stay in the loop.
6. Raise the bar every cycle. Log the time saved, but also ask whether you're just doing old tasks faster; push some of that new capacity toward projects you previously couldn't start.

Near the end of the interview, Tara described "persistence" with a very concrete mobile scenario: you brief a task on your phone, go underground into a subway car without signal, and by the time you surface the work is already done in the cloud, ready for you to review and discuss. It sounds like simple background processing, but it fundamentally remakes the work relationship — you no longer supervise every step, but you have to be more deliberate about direction, boundaries, evidence, and accountability.

The more independently AI colleagues operate, the more human work collapses down to the questions that can't be answered by generating more content: where we're headed, what's good enough, which evidence actually counts, and who's willing to take responsibility for the final call.