Support organization-scoped agents with isolated memory, skills, and project context

Summary

Codex currently feels centered around one primary agent experience. As users connect more repositories, SSH hosts, teams, and long-running projects, a single agent can accumulate too much unrelated context over time.

It would be helpful to support multiple scoped agents, organized under higher-level organizations or companies, with separate memory, files, skills, and project context.

Problem

A single long-lived agent can become overloaded when it is used across many unrelated areas of work. Context from one project, company, server, or workflow may become irrelevant or even harmful when working on another.

For example, a user may have:

1. Multiple organizations, companies, or clients.
2. Several projects per organization.
3. Different coding standards, deployment workflows, credentials, and operational assumptions.
4. Specialized agents for backend, frontend, infrastructure, QA, data, or support.
5. Shared organization-level knowledge that should not leak into unrelated organizations.

Without stronger separation, the agent has to remember too much and the user has to keep correcting scope manually.

Feature request

Add first-class support for a hierarchy such as:

Organization / Company
  -> Agent
      -> Projects / repositories / SSH hosts / memories / skills

Each organization could have shared context, while each agent inside that organization could have its own specialized memory, skills, files, and working scope.

Suggested design

• Allow users to create multiple organizations or workspaces.
• Allow each organization to contain multiple agents.
• Give each agent isolated memory, skills, files, preferences, and project access.
• Support optional shared organization-level memory for common standards and workflows.
• Let agents communicate or delegate tasks to each other when explicitly allowed.
• Make the active organization and agent visible in every conversation.
• Allow moving or copying selected memories between agents when needed.
• Support per-agent permissions for repositories, SSH hosts, tools, and approval policies.

Example use cases

• Organization A has separate agents for backend, frontend, infrastructure, and QA.
• Organization B has a different set of agents with unrelated repositories and standards.
• A personal workspace has experimental agents that do not pollute professional memory.
• An infrastructure agent can know deployment procedures without exposing that context to unrelated projects.
• A code-review agent can keep review preferences separate from implementation agents.

Security and UX safeguards

• Memories should not cross organization boundaries unless the user explicitly moves or shares them.
• Tool access should be scoped per organization and per agent.
• The UI should clearly show which organization and agent are active.
• Export, archive, and reset options should exist for individual agents.
• Users should be able to inspect what memory or files belong to each agent.

Expected benefit

This would make Codex more scalable for long-term professional use. It would reduce context pollution, improve agent specialization, and make Codex safer and more predictable across multiple organizations, projects, and environments.

Suggested labels, if available: enhancement, agents, memory, skills, workspaces, organizations

Redaction check

This request uses generic organization and project examples only. It does not include real company names, private repository names, server names, credentials, internal paths, or client-specific information.