[RFC] Why Doesn’t Codex Have a Social Network? Building ChatGPT’s Human–Agent Network Effect

Open 💬 0 comments Opened Jul 27, 2026 by skiyo

Summary

Codex already connects agents to code, tools, projects, threads, skills, and GitHub.

The missing layer is people.

I would like to propose a social and collaborative layer for Codex: friends, human-first group conversations, shared/public projects, and owner-controlled participation by each person's Codex agent.

The goal is not to turn Codex into another generic messaging app. The opportunity is to create a Human–Agent Social Graph in which:

Humans are the identity, relationship, permission, and accountability layer.
Agents are private delegates owned, invoked, and paid for by humans.
Projects, discussions, research processes, decisions, code changes, and agent contributions become persistent collaborative assets.

A useful design principle would be:

Humans join the room. Agents enter the room by delegation.

---

Why this matters: Codex needs a network effect

AI models are becoming increasingly interchangeable. When a competitor releases a model that is better, faster, or cheaper, users can often switch agent products with relatively little friction.

A user's individual prompts or model preference do not create a strong network effect. Social and collaborative history does.

Over time, a Codex social layer could accumulate:

Trusted collaborators;
Shared project history;
Discussions and decisions;
Human and agent contribution records;
Research and engineering communities;
Reusable conversations and workflows;
Reputation within specific technical domains.

The value of Codex would then become more than:

Model + Tools + Memory + Project Context

It would become:

Personal Agent
+ Project Context
+ Social Graph
+ Collaboration History
+ Reputation

A model can be replaced. A trusted network of people, agents, projects, and shared history cannot be migrated with one click.

Models create capability. People create network effects.

---

Proposed product model

The social layer could contain the following core objects:

| Object | Meaning |
|---|---|
| Human | The identity and accountable principal |
| Personal Agent | A private agent owned by a human |
| Friendship / Follow | A relationship between human accounts |
| Room | A private or public human discussion space |
| Project | Code, files, tasks, threads, decisions, and agent context |
| Shared Thread | A conversation that can be viewed, commented on, or forked |
| Agent Invocation | An explicit request by an owner to bring their agent into a shared space |
| Contribution | A human or agent contribution to a project |
| Permission Grant | Temporary access to selected context, tools, and budget |

The authorization chain should always be:

Human
  → invokes their Agent
  → grants selected context
  → sets permissions and budget
  → reviews or accepts the output

It should never be:

Another user → directly controls my Agent

---

1. Friends and collaborator profiles

Any Codex user could add or follow another user.

A profile could optionally show:

Online, busy, or focus status;
Areas of expertise;
Recent public projects;
Public contributions;
Shared projects;
Whether the user is open to collaboration;
Coarse Codex activity, such as Light / Active / Power User.

Exact token usage should remain private by default because it may reveal spending, work intensity, or confidential project activity.

Users could explicitly choose to publish coarse information such as the number of public tasks completed or active public projects.

---

2. Human-first group conversations

Users could create private or public rooms for discussing a project, research question, or technical problem.

Only human accounts would be room members. Each participant could bring in their own Codex agent when useful.

For example:

@my-codex Review the proposed database schema and list the main risks.

The response should clearly show:

Which human owns the agent;
Which agent or model generated the response;
What shared context it received;
Whether tools were used;
An optional usage estimate;
Whether the owner reviewed or approved the result.

Another participant should not be able to invoke that agent directly. Instead, they could ask:

@Alice Could you ask your Codex to review the security assumptions?

Alice would decide whether to invoke her agent, what context to share, and how much usage to authorize.

This design prevents unauthorized token consumption and ensures every agent action has a responsible human principal.

---

3. Shared and public projects

Projects should remain private by default, but owners could choose from several visibility levels:

Private;
Invite-only;
Workspace-visible;
Public read-only;
Public with comments;
Public with contribution requests;
Maintainer access.

A shared project page could include:

Project description and objectives;
Milestones and current status;
Relevant Codex threads;
Decisions and open questions;
Files and generated artifacts;
Human and agent contribution history;
Linked GitHub repositories, issues, commits, and pull requests;
Agent-generated progress summaries.

GitHub could remain the system of record for code. Codex could become the system of record for the reasoning, conversations, research, and agent activity surrounding that code.

Other users could follow, fork, comment on, or request permission to contribute to a public project. They could also ask their own Codex to independently review it and submit suggestions or a GitHub pull request.

---

4. Shared threads as “pull requests for ideas”

Codex already has useful sharing primitives. The next step could make a shared thread a versioned collaborative artifact rather than only a conversation that others can read.

Recipients could:

Comment on a specific message;
Point out a missing assumption;
Add evidence or citations;
Suggest an alternative implementation;
Fork the thread into their own Codex workspace;
Ask their own Codex to reproduce or challenge the result;
Submit a proposed revision to the original author;
Compare conclusions produced by multiple independently owned agents.

This is especially valuable for academic and research collaboration.

A researcher could share the conversation in which a hypothesis, model, or experiment was developed. Other researchers could identify missing controls, propose alternative models, rerun the analysis, and contribute a revised version.

GitHub manages versions of code. Codex could help manage versions of reasoning, research, and decisions.

---

Recommended MVP

The first version does not need to build a complete social network.

I suggest starting with:

Collaborative rooms built on shared Codex threads

The MVP could support:

Creating a shared room from an existing Codex thread or project;
Inviting other Codex users;
Inline comments on individual messages;
Forking a thread into another user's Codex workspace;
Allowing each participant to invoke only their own agent;
Per-invocation context, permission, and usage controls;
Clear attribution of human and agent contributions;
Linking the room to a GitHub repository, issue, commit, or pull request;
Secret and privacy review before content is shared.

This MVP would validate whether users want to:

Share the process behind their Codex work;
Collaborate around agent-generated output;
Bring multiple independently owned agents into one problem;
Continue projects across organizational boundaries;
Build persistent working relationships inside Codex.

---

Example workflow

Alice is using Codex to design a distributed job scheduler.

Alice creates a collaborative room from the relevant project thread.
Bob comments on the database consistency assumptions.
Carol forks the thread and asks her own Codex to test an alternative architecture.
Carol submits her agent's findings back to the room.
Alice invokes her Codex to compare both designs.
The humans discuss the trade-offs and make the final decision.
Codex creates a linked GitHub issue and implementation plan.
Bob submits a pull request.
The project records the discussion, decision, implementation, and review history.

This is not merely group chat. It is a persistent collaboration graph connecting humans, agents, projects, decisions, and code.

---

Permissions, privacy, and safety

This feature would require strict boundaries.

Agent ownership

Only the owner can invoke an agent;
Usage is charged only to the owner;
Other users may request an invocation but cannot execute it;
Owners can set invocation and room-level usage limits.

Context isolation

An agent receives only explicitly granted context;
Private projects, memory, files, and conversations are never implicitly exposed;
Shared-room context and private-agent context remain separate by default.

Publishing safety

Before publishing a thread or project, Codex should check for:

API keys and credentials;
Environment variables;
Personal information;
Private repository content;
Confidential documents;
Sensitive conversation history;
Private agent memory;
Hidden secrets in Git history.

Auditability

Every agent contribution in a shared space should record:

Agent owner;
Invocation time;
Context scope;
Tool permissions;
Associated project;
Human approval state.

Abuse prevention

The platform would also need blocking, reporting, spam controls, group moderation, rate limits, prompt-injection protections, and enterprise retention policies.

The default principles should be:

Private by default;
Explicitly shared;
Scope-limited;
Reversible;
Auditable;
Owner-controlled.

---

Possible roadmap

Phase 1 — Collaborative threads

Shared rooms;
Inline comments;
Forks;
Privacy review;
GitHub links.

Phase 2 — Social graph

Friends and follows;
Collaborator profiles;
Presence;
Direct messages;
Shared activity.

Phase 3 — Bring Your Own Agent

Owner-only agent invocation;
Agent identity labels;
Context and budget controls;
Multi-agent comparison inside a human conversation.

Phase 4 — Shared projects

Public and private project pages;
Followers;
Contribution requests;
GitHub integration;
Agent-generated project updates.

Phase 5 — Reputation and discovery

Human and agent contribution records;
Expertise discovery;
Research communities;
Project and collaborator recommendations.

In the longer term, a trusted and permissioned human-agent identity layer could also support privacy-preserving discovery of research partners, technical collaborators, contributors, talent, and other meaningful human connections.

---

Success metrics

Possible metrics include:

Percentage of active users joining a collaborative room;
Share-to-comment conversion rate;
Percentage of shared threads that are forked;
Number of multi-human Codex projects;
Number of rooms involving independently owned agents;
Weekly collaborative-project retention;
Percentage of discussions resulting in an issue, commit, pull request, or artifact;
Collaboration-driven user retention;
Privacy-incident and abuse-report rates.

The most important leading indicator may be:

How often does a user's Codex work become more valuable because another human and their independently owned agent participated?

---

Non-goals for the initial version

The initial implementation should not try to become:

A general-purpose social feed;
A replacement for GitHub;
A replacement for Slack or Discord;
A system where autonomous agents freely contact humans;
A mechanism for consuming another person's agent quota;
An open agent marketplace;
A dating or general social-matching product.

The first goal is narrower: make Codex work collaboratively discussable, forkable, attributable, and extendable by multiple humans and the agents they own.

---

Closing thought

The next major step for AI agents may not only be making each individual agent more capable.

It may be connecting humans through the agents they own.

Codex already connects agents to tools. The next step is connecting people through their agents.

View original on GitHub ↗