I watched a podcast interview this week — Peter Yang talking with Jason Liu, a developer experience engineer on OpenAI’s Codex team — walking through how Liu runs his entire workday through an AI agent. Reading emails, triaging Slack, drafting messages in his own voice, checking in flights, editing videos while he’s on a bike ride.
I kept waiting for the part where he described something I hadn’t already built. It never came.
That’s not a brag. It’s the more interesting story: an engineer sitting inside the company building these tools independently converged on the exact same architecture I’ve been running for months to manage my own work. When two people build the same system without comparing notes, that’s usually a sign the system is correct — not that one of us is clever.
So instead of a tool review, here’s what the convergence actually reveals: a three-layer pattern for running a life or a business through an AI agent, and the one thing that still doesn’t scale no matter how good the model gets.
Layer One: Context That Doesn’t Reset
The first thing Liu described was almost mundane: he doesn’t open a new AI conversation for every task. He has a small number of long-running, “pinned” threads — one for his role as a de facto chief of staff, one for a side project, one for planning a work event — and each one persists indefinitely. The AI compacts old context automatically so the thread never gets too big to reason over, but nothing important gets lost, because he also writes anything durable down to a set of markdown notes that live outside the conversation entirely.
That second part is the one people skip. The conversation is not the memory. The files are the memory. The conversation is just the interface to it.
This is precisely why I don’t let any of my own agents run on live-chat memory alone. Every session that matters gets checkpointed to a file before it ends — decisions made, state changed, open loops, next steps. Not because I don’t trust the AI to remember, but because I don’t trust any system, human or machine, to hold context reliably across a reset, a crash, or a tool update. Durable memory has to live in something you can grep, diff, and back up. A chat log is not that.
Layer Two: Scheduled Judgment, Not Scheduled Tasks
The second layer is the one most people building “AI automation” get wrong: they automate the action, not the judgment.
Liu’s setup runs three times a day — morning, midday, evening — and does the same thing each time: read everything (Slack, email, project board), figure out what actually needs a human, and surface only that. If a ticket needs its status updated, it just does it. If a flight confirmation shows up in an inbox, it checks in automatically and texts the boarding pass. But if something requires a judgment call or an external commitment, it drafts a response and waits.
That’s the distinction that actually matters, and it’s the one most “AI productivity” content glosses over: the automation isn’t the task, it’s the triage. The task itself — replying to a Slack message, updating a status field — is trivial and has been automatable for years. The hard part was always deciding which fifty things out of five hundred deserve five minutes of a human’s attention today. That’s the part Liu’s system is actually solving, and it’s the part that requires an agent with enough standing context to know what “important” means for this specific person, this week.
I run the same shape of system — read everything, act on the low-stakes stuff, draft-and-hold on anything external or irreversible, escalate only what’s genuinely ambiguous. The interesting design decision isn’t the schedule. It’s where you draw the line between “just do it” and “ask first.” Liu’s line moved over time, and that’s worth dwelling on.
Layer Three: Skills That Get Audited, Not Just Added
The part of the interview that stuck with me most wasn’t a capability demo — it was a maintenance habit. Liu doesn’t just keep adding automations. Periodically he tells the agent to review its own usage logs: which skills get invoked, which ones haven’t fired in months, where there’s redundant overlap (a “write like me” skill, a “Slack reply” skill, and an “email reply” skill that all do roughly the same thing and should probably be one skill). Then he has it propose consolidation, and he approves or declines each change.
This is the part nobody talks about when they demo agentic workflows, and it’s the part that determines whether the system is still useful in six months or has quietly turned into unmanageable sprawl. Every skill, automation, or standing instruction you add to an AI system is a small piece of shadow infrastructure. It has a maintenance cost even when it’s not actively broken — someone (or something) has to know it exists, know what it does, and know when it’s stopped being the right approach. Liu’s habit of periodically asking the system to self-audit against real usage data is, functionally, a governance process. He just doesn’t call it that because he’s not thinking about it as a compliance exercise — he’s thinking about it as basic hygiene, the same way you’d clean out a garage.
That’s the right instinct. Most people either never prune (bloat accumulates silently) or prune manually on no schedule (inconsistent, easy to forget). Having the system itself surface “here’s what you haven’t used in 90 days, here’s what overlaps” turns cleanup from a chore you avoid into a five-minute decision you make when prompted.
What Still Doesn’t Scale
Here’s the part that’s easy to miss under all the automation: Liu was explicit that he didn’t trust the system to reply on his behalf, in his voice, without review, on day one. He built that trust incrementally — starting with “just tell me what happened,” moving to “draft a response for me,” and only after months of consistently good drafts did he get comfortable with “post this and let me know it’s done.”
That sequencing is the actual constraint on all of this. It’s not model capability. Today’s models are already good enough to draft a passable email or a reasonable Slack reply on the first try in most cases. The constraint is that trust has to be earned incrementally, on a timeline set by the human, not the vendor. You can’t shortcut that by using a better model. You can only shortcut it by being sloppy about what you delegate before you’ve verified the system’s judgment on lower-stakes calls — and sloppy delegation is exactly how you end up with an agent that confidently sends the wrong thing to the wrong person.
The most quotable line from the interview wasn’t about tools at all. Asked what’s actually left for humans to do once an AI can execute almost anything, Liu’s answer was: the only job left is understanding what you don’t like about something and putting it into words. That’s a claim about taste, not capability — that once execution is free, the scarce skill becomes articulating precisely what “better” means, in a way specific enough that a machine (or a person) could act on it.
That’s not a new idea. It’s the same skill that’s always separated a good manager from a bad one, a good editor from a bad one, a good client from a difficult one. What’s new is that it’s no longer optional. If you can’t articulate what’s wrong with a draft beyond “make it better,” you’re not going to get a better draft — from an AI or from anyone else. The bottleneck was never really typing speed. It was always precision of judgment. The AI just removed everything else that used to hide that fact.
The Actual Takeaway
If you’re building any version of this for yourself or your team, the order matters more than the tools:
- Externalize memory first. Files, not chat history. If the system’s only memory is the conversation, you don’t have a system — you have a very articulate goldfish.
- Automate triage before you automate action. Reading everything and telling you what matters is more valuable, and safer, than reading everything and acting on all of it.
- Schedule the audit, not just the automation. Every standing skill or automation needs a review cycle or it becomes debt.
- Earn autonomy in stages, deliberately. Draft-and-hold until the system has proven itself on enough low-stakes calls that the failure mode of a mistake is survivable.
None of this requires being an engineer at OpenAI. It requires being willing to write down what you don’t like about the output until the system — and you — get specific enough to fix it.
Source: ChatGPT Work + Codex Tutorial: My Complete System at OpenAI | Jason Liu, Peter Yang’s channel.