How to Organize the Codex Desktop App: Projects, Chats, Files, and AI Agents

I was starting my Growth Academy Community AI Training the other day when someone mentioned how overwhelming it is to keep up with all of their Codex chats.

This is not the first time I have heard this in real time.

Millions of people are now using Codex every week, and maybe you are one of the people who feels the same way.

You are relying more on Codex to get work done, but you are also getting tired of trying to find where your stuff is.

Was it in a chat?

When should you use a project?

What folder should you attach to that project?

Should you continue an old chat or start a new one?

If you are totally new to setting up Codex, watch my OpenAI Codex for Business Owners: Day 1 Training first. I break down the beginning of the setup there.

But if you have been using Codex for a bit, your chats and projects are adding up, and you feel like you are drowning, this is the guide for you.

When this same person asked me, "How do you keep all of this organized?" my answer was:

"I don't. At least not in the Codex harness."

So first, we need to understand that this organization should happen in phases. We also need to understand what the harness actually is.

The Harness Is Just a Harness

The harness is the visual interface you use to work with Codex. It gives you a prettier, easier place to open chats, start tasks, connect projects, attach folders, and review what Codex is doing.

If you are still sorting out the difference between ChatGPT and an agent that can work inside your files and systems, start with my plain-English guide to what Codex is.

But your actual business work is not magically living inside that pretty sidebar.

For most people, the files Codex is working with live somewhere else: in local folders on the computer, inside a repository, or in connected systems such as Google Drive, Notion, a CRM, or a website.

Even if you organize your harness, all you have done is make it easier to find things.

That does not guarantee that your important work is backed up. It does not guarantee that your agent instructions are current. It does not guarantee that your business knowledge can be recovered.

If your computer were run over by a truck tomorrow, organizing the Codex harness would not save important work that only existed in an unprotected local folder or one forgotten chat.

So first, you need to make sure your local files are organized and protected.

But before we go there, the real answer is that you need more than to organize your Codex app.

You need to organize your business operating system in a place that is agent-friendly. That is the larger idea behind my I7 Method for building an agent-ready business.

I am going to show you how I organize mine and why I use GitHub.

But first, we will start with a simple prompt that can make it easier to find things inside Codex now.

Then we will move toward the longer-term solution.

Quick Answer: How to Organize Codex

The best way to organize Codex is to run a read-only audit first. Use a project for continuing work that shares files and instructions, and use a separate chat for each specific outcome. Organize around durable business outcomes, clients, and permission boundaries, not chronology. Let Codex recommend the structure, then create the projects yourself and approve any file changes separately.

What a Project in the Codex Harness Is Actually For

A project is a container for related work. It keeps a continuing area of work, its chats, its folders, and its shared instructions together so Codex starts each task with the right context.

OpenAI's current Projects and chats documentation says to create a project when the work will continue over time, produce more than one output, or depend on the same files and sources. A self-contained task that does not need shared project context can remain a standalone chat.

For a business owner, that means:

• Marketing and Content can be a project because many related tasks use the same brand files, website, voice, and approval rules.
• Prepare Thursday's newsletter draft should be one chat inside that project because it has one specific outcome.
• Compare two microphones for my next live training can be a standalone chat if it does not need access to company files or continuing instructions.

A local project can connect Codex to one or more folders on your computer. Its primary folder becomes the default place for new chats and for discovering project guidance such as AGENTS.md.

But a project is still part of the harness. It is a useful context and navigation boundary. It is not automatically your backup, your version history, your company memory, or your agent accountability system.

That is why business owners need both levels of organization:

• Organize the harness so you and Codex can find the right chats, projects, and folders quickly.
• Organize the infrastructure behind the harness so your company controls the files, instructions, permissions, history, and evidence even if the interface or AI tool changes.

What Is a New Chat in Codex?

A new chat is a fresh conversation for one distinct task or outcome. Think of the chat as the working conversation and the project as the shared room that conversation happens inside.

If you start a new chat inside a project, that chat can still use the project's connected folders and shared instructions. You are not starting the business context from zero. You are giving the next outcome its own clean conversation.

For example, inside a Marketing and Content project, you might have separate chats for:

• drafting this week's newsletter;
• turning a training transcript into a blog article;
• reviewing website conversion copy; and
• planning next month's editorial calendar.

Those tasks belong to the same continuing area of work, but they do not need to be mixed into one endless transcript.

Can You Put Different Things in One Chat?

Yes. Codex will not stop you from asking for a newsletter draft, then a landing-page review, then a spreadsheet analysis in the same chat. The better question is whether those requests are moving the same outcome forward.

Keeping work in the same chat can help when:

• each request is the next step in the same deliverable;
• you are drafting, revising, checking, and finalizing one piece of work;
• earlier decisions and corrections still matter to the next step; or
• the work uses the same owner, files, permissions, and approval path.

The benefits are convenience and continuity. You do not have to repeat every decision, and the reasoning behind the current draft remains visible.

But mixing unrelated work in one chat creates real disadvantages:

• the transcript becomes harder for you to scan and search;
• old instructions can conflict with what you ask for later;
• irrelevant context can follow the new task;
• decisions and final outputs become harder to hand off or audit; and
• work for different clients, teams, or permission levels can become dangerously easy to mix.

My rule is simple: continue the same chat when you are continuing the same outcome. Start a new chat when the outcome changes.

Revising a newsletter draft belongs in the newsletter chat. Auditing an invoice does not—even if both tasks happen on the same afternoon.

Can You Use Only Chats and Skip Projects?

Yes. You do not need a project for every Codex task. Standalone chats work well for one-time questions, quick research, experiments, and self-contained work that does not rely on shared company files or instructions.

Chats alone can also feel perfectly manageable when you are new to Codex and only have a few of them. The problem appears as recurring work accumulates. You begin recreating context, attaching the same folders, repeating the same rules, and searching through a chronological list for work that belongs to a continuing business function.

That is the moment when chats alone stop being a lightweight solution and chronology starts becoming your architecture.

Use this decision rule:

• Continue the current chat: same outcome, next step.
• Start a new chat inside the same project: new outcome, same shared files, instructions, or business function.
• Start a standalone chat: self-contained task with no continuing shared context.
• Create a new project: continuing area of work that will contain multiple related chats or needs its own folders, instructions, owner, client boundary, or permission boundary.

Projects are not a replacement for chats. A well-organized project usually contains several focused chats. And neither one replaces the durable business infrastructure behind the interface.

Use This Prompt Before You Reorganize Anything

The first version of this request is too vague:

Clean up my Codex. Organize my chats and projects and delete anything I do not need.

That prompt gives the agent too much authority before it understands the business meaning behind your files.

Use this version instead:

Audit my current Codex setup and suggest a better organization for my projects, chats, attached folders, and durable agent instructions.

Keep this first pass read-only. Do not create, rename, move, merge, archive, detach, or delete anything.

Show me:

1. The projects and major areas of work you can directly observe.
2. Which chats appear related to each continuing business outcome.
3. Which recurring work should become a project and why.
4. Which one-time tasks should remain standalone chats.
5. Which folders each proposed project should use and which folder should be primary.
6. Which clients, companies, systems, and permission boundaries must remain separate.
7. Which instructions or business decisions appear to exist only inside old chats.
8. A proposed before-and-after project map.
9. The exact setup steps I must complete manually in the Codex harness.
10. Anything you cannot verify from the evidence you can access.

Separate observed facts from recommendations and unknowns. Wait for my approval before making any change to local files.

What This Prompt Can and Cannot Do

This prompt can give you a useful map of the work Codex can actually see. It can recommend which projects you should create, which chats belong together, which folders should be attached, and where your current structure is creating risk.

It does not magically finish the reorganization inside the harness.

Treat project creation and folder attachment as a separate setup step. After you approve the plan, you still create or edit each project in the Projects view, choose its folders and primary folder, and then start or move forward with focused chats inside it. The audit should tell you exactly what to create. It should not pretend the new projects already exist.

In plain English: Codex can recommend the project, but this read-only audit cannot create the project for you.

The same boundary applies to local files. A read-only audit can recommend changes. It cannot move, merge, rename, archive, or delete files unless you later authorize those specific actions.

What My Own Audit Taught Me

When I ran this process on my own setup, Codex found 3,751 indexed threads, 148 date-based task folders, approximately 26 GB of task storage, and 138 accumulated project-trust entries.

Why does that matter?

Not because those numbers prove that I should delete thousands of chats. They do not. They showed that my environment was excellent at recording when work happened and much weaker at showing where that work belonged in the business.

That is the pattern I now look for when helping established business owners organize Codex.

The problem is not necessarily too many chats.

The problem is allowing chronology to become architecture.

This article is based on that read-only audit, my experience helping more than 100 business owners set up and use Codex, a full 72-minute Growth Academy Community AI Training, and the operating practices I use in my own company and in client implementations. Codex assisted with drafting and editing. I supplied the first-hand evidence, retained editorial control, and approved the final article for publication.

The Codex project guidance was checked against OpenAI's Projects and chats documentation, and the explanation of AGENTS.md was checked against OpenAI's agent-configuration documentation. The content-quality approach was checked against Google Search Central's people-first content guidance.

Why Codex Becomes Disorganized So Quickly

Most business owners do not begin with an AI infrastructure plan.

They begin with one useful conversation.

Then they create a chat for a proposal, another for a website update, another for meeting follow-up, and another for the agent they suddenly realize they can build. A client request arrives, so they open a new task. An instruction improves inside that task, but the improvement never reaches the original agent file.

The owner is still productive. The individual tasks may even be excellent.

But the structure underneath the work starts becoming harder to trust.

Common warning signs include:

• several projects with nearly identical names;
• multiple versions of the same agent;
• important business rules that exist only inside old conversations;
• client work mixed with internal company work;
• uncertainty about which instruction file is current;
• agents that share data without a documented reason;
• completed actions without evidence that the intended outcome occurred; and
• no clear place for the next chat, file, decision, or improvement.

This is why I organize Codex in two phases.

Phase 1 makes today's Codex workspace understandable. Phase 2 makes the company's instructions, approvals, evidence, and operating history durable.

Phase 1: Audit and Organize the Codex Harness

The first phase is about clarity inside the environment you already use.

Do not begin with a cleanup command. Begin with an inspection request.

What a Useful Before-and-After Map Looks Like

Before the audit, an owner's sidebar may mostly reflect chronology:

• August 12 Training
• Website Fixes
• Follow Up With Client
• New Agent Test
• several untitled chats whose outcomes are impossible to recognize

After the audit, the proposed structure should reflect durable business areas:

• Marketing and Content for the website, newsletter, training, and reusable brand instructions
• Sales and Follow-Up for pipeline reviews, proposals, renewal follow-up, and sales rules
• Company Operations for internal policies, recurring meetings, and operating decisions
• separate client projects where data, ownership, or permissions must not cross
• one clearly named chat for each specific deliverable inside those projects

Codex can propose that map. You decide whether the business meaning is correct, create or edit the projects in the harness, and approve any later file changes separately.

Organize the Local Files Behind the Harness

Once Codex shows you what it can see, look at the local files and folders the projects point to.

A Codex project can help limit and organize the context available to a task. It is not automatically a backup system, a source-of-truth decision, or proof that the folder attached to it is the correct long-term home.

I want durable business work to have stable locations based on the business, client, or continuing outcome. I do not want the only usable copy of an important agent living in a date-named task folder that nobody will recognize three months from now.

Before moving anything, identify:

• which folders contain durable business or client work;
• which folders are temporary task workspaces;
• which files are source material versus generated outputs;
• which repository or system is authoritative;
• which work is backed up and recoverable;
• which client and permission boundaries must remain separate; and
• which local-only files would disappear if the computer were lost or damaged.

The harness helps you reach the work. Your file structure, repositories, backups, and business systems determine whether the work can survive. If you have not made that storage decision yet, use this guide to decide where Codex work should live.

When a Business Owner Should Create a Codex Project

A project should represent a durable area of work, not a momentary idea.

I usually consider a separate project when the work:

• continues over time;
• produces multiple related outputs;
• repeatedly uses the same source material or instructions;
• belongs to one client, company, owner, or permission boundary;
• supports one continuing business outcome; or
• contains agents that need the same operating context.

A practical business structure might include:

• Company Operations
• Sales and Follow-Up
• Marketing and Content
• Finance and Reporting
• Agent Development
• Client A
• Client B

The individual conversations inside those projects should remain narrow.

A project carries durable context. A chat carries one task and outcome.

For example, Sales and Follow-Up may be a durable project. Draft the renewal follow-up for Tuesday's call is a task conversation inside it.

What Must Remain Separate

Do not combine work merely because the workflows look similar.

Two clients may use nearly identical meeting agents. The underlying templates may overlap. Their data, permissions, brand voice, contracts, owners, and expected outcomes may still require complete separation.

The same principle applies inside one company. A sales agent and a finance agent may both need revenue information. That does not mean they should receive the same access or be allowed to perform the same actions.

This becomes even more important when several employees have their own agents. I explain the rollout order and governance rules in ChatGPT Work for Teams: Roll It Out Without the Chaos.

Before approving a merge, confirm five things:

1. The same owner controls both areas.
2. The intended business outcome is the same.
3. The instructions and current version are verified.
4. The evidence and source systems are compatible.
5. The permissions, privacy obligations, and approval rules allow consolidation.

If any answer is unknown, leave the items separate and add the decision to the review list.

Implement the Cleanup Reversibly

After reviewing the audit, approve a specific plan rather than granting permission to reorganize everything.

The implementation plan should include:

• the exact projects, chats, and folders included;
• what will move and where;
• what will remain unchanged;
• verified duplicates versus merely similar items;
• unresolved decisions;
• client and system boundaries;
• a before-and-after map; and
• a rollback note for every material change.

Do not delete source files during the first pass. Do not move credentials or sensitive private records into a new location. Do not assume the newest file is the authoritative file. Dates are evidence of recency, not proof of approval.

For many owners, the first read-only inspection and structure decision can be completed in under an hour. That does not mean every business system will be organized or integrated in an hour. It means you can identify the visible chaos, the highest-risk conflicts, and the structure you want before authorizing changes.

Create a Routing Guide So the Mess Does Not Return

An organized sidebar will become disorganized again if nobody knows where future work belongs.

Ask Codex to create a short routing guide that answers:

• When should I continue the current chat?
• When should I start a new chat inside the same project?
• When does recurring work deserve its own project?
• Where do new clients and their private data belong?
• Where should approved improvements to an agent be saved?
• What should never exist only inside a conversation?
• Which source wins when two instructions disagree?
• What must be recorded when an agent finishes work?

The goal is not perfect taxonomy. The goal is to make the next decision obvious.

What the Audit Reveals Beyond Organization

A Codex audit often exposes an operating problem that folders alone cannot fix.

If Codex finds four versions of the same agent, that is a version-control problem.

If pricing rules live only in an old chat, that is a knowledge-management problem.

If two employees maintain conflicting instructions, that is an ownership problem.

If an approved agent improvement never reaches the other workflows that depend on it, that is a synchronization problem.

If nobody can distinguish drafted, approved, sent, and verified, that is a status and evidence problem.

If multiple agents can change the same system without a work record, that is an accountability problem.

This is the limit of Phase 1. A cleaner Codex harness improves current work, but it does not by itself create durable company infrastructure.

Phase 2: Build a Private Agent Homebase™

Once agents begin doing real work across sales, marketing, finance, operations, and client delivery, the company needs a layer underneath the individual AI tools.

I call that layer Agent Homebase™.

Mine lives in a private, company-controlled GitHub repository. GitHub provides useful version history and rollback, but a repository alone is not an operating system. A reliable Homebase also needs rules for what agents read, trust, change, verify, and write back. If GitHub still feels overly technical, I explain why GitHub gives Codex more leverage in a separate guide.

A first Agent Homebase™ can contain:

• a clear start-here file;
• canonical company and client context;
• approved agent instructions;
• source-of-truth maps;
• ownership and access boundaries;
• approval gates for sending, publishing, spending, deleting, and changing live systems;
• agent work sessions and activity logs;
• evidence and action receipts;
• current handoffs and next actions;
• version history and rollback information; and
• a write-back rule for approved learning.

You do not need to document the entire company on day one. Start with the rules and knowledge that would create the most risk if they were lost, duplicated, or misunderstood.

How Agent Homebase™ Reduces Model Dependency

This structure also reduces one of the risks business owners rarely consider when they first begin using AI: becoming dependent on one model, one interface, or one very long conversation.

If your instructions, decisions, examples, approvals, and work history exist only inside one model's chats, changing tools means rebuilding context from memory. If that model changes, a feature disappears, pricing increases, or the account becomes unavailable, part of the company's operating knowledge can become difficult to recover or reuse.

Agent Homebase™ reduces that dependency by keeping the durable business layer outside the model. Each approved agent can read from the same company-controlled sources, follow the same permission rules, review the same action history, and leave a handoff for whoever or whatever works next.

That creates four practical advantages:

• Context portability: important company knowledge can be supplied to another approved model without reconstructing it from old chats.
• Operational continuity: a different agent can continue from the recorded state, evidence, and next actions rather than starting over.
• Model comparison: the company can test more than one model against the same instructions and source material instead of confusing better context with better model performance.
• Vendor leverage: the business can choose the model that best fits a particular task, cost, security requirement, or capability without moving its entire institutional memory.

This does not make every model interchangeable. Models interpret instructions differently, tool access varies, and vendor-specific configurations may still need adaptation and testing. Agent Homebase™ does not eliminate model dependency. It reduces the cost and risk of changing models because the company's memory and operating rules do not have to leave with the model.

The more of your operating knowledge you keep in clear, inspectable, company-controlled files, the less your business depends on any AI provider remembering who you are.

Official OpenAI documentation states that Codex reads AGENTS.md files before beginning work and can layer global guidance with project-specific instructions. That makes AGENTS.md useful for persistent operating expectations. It does not remove the need to control sources, permissions, approvals, evidence, or business state. See OpenAI's guide to custom instructions with AGENTS.md.

What Agent Accountability Looks Like Inside My Own Company

At Growth Academy, we do not treat agents as a loose collection of smart chats.

We work with them as an organization.

For meaningful work, the agent starts a visible work session tied to an assignment and business project. Actions are recorded when they happen. The record identifies who or what performed the work, why it ran, which systems or files it touched, the outcome, and the evidence supporting that outcome. The session closes with a handoff, blockers, and next actions so another person or agent can continue without reconstructing the story from scattered conversations.

We also preserve status distinctions that are easy to blur when AI work moves quickly. Drafted is not approved. Approved is not sent. Sent is not received or acted on. Published is not necessarily deployed. Deployed is not necessarily live-verified.

I learned the importance of this through an internal agent-fleet audit. At the time of that audit, only six of 30 scheduled agents were writing to the central activity ledger, while 23 were performing meaningful work without a central trace. Their work was not necessarily bad. The operating system around the work was incomplete.

That finding changed the rule: every meaningful action must create one record at the time it happens. Failed runs are recorded too. Each record receives a permanent identifier so a later action, error, or correction can be traced back to what caused it.

This is not bureaucracy for its own sake. It is how we prevent two agents from duplicating work, how we see when one agent changed a rule another agent depends on, and how we diagnose a failure months later without relying on somebody's memory.

How We Applied This Inside an Established Consulting Group

We have also installed this model for an established consulting group building an agent workforce across executive leadership, finance, client service, marketing, and business development.

Its private Agent Homebase™ now includes an agent registry, a current event log, handoffs, approval records, project files, and explicit startup instructions. Agents are mapped to a department, an accountable leader, a day-to-day operator, and an executive approval gate. The fleet map gives every agent a defined log destination, and the operating rules require every meaningful action to be written to the shared event history when it happens.

That does not mean every agent on the roadmap is already live. Some are operating, some are being tested, some are ready for controlled implementation, and others are still planned. Keeping those states separate is part of the system.

The important change is that the company is no longer asking only, "What agents should we build?" It can also ask:

• Who owns this agent?
• What is it allowed to do?
• Where does its work get recorded?
• What requires human approval?
• What happened during its last run?
• What evidence supports the result?
• What should the next employee or agent know before continuing?

That is the point where an AI initiative begins to operate like part of the business instead of a collection of experiments.

Codex Should Use the Homebase, Not Be the Homebase

Codex is where work can happen.

Agent Homebase™ is where the company preserves the rules, context, evidence, and accountability surrounding that work.

Models will change. Interfaces will change. Pricing, capabilities, and security requirements may change. A company should be able to use a different AI tool for a particular workflow without rebuilding its institutional memory.

Your sales process belongs to your company.

Your pricing rules belong to your company.

Your client knowledge belongs to your company.

Your agent instructions and audit history belong to your company.

The model can use that knowledge. It should not be the only place that knowledge exists.

How to Verify That the System Is Working

A better folder structure is visible immediately. A dependable AI operating system has a higher standard.

For any meaningful agent action, you should be able to answer:

• Which agent or person performed the work?
• Which instructions and version were active?
• What source information was used?
• What was created or changed?
• Did the action require human approval?
• Is there a receipt showing the action ran?
• Is there separate evidence that the intended result occurred?
• Where was the new decision or learning written back?
• How can the change be reversed?

An email marked sent does not prove the recipient replied. An invoice created does not prove it was paid. A deployment command that succeeded does not prove the public page is correct.

Receipts prove actions. Verification proves outcomes.

That distinction becomes more important as the number of agents grows. A small company may eventually run dozens of narrowly scoped agents; here is why a five-person business could run 100 AI agents without becoming a 100-person company.

Frequently Asked Questions

Should I Delete Old Codex Chats?

Not during the first organization pass. Inventory and classify them first. Archive or delete only after confirming that important instructions, decisions, source evidence, and client records have durable homes.

When Should I Start a New Chat Instead of a New Project?

Continue the current chat when you are moving the same outcome forward. Start a new chat for a distinct outcome that can use an existing project's shared context. Create a new project when the work is ongoing, will contain multiple related chats, repeatedly uses the same files or instructions, or requires its own owner, client, data, or permission boundary.

Can I Put Several Tasks in One Codex Chat?

Yes, but keep them together only when they are steps toward the same outcome. Combining unrelated deliverables makes the transcript harder to search, introduces irrelevant or conflicting instructions, complicates handoffs, and increases the risk of mixing clients or permission boundaries.

Can I Use Codex Chats Without Creating Projects?

Yes. Standalone chats are appropriate for one-time, self-contained work. Create a project when several chats need the same folders, instructions, sources, or continuing business context. Projects are optional organizational containers, not a requirement for every conversation.

Does Agent Homebase™ Eliminate Model Dependency?

No. Models have different capabilities, tool access, security controls, and instruction behavior. Agent Homebase™ reduces dependency by keeping durable company context, rules, decisions, logs, evidence, and handoffs outside any single model. That makes it easier to test or change approved models without rebuilding the company's operating memory from scattered chats.

Where Should Permanent Codex Instructions Live?

Use AGENTS.md for persistent Codex instructions at the appropriate global or project scope, following OpenAI's documented discovery and precedence behavior. Keep canonical business rules, approvals, evidence, and ownership records in a company-controlled source of truth rather than relying on one conversation.

Do I Need GitHub to Organize Codex?

No. You can improve a Codex workspace without GitHub. I use a private GitHub repository for Agent Homebase™ because version history, review, and rollback are valuable when multiple people and agents change instructions. The larger requirement is company control and disciplined write-back, not a specific vendor.

Can Codex Organize Everything Automatically?

Codex can inspect accessible evidence, identify patterns, and propose a structure. It cannot independently know every contractual, political, security, or ownership reason that similar work remains separate. Keep the first pass read-only and require owner approval for material changes.

The Practical Next Step

If your Codex environment is already crowded, begin with the audit prompt in this article.

Do not begin by deleting.

Ask for an evidence-based map. Review what Codex observed, inferred, and could not verify. Approve only the reversible changes you understand. Then move the company knowledge that matters into a durable Homebase.

If you want done-with-you help, Growth Academy's AI agent implementation helps established business owners identify valuable workflows, organize operating context, build agents, and install appropriate approval and verification rules.

If you want to build independently, the 100+ Codex Skills Dashboard provides reusable skills and prompts for common business workflows.

About the Author

Shanee Moret is the founder of Growth Academy Global. She built an organic LinkedIn audience of nearly one million followers, publishes a LinkedIn newsletter read by more than 267,000 subscribers, and has welcomed more than 50,000 attendees to her trainings. Her work has been featured in Forbes and Entrepreneur, and more than 500 business owners have graduated from Growth Academy programs.

Today, Shanee helps established business owners implement Codex and AI agents inside real sales, marketing, finance, operations, client-delivery, and reporting workflows. Her recommendations in this article come from more than 100 business-owner Codex setups, live community AI trainings, a documented read-only audit of her own working environment, and hands-on Agent Homebase™ implementations for established companies building multi-agent teams.

Connect with Shanee on LinkedIn.

Primary Sources

• Growth Academy Community AI Training, full 72-minute transcript, recorded August 12, 2026.
• Growth Academy internal agent-fleet audit and Action Ledger operating standard, reviewed August 26, 2026.
• Private client Agent Homebase™ operating rules, agent roadmap, and fleet map, reviewed August 26, 2026. Client-identifying details are intentionally omitted.
• OpenAI: Codex is becoming a productivity tool for everyone
• Google Search Central: Creating helpful, reliable, people-first content
• OpenAI documentation: Projects and chats
• OpenAI documentation: AGENTS.md custom instructions
• OpenAI documentation: Codex app