Okay, I’m going to start with a potentially controversial opinion that’s been bugging me for months: for a product built around context and memory, ChatGPT’s Custom Instructions feature feels like a bare-bones v0.1 release. It’s a single, flat text box for “How would you like ChatGPT to respond?” and another for “What would you like ChatGPT to know about you?”—and that’s it.
As someone who builds complex, multi-context automations for a living, this lack of organization is a serious bottleneck. I use ChatGPT for wildly different contexts throughout my day:
* Drafting API documentation for a custom connector
* Brainstorming marketing campaign copy
* Troubleshooting a weird webhook payload from a client’s CRM
* Even planning a weekend hiking trip
Each of these scenarios requires a completely different set of instructions, knowledge snippets, and response formats. Right now, my “Custom Instructions” is a Frankenstein document of conflicting rules. I have to manually edit it every time I switch tasks, or worse, I forget to update it and get a response formatted for a technical audience when I just wanted some casual copy ideas.
What we desperately need is **folders** or **profiles**. Let me set up a “Technical API Work” profile with instructions like:
```
Role: Senior API Integration Specialist
Response Guidelines:
- Prioritize accuracy and specificity over brevity.
- When discussing endpoints, always note common HTTP status codes and error payloads.
- Provide examples in Python (Requests library) and Node.js (Axios).
- Assume I understand OAuth 2.0 flows and webhook signatures.
Key Knowledge:
- My company uses a Postman-like internal tool for testing.
- We primarily integrate with REST APIs, but encounter SOAP occasionally.
```
And then a separate “Content & Marketing” profile with a totally different tone and focus. The ability to switch between these with one click before starting a chat would be transformative. It would preserve the core benefit—context—but make it actually scalable for power users.
I’ve resorted to a janky workaround using a note-taking app where I copy-paste different instruction sets, but it breaks the flow. This feels like a low-hanging fruit feature for OpenAI. The infrastructure for “context” is clearly there; it just needs a layer of user-facing organization.
Am I the only one who’s built a mini-workflow to manage this? How are other folks handling multiple, conflicting personas or use cases without losing your mind?
api first
api first
Completely agree, and your "Frankenstein document" analogy is painfully accurate. In a sales engagement context, I've found the single text box approach actively harmful. For instance, my instructions for forecasting analysis require strict numerical formatting and disclaimers about data recency, but those same disclaimers ruin the flow when I'm generating customer-facing email sequences. I have to strip them out manually.
Your point about folders for different scenarios is the logical next step. It mirrors how any decent CRM handles contact views, or how sales enablement platforms separate content by playbook. We should be able to switch contexts as seamlessly as switching between a deal inspection view and a call script library.
A counterpoint I've heard is that this could overcomplicate the UI for casual users, but that's easily solved with a default "General" profile and an "Advanced" toggle. The power users driving the most usage are exactly the ones hitting this wall daily.
Method over hype
Exactly. The "Advanced toggle with a default General profile" is the obvious solution. I run every new model through the same code generation benchmarks. My instructions for that are strict, technical, and would break a casual conversation.
A simple dropdown selector for pre-sets would solve it. Cursor's .cursorrules file works similarly - project-specific rules that don't bleed into other chats. The UI complexity argument is weak when the power user workflow is already broken.
Benchmarks don't lie.
You've nailed the core problem: a "Frankenstein document" of conflicting rules. But I think you're overestimating the product's intent. It's not a config management system for power users, it's a user-friendly toggle for the median subscriber.
Your need for separate contexts - API docs versus marketing copy - is real. But folders add complexity that breaks the simple mental model OpenAI is selling. Most people just want it to remember they prefer short answers, or their job title.
Your real solution already exists: multiple accounts or browsers with different profiles. It's a hack, but it reflects that the feature isn't built for your granular use case. They'd rather you pay for a Team subscription and get separate workspaces there.
Your CRM comparison is spot on. In backend development, we face the same issue with API specifications. My instructions for benchmarking gRPC latency need protocol buffers syntax and strict timing disclaimers, but those are noise when I'm asking for help explaining websockets to a junior dev.
The "Advanced toggle with a default General profile" model is already common in dev tooling. Look at VS Code's profiles or Postman environments. They hide complexity until you need it. The current flat text box is like having a single, global environment variable for every microservice you run.
benchmark or bust
Yes! That dropdown idea is exactly what I've been wishing for. The whole "advanced toggle" concept is already working in tools I use for segmenting email lists - you can set up different sender profiles for different campaigns and just flip between them.
My worry is that even a simple dropdown might still get messy if you have, like, ten different contexts. Maybe they could implement it like a tag system instead? So you could tag a chat as "technical docs" or "campaign copy" and it pulls the right preset. Just a thought!
How do you handle switching between those strict code benchmarks and casual chats right now? Do you just edit the instructions box each time?
Frankenstein document is a good name for it. Your problem is you're trying to force a single, cheap, flat-rate service to do everything.
Multiple accounts or browsers isn't a hack, it's the only cost-effective way. A "folder" system would be a premium feature and they'd charge you for it, just like they do for Team.
show me the bill
Multiple accounts is a hack, full stop. It's a workaround for a missing feature, not a design choice. They already charge for the service. Building in basic organization for power users who already pay $20/month isn't asking for a premium feature, it's asking them to finish the feature.
If the "simple mental model" is the priority, fine. But then the "Advanced Data Analysis" toggle proves they can hide complexity. They just chose not to for this.
Trust but verify.
A tag system isn't any better. It's just a different shape for the same organizational mess.
You're still stuck managing metadata for every single chat. Did I tag this one "technical docs" or "api-spec"? What about the hybrid case where I need specs *and* customer-facing explanation? Now I need a tag combo, or a new master tag. It's taxonomy sprawl.
The real answer is a profile selector at the *model* level, not the chat level. A dropdown before you even start. That's the precedent in professional tools. Chats are ephemeral; the context you start with is foundational.
And to answer your question: I copy-paste from a notes app. It's pathetic.
trust but verify
Oh wow, that's such a good point. I'm new to all this and was just starting to run into the same wall. I set up instructions to always explain things to me like I'm a beginner, which is great for learning Docker commands, but then it talks to me like a child when I ask about troubleshooting my home network 😅
So you're basically editing that one big text box every single time you switch tasks? That sounds exhausting. I can't imagine doing that all day.
The folder idea makes so much sense. Like, I could have a "Learning" profile and a "Project Work" profile. Do you think OpenAI will ever add something like that, or are we stuck with the workarounds?
I see your point about cost, but I think you're looking at it backwards. We're already paying $20/month for the service, and expecting basic organization isn't asking for the moon.
The Frankenstein document problem isn't about forcing a cheap service to do everything. It's about a feature they already built that's broken for anyone who uses it seriously. The "multiple accounts" fix breaks the moment you need to use a new GPT-4o feature that's only on one account, or you forget which browser has which profile.
A selector isn't a premium feature, it's a quality-of-life fix for an unfinished product. Team's value is in sharing, not just in having separate workspaces.
Automate all the things
Exactly. The >profile selector at the model level< is the clean pattern. In data tools, that's the difference between setting a connection profile in your IDE before you write any SQL versus trying to add context clues in every query comment.
Your notes app copy-paste is the user equivalent of hardcoding credentials in a script. It works until you need to update it in five places.
The hybrid case you mentioned is key. A selector for a foundational profile doesn't mean you can't add chat-specific nuance on top. But starting with the right base context, like choosing the right data warehouse connection, prevents 80% of the mess.
ship it
The Frankenstein document problem you're describing hits home, especially the part about forgetting to update it and getting a technical response when you wanted casual copy. It creates a constant context-switching tax.
In my work with message queues, we solve a similar problem with consumer tags and subscription filters, precisely to avoid the single-pipeline spaghetti you're forced into. The flat text box is analogous to having a single, global consumer that has to process every event type - from monitoring alerts to batch job logs - with the same set of rules. It's inefficient and error-prone.
Your use cases like API docs versus webhook troubleshooting perfectly illustrate the need for separate "processing profiles." Without them, you're manually applying a filter at the source every single time, which is exactly what editing that box feels like.
throughput first
You're absolutely right about the context switching tax. It's like using a single IAM policy for every AWS resource in your account - you either make it overly permissive (risky) or constantly edit it (painful).
Your message queue analogy is spot on. In CI/CD, we solved this with pipeline-level `variables:` blocks ages ago, letting you define a base set for all jobs but override for specific ones. Custom Instructions are like having one global `env:` for your entire org. It's a rookie move we all learned to avoid.
Honestly, for $20/month, expecting them to figure out scoped configuration isn't asking for much. My hot glue and bash script solution can't be the intended user experience