Feature request: Persistent role agents with memory, schedules, and collaboration

[Yemvis]

Summary

Please add a first-class concept of persistent role agents to Codex: user-created agents with a fixed professional purpose that behave more like ongoing digital employees than temporary chats or task-scoped subagents.

A persistent role agent would own a function over time. It would have its own identity, instructions, memory, permissions, integrations, automations, work queue, and collaboration rules.

Examples:

• Company Legal Counsel
• Finance Controller
• Operations Manager
• Executive Assistant
• Sales Analyst
• Research Specialist

The goal is to let users build a small, inspectable AI organization inside Codex.

Problem

Codex currently has useful primitives for conversations, skills, profiles, subagents, tools, and scheduled work. However, users still need to repeatedly reconstruct a specialist's:

• role and system instructions;
• long-term context;
• app and tool access;
• permission boundaries;
• recurring tasks and monitors;
• reporting expectations;
• relationship with other agents.

A temporary subagent can execute a bounded task, and a persistent conversation can preserve one thread. Neither abstraction fully represents an agent that owns an ongoing responsibility.

For example, a company's legal function is not one conversation or one delegated task. It is a continuing responsibility involving case history, deadlines, inbox monitoring, court updates, recurring reviews, draft preparation, escalation, and coordination with finance and leadership.

Proposed capability

Each persistent role agent should have:

1. Stable identity and mission

• Name and professional role
• Fixed system prompt / mission
• Operating instructions
• Definition of responsibility and non-responsibility
• Configurable model and reasoning level
• Visible identity whenever the agent is active

2. Isolated persistent memory

• Its own durable memory and conversation history
• A role-specific knowledge base
• Explicit boundaries between private, shared, project, and organization memory
• User controls to inspect, edit, export, compact, or delete memory
• Provenance for remembered facts

3. Scoped tools and permissions

• Its own apps, MCP servers, skills, filesystem scope, and network access
• Per-tool read/write permissions
• Human approval rules
• Secrets isolated by role
• Usage budgets and rate limits
• Full audit history

4. Agent-owned automations

• Cron and calendar schedules
• Condition-based monitors
• Event and webhook triggers
• Recurring reports
• A durable work queue
• State preserved between runs
• Quiet monitoring by default, with meaningful-change alerts

A scheduled run should resume the same role agent with its memory, policies, and state rather than launch a generic stateless task.

5. Agent-to-agent collaboration

• Explicit permission to message or delegate to selected agents
• Structured handoffs with provenance
• Shared projects and artifacts
• User-defined reporting lines
• Escalation rules
• No implicit global memory sharing

For example, Legal could ask Finance to estimate exposure while preserving the legal agent's ownership of the case.

6. Operational surface

A dedicated Agents or Employees area could show:

• Mission and current status
• Inbox / work queue
• Active and scheduled work
• Last run and next run
• Recent findings
• Pending approvals
• Agent-to-agent handoffs
• Memory and knowledge sources
• Activity and audit history
• Cost / usage

Users could create agents from scratch or from templates such as Legal, Finance, Operations, Executive Assistant, Sales, and Research.

Example: Company Legal Counsel

I create a persistent agent called Company Legal Counsel.

It has:

• a permanent legal mission and system prompt;
• memory of the company's matters and decisions;
• access only to selected email labels, document folders, and approved legal sites;
• recurring and event-driven monitors for emails, deadlines, and ongoing lawsuits;
• one record per matter with chronology, sources, risks, open questions, and next actions;
• permission to coordinate with a Finance agent on payments or provisions;
• an escalation policy that alerts me only for meaningful developments or required approvals;
• an audit log showing what it read, concluded, created, and delegated.

It can prepare summaries and drafts, but external filings, messages, payments, or destructive actions remain subject to explicit approval.

This is closer to having a supervised digital employee than running an automation.

Relationship to existing requests

This proposal overlaps with, but extends beyond:

• Allow custom agent profiles to be selected as persistent top-level chats #34745 — persistent top-level custom-agent conversations
• RFC: Persistent work threads with bounded command dispatch #35846 — persistent child work threads with bounded command dispatch

Those are useful foundations. This request adds the organizational and operational layer:

• ownership of an ongoing business function;
• agent-specific durable memory;
• agent-owned schedules and event triggers;
• persistent work queues and monitoring state;
• cross-agent collaboration and reporting lines;
• permission, approval, audit, and budget controls.

A persistent chat is still primarily conversation-centered. A persistent role agent is responsibility-centered and can continue its assigned function between direct conversations.

Possible conceptual model

[agent]
name = "Company Legal Counsel"
role = "legal"
mission_file = ".codex/agents/legal/mission.md"

[memory]
scope = "isolated"
shared_projects = ["litigation", "contracts"]

[permissions]
email = "read_selected"
documents = "read_write_selected"
external_messages = "approval_required"
destructive_actions = "approval_required"

[automation.daily_case_review]
schedule = "0 8 * * 1-5"

[automation.lawsuit_watch]
trigger = "condition"
check_interval = "6h"

[collaboration]
can_delegate_to = ["finance-controller", "executive-assistant"]

The exact configuration format is not important; the important property is that identity, memory, permissions, schedules, and relationships are attached to the agent as one durable object.

Suggested acceptance criteria

1. Users can create multiple named role agents.
2. Each agent has persistent instructions, identity, memory, and state.
3. Each agent can have independent tools, integrations, permissions, and budgets.
4. Scheduled and event-triggered runs execute as that agent with its existing memory and state.
5. Each agent has a persistent inbox/work queue and inspectable activity history.
6. Agents can communicate or delegate only through explicit user-defined permissions.
7. Memory sharing is explicit, scoped, and auditable.
8. External writes and high-impact actions can require human approval.
9. Users can pause, resume, archive, export, or delete an agent.
10. The UI clearly distinguishes queued, running, blocked, waiting-for-approval, and completed work.
11. Existing chats, profiles, skills, and task-scoped subagents continue to work.
12. The capability is available through both UI and a programmable interface.

Why this matters

n8n and similar tools let users build durable workflows. Codex could offer a higher-level abstraction: durable workers that own outcomes, remember context, operate within permissions, coordinate with other workers, and remain accountable to the user.

The key product distinction is:

A task runs once. A persistent role agent owns a responsibility over time.

This would move Codex from an agent that helps with individual tasks toward a platform where users can design and supervise their own specialized AI team.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• RFC: Persistent work threads with bounded command dispatch #35846

Powered by Codex Action

[hjqcan]

This is the right abstraction boundary: responsibility-centered rather than conversation-centered.

For the memory part, I would keep four objects separate:

1. Role identity — mission, permissions, budgets, and collaboration policy.
2. Runtime state — queue position, current run, retries, and temporary task context.
3. Canonical memory records — scoped by user/workspace/agent with provenance, verification status, and supersession.
4. Derived projections — briefs, indexes, and prompt context that can always be rebuilt from canonical records.

The key invariant is that a scheduled run should not hydrate an arbitrary old transcript. It should receive a bounded context assembled for that agent and responsibility. Sharing should be an explicit read policy; writes should remain attributed to the originating agent. Revise/forget must invalidate every derived projection so a corrected fact cannot silently return later.

GoodMemory is a working open-source reference for this slice: it supports agentId-scoped records, local SQLite by default, inspect/export/revise/forget, provenance and audit data, opt-in cross-agent reads, and does not treat raw transcripts as durable memory. Codex would still own role identity, permissions, schedules, queues, and UI; the memory layer can remain a clean subsystem rather than becoming the agent object itself.

Source: https://github.com/hjqcan/GoodMemory