Optional instructions and memory per thread, set in thread details

[lhagenmayer]

Problem

A thread has no durable identity of its own. I want to run threads like team members: each one knows what it is responsible for, what it is not responsible for, and which facts it should keep in mind.

Today the options don't fit that:

• CLAUDE.md and AGENTS.md apply to a whole repository or worktree.
• Provider launch arguments such as --append-system-prompt-file apply to a whole provider instance, so each role needs its own instance per account.
• A role pasted into the first message is ordinary conversation text, and it can't be seen or edited later.

Proposal

Add two optional text fields to each thread, editable in thread details:

• Instructions: the thread's role, responsibilities and limits.
• Memory: facts this thread should keep, maintained by the user.

If both are empty, nothing changes. T3 Code sends exactly what it sends today, so existing threads keep their behavior and their prompt cache.

Like other rows, this one could be switched off through the existing thread details item settings.

How it could work

T3 Code already delivers its own instructions through each provider's adapter. These fields could use the same paths instead of a new mechanism:

• Claude: add the text to the append value of the system prompt, next to T3's own text and any launch-argument text.
• Codex: send it as additionalContext, which T3 already restores after compaction. Values are limited to 4,000 bytes per entry, so longer text needs splitting across entries or a stated limit.
• Other providers: use the path each adapter already has for T3's instructions.

Optional fields on t3_thread_launch would let an external coordination tool set them when it starts a thread. I use such a tool to track each thread's owner, goal and plan, so this would let it give a thread its role without a parallel mechanism.

Out of scope

• Agent rosters or pickers, and Markdown agent discovery (GitHub Copilot-Style Custom Agents with Lead-Subagent Delegation, Dynamic Model Switching, and Project Defaults #17924, feat(agents): add project custom agents #18225)
• Delegation rules
• Names, avatars or a bot UI (Tots: long-lived bots on mobile with a name, role and memory, plus teams (Grok Bot / Duet style) #27347)
• Automatic memory extraction (Project router and neutral memory #26194)
• Permission enforcement: these fields guide the agent, they don't restrict it

Open questions

1. Agent writes to memory: should it be user-only at first, or should an agent be able to update it through an MCP tool, with changes visible in the thread?
2. Edits during a thread: when should they apply? On Claude, changing the system prompt may mean replacing the running query and rewriting the prompt cache.
3. Inheritance: should forks, side chats and delegate_task children inherit the fields? I'd suggest not for delegate_task, which starts without parent history.
4. Access: who can see and edit the fields on shared environments or guest links? I'd suggest the same access as other thread edits, with a clear note not to store secrets there.
5. Size limit: what limit should apply across providers?

Related

• Tots: long-lived bots on mobile with a name, role and memory, plus teams (Grok Bot / Duet style) #27347: long-lived bots on mobile, including an optional thread persona
• GitHub Copilot-Style Custom Agents with Lead-Subagent Delegation, Dynamic Model Switching, and Project Defaults #17924: project custom agents
• Allow configuring default instructions or a default skill per provider model #21259: default instructions per provider model
• Let a project append to, replace or turn off the injected orchestration instructions #27201: changing the injected orchestration instructions per project
• Project router and neutral memory #26194: provider-neutral project memory

---

Checked against the source of v0.1.6-nightly.20261031.3977. This is a proposal only: nothing has been implemented or tested. Drafted with Claude Opus 5.5 in Claude Code, during a t3 triage session.