Codex for Knowledge Work

Codex is an agentic workspace: You give it a goal, and it plans the work, uses available tools and context, and produces a result for you to review. It can read and write files in the project folder you open, work with external services through plugins and apps, run multi-step workflows, generate code and scripts when a task needs them, and create documents, spreadsheets, presentations, PDFs, and websites.

Codex can:

These capabilities make Codex useful both for delegating well-specified tasks and as a shared workspace for human-agent collaboration. The central judgment call is deciding which mode fits the task.

Five Codex features do most of the organizational work in this guide. They are easy to blur together, but each solves a different problem: Projects hold shared context, threads keep individual assignments separate, goals hold a longer objective, plugins add reusable capabilities, and Sites turn work into a shared interface.

Projects

A project gives Codex a particular folder and its instructions as the working context for one or more threads. Use one project for each ongoing area of work—a product launch, weekly reporting, recruiting—so its threads can draw from the same source material and rules. Keep durable decisions, current status, and source links in the project files rather than relying on any single conversation to remember them.

Threads

A thread is a conversation for one assignment or line of thought inside a project. Start a fresh thread when the assignment changes or a conversation becomes difficult to navigate. Long threads accumulate noise and Codex may compact them by summarizing relevant information. Project files preserve important information between conversations.

Separate threads do not automatically share their conversation history or report into one another. They can still coordinate through several mechanisms:

A useful handoff prompt is: “Find the thread called [name]. Send it this update: [decision and source]. Ask it to [bounded task], save the result to [location], and report back when it is ready for review.” For consequential work, don’t assume the handoff worked; review the other thread or shared file.

Goals

A goal in Codex, initiated using the /goal command, is a persistent objective for a longer task. You tell it what “done” looks like, how success gets checked, and which constraints to respect. Codex works toward that outcome until it finishes, pauses, or needs your input. You can pause, resume, edit, or clear the goal as the work changes. If /goal is unavailable, you may need to enable the Goals feature.

Use /goal when an assignment has a clear destination but will take many steps. Standing instructions such as “cite every factual claim,” “match the house style,” or “never send without my review” belong in project files or a reusable skill instead.

Goals versus skills: A skill teaches Codex how to handle a recurring kind of task. A goal names what you are trying to accomplish in one longer stretch of work. When the objective is met, the goal is done.

Plugins

A plugin is an installable bundle of skills, apps, and MCP servers built around a reusable workflow. Browse the Codex plugin directory before building a common workflow from scratch. Use a local skill while the procedure is still changing; package a stable workflow as a plugin when you want to share it. Plugins are also useful when the workflow depends on bundled apps or MCP servers..

Installing a plugin does not give the plugin unlimited access. Its apps and MCP servers still depend on their own authentication, permissions, privacy rules, and workspace policies. Which plugins you can install can vary by plan, region, and workspace settings.

Sites

Sites turn plans, reports, dashboards, and other working material into hosted webpages or web apps. Use a Site when people need a shared workspace that remembers progress and supports recurring tasks. If they only need to read it, keep it as a document. A Site can remember progress when durable storage is configured.

Build the underlying workflow manually first. If a Site is justified, save a version for review before deploying it. Every deployment URL is a production deployment, so check the content, data handling, access settings, and audience before widening access. Sites can be limited to workspace admins, everyone in the workspace, or specific members and groups.

Codex needs supervision. It cannot replace taste, judgment, ownership, human review, or fact-checking. Avoid autonomous use when the source data is inaccessible, the criteria for success are entirely subjective, or an error would carry serious consequences.

A task is a good candidate for Codex if it has at least two of the following traits:

• It requires pulling data from multiple sources
• It involves repeated steps you do regularly
• It can be checked against objective criteria
• It produces a durable artifact—a document, a plan, a report, a script
• It benefits from synthesis across many inputs
• It’s annoying enough that you routinely delay or avoid it

Every sustainable Codex workflow follows the same five-step pattern:

Connect: Give Codex access to the systems you use for work—Gmail, Slack, Notion, Google Drive, your calendar, your analytics tools, your support platform, or local files. Without connected apps or source access, Codex is limited to the local and project files it can access, uploaded or linked materials, and context you provide in the thread. With connections, it can search the approved sources instead of relying on whatever you remember to paste into the prompt.

Contextualize: Put your goals, preferences, project details, source links, review standards, and standing rules in files Codex can access, then cite those files in Codex’s AGENTS.md file to make them readily available. This is the difference between an agent that has to be re-briefed every time and one that already understands who you are, what you’re working on, and how you like to work.

Delegate/collaborate: Decide whether the task needs close collaboration or can run on its own. Either way, specify inputs, output format, and acceptance criteria, then let it work.

Review: Check the output in the destination app. If Codex drafted Slack messages, review them in Slack. If it wrote a strategy document, review it in your word processor of choice, such as Google Docs, Notion, or Proof. Content that looks fine in a terminal or the Codex app may read differently in the space where it will ultimately be used.

Compound: Turn what works into something reusable. Save the prompt. Document the workflow. Add mistakes to your review checklist and keep your context files up to date. Each session should make future sessions faster.

Connect the tools you want Codex to have access to. This includes Gmail, Slack, Notion, Google Drive, your calendar, analytics tools, support platforms, or anything else for which Codex has an integration. Once the relevant tools are connected, Codex can look at your actual work context and suggest workflows based on your messages, files, meetings, and recurring tasks.

Connecting a tool isn’t the same thing as giving Codex unlimited permission to act using it. Start with the narrowest access that supports a real workflow. Require approval before Codex changes data in any connected tool. Plugins and apps remain subject to their own authentication, privacy, data-sharing, and workspace policies.

Starting prompt—use this once your integrations are set up:

Once your tools are connected, Codex can look at your actual work and suggest useful workflows. Repetition alone doesn’t mean a task should be automated.

Build Codex’s workspace before running any workflows. Skip this step and you’ll likely stall.

A Codex workspace is a folder—local on your machine, synced to GitHub if you want version control—that contains the instructions, context files, workflow documents, sources, and review standards Codex needs. Think of it as an onboarding manual and working file cabinet that both you and the agent can navigate.

Do not begin by designing the whole filing system yourself. Ask Codex to interview you first:

If you already have a filing system, have Codex inspect it and propose the smallest useful set of additions. You do not need to move all of your work into a new “AI” folder. Keep the source of truth where it already lives and give Codex a clear map to it.

An example workspace structure

your-workspace/
├── README.md                  # Start here—orientation
├── identity/                  # About you
│   ├── context.md
│   ├── preferences.md
│   └── rules.md
├── playbooks/                 # Process—repeatable workflows
│   ├── workflows/
│   ├── inbox-sweep.md
│   └── research-brief.md
├── sources/                   # Source shelf—inputs
│   ├── sources/
│   ├── key-links.md
│   └── recurring-docs.md
├── outputs/                   # Finished work
│   ├── outputs/
│   ├── drafts/
│   └── reports/
└── reviews/                   # Quality checks—guardrails
    ├── data-checklist.md
    └── writing-checklist.md

What you’re doing here has a name: context engineering—arranging instructions and source material so Codex can find the right information at the right moment.

Codex reads AGENTS.md before it begins work. Keep the root file short: orient the agent, name the authoritative files, and state the rules that apply across the workspace. Put detailed or project-specific instructions in a nearer AGENTS.md inside the folder they govern. Codex combines the applicable files, with more specific instructions taking precedence.

Use supporting files only when they earn their keep. context.md can explain who you are and what you are working on; preferences.md can describe how you want work handled; rules.md can define approval boundaries; and STATUS.md can record current priorities and open decisions. A small workspace with current files beats an elaborate one that nobody maintains.

Starting prompt—use this to have Codex create your workspace structure:

Codex power users don’t arrive there all at once. They get there in stages, and each stage calls for a different way of thinking about what Codex is doing and what it’s good for. Skip ahead too quickly, and you’ll get frustrated—either you don’t trust it yet, or you haven’t built the infrastructure for more autonomous work. At every level, you should know when to hand work to Codex and when to stay in the loop as its collaborator.

Treat these levels as a ladder of complexity, not status. Levels 1 and 2 are a sensible beginner range, Level 3 is intermediate, and Levels 4 and 5 are advanced. An experienced operator may still keep high-stakes work at Level 1 because close review is the correct design.

Mental model: Codex as a capable, thorough research and drafting assistant.

Mode: Collaborate. At this level, nothing is automated. You run single-session tasks, review everything before it leaves your hands, and build familiarity with how Codex handles different types of work.

Best first tasks:

• Summarize a meeting transcript and extract decisions, open questions, and follow-up actions.
• Turn scattered notes into a structured outline.
• Build a research brief from a set of links and documents.
• Rewrite a draft against a style guide.
• Create a review checklist for a document, launch plan, or strategy memo.
• Convert a written draft into an audio file for editing on the go.

Prompt pattern:

Review habit: Before polishing any output, ask Codex to list the assumptions it made and where it is least confident. This surfaces problems before you invest time in refinement.

Move to Level 2 when: You keep wishing Codex remembered what you told it last time.

Mental model: Codex as a cross-system analyst that can assemble information you could never pull together manually in a reasonable amount of time.

Mode: Collaborate. At this level, Codex can synthesize outputs from multiple connected systems—Slack threads, Notion pages, email archives, analytics dashboards, and Google Drive documents—but it still needs guidance and feedback.

Example multi-source tasks:

• A go-to-market plan built from internal meeting transcripts, Slack discussions, customer notes, and a strategy template
• A weekly KPI report from analytics, revenue data, support volume, and social metrics
• A summary synthesized from Slack, Notion, Drive links, and past drafts
• A weekly leadership brief assembled from team standups, metrics, and open decisions

How to delegate a multi-source task:

A warning about data: A one-shot attempt at pulling data from multiple systems can be wrong because of stale data, mismatched definitions, permissions gaps, or join errors. For any metric that informs business decisions or agent actions, verify column by column against your primary source. The closer a number is to a source of truth, the more carefully it needs to be checked.

Make your outputs agent-readable: Plans and reports you generate in Codex will be read by other people—but also, increasingly, by their agents. Write them in plain, structured language that a human can scan and an agent can query. Clear section headers, explicit decisions, and labeled action items make the artifact useful in both directions.

Move to Level 3 when: You keep running the same multi-source workflow more than once a week and wishing it happened automatically.

Mental model: Codex as an automated operations layer that handles predictable, recurring work so you don’t have to.

Mode: Hybrid. Some tasks are fully predictable and can run without back-and-forth. These tasks are ripe for delegation. Tasks that involve judgment, strategy, or creative decisions suit collaboration.

A useful heuristic: If a checklist covers most cases, delegate the execution. If you need to think about the task differently each time, collaborate.

In either case, look for “computer chores”—recurring tasks that take time and attention, but don’t require human judgment at every single touchpoint.

Common chore candidates:

• End-of-day check for unanswered Slack messages and emails, with drafted replies
• Weekly metrics brief from analytics, revenue, and support data
• Meeting-note cleanup and action-item extraction after each recorded call
• Customer support pattern detection and issue routing
• Draft-to-review package that formats a piece for editor handoff
• Recruiting research for an open role

The workflow:

Before building any persistent workflow, fill out this template. Save it as the instruction file Codex should read each time you run the workflow. (The workflows in Part 4 are each an example of this canvas applied.)

Review discipline for automated workflows: Don’t review automated output only inside Codex. Review in the destination app—Slack for Slack messages, Gmail for email drafts, and a word processor for documents. The output may look different in the tool where it will be used, and the change of context often reveals problems.

Move to Level 4 when: Your prompt-based workflow hits a ceiling—the task is too complex or too custom to handle in text alone, and a small script or local tool would make it reliable.

Mental model: Codex as a builder that creates lightweight infrastructure to make your workflows more reliable, faster, or more repeatable.

Sometimes the best Codex output is a small script, a local app, a custom dashboard, or a review surface that makes a recurring workflow easier, rather than pure text.

Mode: Hybrid. In some cases, Codex may generate an artifact independently for you to review and then move on. In others, the artifact it produces may become a space where you and the agent iterate together.

Examples of when a small tool helps:

• A recurring workflow that requires pulling from an API that has no Codex integration. A short script handles the connection reliably.
• A review process where you need to see formatted output side by side with the source. A simple local app gives you the view.
• A task that needs to run on a schedule. A Codex automation can handle it after you test the prompt manually and define permissions, review, and failure behavior.
• A workflow that accumulates structured data over time. A lightweight database or structured file tracks it persistently.
• A report or review queue that has outgrown a document. A Site can give people a shared place to view the work, while a small app can remember progress and let people approve or reject items.

Practical approach for non-engineers:

1. Run the task manually in Codex once to confirm the output is what you want
2. Ask Codex: “Which steps in this workflow could be made more reliable with a small script or tool?”
3. Have Codex prototype the tool and explain what it does in plain language
4. Run it on your data and verify the output matches what the manual process produced
5. Keep only the parts that reduce friction. Discard what adds complexity without benefit.

You don’t need to understand every line of code to use a tool Codex built. You should be able to explain what goes in, what comes out, and where a person checks the result. If you can’t, the tool isn’t ready to run autonomously.

Prefer a document or spreadsheet when it can do the job. If you use Sites, ask Codex to save a version for review before deploying it: Every deployment URL is a production deployment. Check content, data handling, access settings, and audience before widening access.

Move to level 5 when: You give Codex the same feedback repeatedly and have standing preferences that you’d prefer it to apply on its own.

Mental model: Codex as a system that can improve over time when you save useful workflows, maintain review rules, and use memories or skills to codify preferences where available.

Mode: Hybrid. Some instructions will dictate how the agent approaches autonomous work; others will guide how the model interacts with you in collaboration mode.

The idea of “compounding” work comes from compound engineering, the AI-native coding methodology coined by Kieran Klaassen and Nityesh Agarwal while building Cora, Every’s email client. The canonical example is a product requirements document (PRD) that writes the scaffolding for the next one: The artifact you produce becomes the tool that speeds up the next round. The four habits below are how you put it into practice as a knowledge worker, not just an engineer.

Each useful session should make future sessions faster and more reliable. In practice, that requires doing four things consistently after completing any significant piece of work:

1. Save successful prompts as workflow files. When a prompt produces exactly the right output, document it. Write down the input sources, the exact prompt, the output format, and the review step. Save it in your workflows/ folder. The next time you need the same output, the agent will have that reference to work from.
2. Add mistakes to review checklists. When Codex gets something wrong—a number that was off, a tone that missed the mark, or an assumption it should not have made—add a specific check to your relevant review file, and instruct Codex to check its work against those guardrails.
3. Update your context files after major projects. When a project ends, update context.md to reflect what changed—new priorities, new tools, what worked, and what didn’t. Codex can use the pattern when you point it to the file or turn it into a reusable skill or workflow.
4. Ask Codex to identify compounding opportunities. At the end of any session where you did something useful, run this prompt:

When a workflow becomes stable enough to share, package it only if the plugin directory does not already cover it. Every’s compound engineering guide shows how a maintained plugin can package a complete working method rather than a single prompt.

These workflows are meant as inspiration to get you started. Adapt the inputs, outputs, and approval rules to your specific tools and standards.

Choose the lowest-complexity workflow that solves the job. We’ve tested the additional examples at Every and adapted them so they don’t depend on our private systems. For more of the operating context behind the original library, read “One App to Rule All Knowledge Work” and “The Dawn of Codex-native Apps”.

Best for: Anyone whose email backlog is a recurring source of anxiety or dropped balls.

Input sources: Gmail or your email client of choice.

Output artifact: A structured list of draft replies, proposed actions (archive, delegate, flag), and any emails flagged for your personal attention because the draft alone isn’t sufficient.

Dan Shipper kept inbox zero for 10 days straight with Codex. To use this workflow, have Codex:

1. Gather email through Cora running in the in-app browser.
2. Render the email queue as a single page.
3. Go through each item with you as you dictate the action the AI should take (e.g., “research this,” “draft that,” “pull the documents our lawyers asked for.”) You can do this via chat or voice with a dictation tool like Monologue (we recommend the latter).

First prompt:

Review step: Review all drafts in Gmail before sending. Don’t approve from inside Codex.

How to compound: After a few sessions, add a rule file describing your categorization preferences—which senders always get priority, which topics can be archived without reply, and which types of requests need a human-written response.

Best for: Anyone who communicates across Slack, email, and other channels and loses track of what still needs a response.

Input sources: Slack, Gmail, any other communication tool you use.

Output artifact: A list of unanswered items with drafted replies or proposed reactions, organized by urgency.

First prompt:

Review step: Review in Slack and Gmail.

How to compound: After a few runs, save a rules file specifying which Slack channels are high-priority, which senders always warrant a human response, and which types of messages can be handled with a reaction rather than a reply.

Best for: Anyone preparing for a meeting, a pitch, a content piece, or a strategic decision and needing a thorough, sourced summary of a topic.

Input sources: Provided links, Notion, Drive, web search.

Output artifact: A structured brief with background, key facts, open questions, and source links.

First prompt:

Review step: Check source links. Verify any statistics against the original source before using them.

How to compound: Save a brief template in your workflows/ folder. After each brief, add any recurring sources (newsletters, databases, key authors) to your sources/key-links.md so Codex checks them by default.

Best for: Writers who want Codex running alongside them as they draft—checking the work, flagging issues, and responding in parallel without interrupting the writing session.

Input sources: Your draft as a file or in a supported review surface, plus any relevant style guides, source documents, or review standards in your workspace.

Output artifact: An annotated draft with inline feedback, flagged issues, and suggested revisions—produced continuously as you write rather than in a single pass at the end.

Setup:

Open your draft in Proof or make it available as a file in the project. Start a Codex session with your workspace context loaded. Give Codex standing instructions for what to monitor and how to respond.

First prompt:

I am writing [describe the piece—type, audience, purpose].

Review step: Read the flagged issues at natural stopping points—the end of a section or session. Decide which to address and which to dismiss. Don’t let the feedback loop interrupt the drafting flow; the value is in the accumulation, not in responding to every flag in real time.

How to compound: After each writing session, add any recurring flags to reviews/writing-checklist.md. Patterns that come up repeatedly are candidates for a standing rule in your preferences file, so Codex checks for them next time.

Best for: Writers and researchers who need to organize source material before drafting.

Input sources: Links, PDFs, past drafts, notes, transcripts.

Output artifact: A structured document with the core argument, supporting evidence organized by claim, counterarguments, and a gap analysis (what is still missing).

First prompt:

Review step: Read the evidence room before drafting. Verify any statistics or quotes you plan to use directly.

How to compound: Save the evidence format as a workflow template. Add a standing note to your context file about your writing voice and recurring themes so Codex calibrates its framing.

Best for: Anyone who processes information better by listening than reading, or who wants to take time away from a screen but stay on top of work.

Input sources: Any written content: drafts, research briefs, meeting summaries, strategy documents, reports, lengthy emails, articles.

Output artifact: An audio file saved to a location accessible from your phone (Dropbox, Drive, etc.).

First prompt:

Review step: Listen on your commute, walk, or wherever you have time away from a screen. Take notes on your phone as things come up. Return to the source material with whatever you noticed.

How to compound: Add a standing instruction to your context file covering your audio preferences—such as speed, file format, naming convention, and preferred save location—so you do not have to specify each time. You can also prompt Codex to convert content automatically at the end of certain workflows: “After generating the weekly metrics report, convert it to audio and save to [location].”

Best for: Anyone responsible for launching a product, feature, or initiative and who has done the thinking in meetings and Slack but has not had time to formalize it.

Input sources: Meeting transcripts, Slack threads, customer notes, a preferred strategy template.

Output artifact: A complete go-to-market plan, structured for human review and agent querying.

First prompt:

Review step: Review in Notion or Proof. Verify that every major claim traces to something in the source material. Anything the model added that was not in your sources should be flagged for your decision.

How to compound: Save the template and the prompt. After each launch, add a retrospective note to your context file about what the plan got right and wrong. Future plans will be calibrated by past ones.

Best for: Anyone responsible for tracking metrics and needing a regular, reliable view across multiple data sources.

Input sources: Analytics (PostHog, Mixpanel, Amplitude), revenue data (Stripe), support volume, social metrics, saved past reports.

Output artifact: A one-page report covering headlines, usage metrics, system health, and follow-up items.

First prompt:

Review step: Verify every number in the report against its source. Don’t use this report as a business source of truth until you have confirmed accuracy column by column. Different definitions and incorrectly matched records can make a report look right when it isn’t.

How to compound: Save each report as a dated file in your outputs/reports/ folder. Over time, Codex can compare reports, identify trends, and flag when something has changed. The folder becomes the working memory of your product.

Best for: Teams where support patterns should feed into product decisions and small fixes.

Input sources: Support platform (Intercom, Zendesk), issue tracker (Linear, GitHub Issues).

Output artifact: A deduplicated list of issues with suggested priority, plus small issues ready to hand off for fixes.

First prompt:

Review step: Review the issue list before anything goes into the tracker. Confirm deduplication is accurate—support tickets often describe the same underlying problem in different words.

How to compound: After each session, add a note about recurring issue types so Codex can categorize faster next time. Build a persistent list of known issues so deduplication improves over time.

Best for: Anyone who needs to make a small, well-scoped change to a codebase—such as copy updates, configuration changes, or content edits—without deep engineering knowledge.

Input sources: The relevant files or repository, and a clear description of the change.

Output artifact: A pull request (PR) that is reviewer-friendly and doesn’t touch anything outside the intended scope.

First prompt:

Review step: Review the Codex preview before the PR is opened. Review the PR itself in GitHub or your code review tool. Ask a technical colleague to approve before merging if you are uncertain.

How to compound: Save a template of your preferred PR format. After each PR, add a note about anything that requires correction so future PRs avoid the same issue.

Best for: Anyone doing outbound recruiting for a role with a specific background profile.

Input sources: LinkedIn, Twitter/X, company websites, alumni databases, public professional networks.

Output artifact: A list of candidates with background summaries and contact information or connection points.

First prompt:

Review step: Review each candidate before any outreach. Verify that the background summaries are accurate by checking the linked profiles. Don’t send any outreach through Codex.

How to compound: Save the role profile as a template. After a successful hire, document what the actual background looked like versus the initial profile to calibrate future searches.

Best for: Leaders and operators who need to compress OKR planning, quarterly planning, or strategic reviews from days to hours.

Input sources: Past planning documents, meeting transcripts, leadership context notes, relevant metrics.

Output artifact: A draft plan or OKR set, structured for review and iteration.

First prompt:

Review step: Review in Notion or Proof. Before sharing with leadership or the team, confirm that every major commitment traces to a decision that was actually made.

How to compound: After each planning cycle, add a retrospective to your context file. Did the goals prove achievable? What was missing from the original plan? Future planning sessions will be informed by past ones.

Best for: Anyone who wants to use Codex to support skill-building, practice, or self-directed learning.

Input sources: External APIs, files, structured practice materials, your own notes.

Output artifact: A custom interactive tool—like a tutor, a quiz, or a practice environment—built for your learning goal.

Example:

A musician wants to practice chord identification. They connect a MIDI keyboard and describe what they want, and Codex builds a small app that listens to what they play, identifies the chord, and tracks progress over time.

First prompt:

Review step: Try the tool on real practice material before committing to it. Verify it is actually testing what you intended.

How to compound: After each practice session, ask Codex to update the tool based on what you found most and least useful. The tool improves as your needs become clearer.

Best for: Editorial planning, product ideas, customer requests, research leads, or any area where useful signals arrive gradually.

Input sources: Approved channels and documents, public sources, existing coverage, and a scoring rubric.

Output artifact: A maintained backlog with evidence, status, duplicates, and a smallest next action.

First prompt:

Review step: Check source quality, duplicate ideas, and criteria changing over time. A scan that finds nothing useful should say so rather than padding the bank.

How to compound: Run collection manually first. Turn it into a skill or scheduled scan only after the data fields, qualification rules, and review process hold up..

Best for: Reports, roadmaps, source rooms, dashboards, and review queues that have become awkward to operate as documents.

Input sources: A proven manual workflow, the current artifact and source data, intended users, required actions, access rules, and an owner.

Output artifact: A saved Site version for review, followed by a deployment only after approval.

First prompt:

Review step: Test it with real data and a real task. Check the source changes, stored data, access settings, and selected saved version before deployment.

How to compound: Add controls only when they support a repeated action. Record ownership, data sources, failure behavior, and a plan for when to retire the Site.

Best for: Public pages, knowledge bases, recurring reports, or resource lists that need regular updates but should never change automatically.

Input sources: The current artifact, approved sources, clear rules for what warrants a change, and a dated record of past decisions.

Output artifact: A list of suggested changes and supporting evidence.

First prompt:

Review step: Accept or reject each proposal in the artifact’s intended destination. Verify links, dates, claims, and rendered appearance before publication.

How to compound: Record what you accept and reject. The system can learn from these choices, but it should never publish without approval.

Operating Codex well is management work. You evaluate talent (which prompts, agents, and workflows to trust), set vision (what to point Codex at, and what “done” should look like), exercise taste (catching output that is technically correct but wrong for the moment), and know when to let be or take the wheel.

Give Codex an outcome. Describe what you want to end up with, not how to get there. “Build a research brief on [topic] with these sources and this structure” produces better results than “First search Slack, then search Notion, then...”

Ask for a plan before long-running work. For any task that will take more than a few minutes or touch multiple systems, ask Codex to explain what it’s about to do before it starts. This catches misunderstandings early and gives you a chance to redirect it before it gets too far along.

Ask Codex what it needs before it starts. For complex tasks, a short briefing prompt saves time:

Three questions to ask before approving any significant output:

These questions surface the judgment calls the model made, the options it dismissed, and the places most likely to contain errors.

Common failure modes and how to handle them:

The human ownership standard: Codex can touch any artifact in your workflow, but a human must direct the work, stand behind the output, and be able to discuss any specific decision in it. If someone asks you about a bullet point in a document Codex drafted, you should be able to answer. An AI-drafted document is fine—expected, even—but if someone talks it through with you and it’s clear you have no idea what’s in it, that’s a problem.

Individual Codex workflows compound over time. Team workflows compound faster but require coordination.

What changes when a team uses Codex

Teams build trust in agents through the humans who operate them. When a colleague receives a document or plan that Codex drafted, they trust it to the degree they trust the person who shared it.

Infrastructure that makes team Codex work

Shared review surfaces. A shared document review tool (Proof, Notion, Google Docs) makes agent-generated documents easier to inspect and comment on than outputs reviewed only inside Codex.

Explicit handoffs. Subagents report back to the task that created them, and scheduled thread work stays in its own conversation. Separate threads do not share updates automatically. When one thread needs another’s work, send a clear handoff and save the result in a shared file or review tool. Give each workflow an owner and approval rules.

Shared skills and plugins. A maintained skill can package a team’s review standards; a plugin can distribute a workflow together with the apps or MCP connections it needs. Teams should inspect those dependencies and permissions before asking everyone to install the same setup.

Shared, agent-readable documentation. Plans, strategy documents, and operational guides written for both human and agent readers become shared infrastructure. Any team member—or any team member’s agent—can query them for specific information without interrupting the author.

Explicit ownership. Every persistent workflow needs a named owner. That person is responsible for monitoring output quality, updating the workflow when it breaks, and retiring it when it’s no longer useful. Automation degrades without ownership.

Day 1: Connect and inspect. Install the Codex desktop app and open one folder you are comfortable using as a project. Connect one or two sources that support a real job you already do. Run the workflow-discovery prompt from Part 2. Don’t build or automate anything yet.

Day 2: Let Codex interview you. Have it propose the workspace structure and a short root AGENTS.md, plus only the supporting context, preference, status, source-map, workflow, and review files you need. Approve the plan before it changes the folder.

Day 3: Run three one-off tasks. Choose one summary task, one research brief, and one draft or plan. Use the prompt patterns from Level 1. Review each output carefully and note where Codex got things right and where it needed correction.

Day 4: Build your first repeatable workflow. Take the most useful task from Day 3 and fill out the workflow canvas from Level 3. Save it to workflows/ in your workspace. Run it again with different inputs and verify the output before you consider scheduling it.

Day 5: Add review rules. Create reviews/data-checklist.md, reviews/writing-checklist.md, and reviews/comms-checklist.md. Start each one with five checks based on what you noticed during Days 3 and 4. These will grow over time.

Day 6: Turn one workflow into a reusable artifact. Document the prompt, inputs, output format, review step, and known edge cases. Keep it as a workflow file while the process is changing; turn it into a skill when the procedure is stable enough to reuse. Browse the plugin directory before packaging a common workflow from scratch.

Day 7: Compound. Run the compounding prompt at the end of your Codex session:

Review Codex’s suggestions and implement the one that would save the most time over the next month.

Start today: Open one safe folder in Codex. Choose one job you already know how to do. Give the agent the sources, define the artifact, and tell it how you will check the work. Run it well once; let the rest grow from there.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter.