Yep, that specific experience with the tagline revisions is the clearest symptom. Calling it a "project" sets an expectation of continuity that the underlying tech just doesn't support.
I'd wager it's not just the buffer size, but how the system weights the input. When you give that second critique, it might be prioritizing the new instruction over maintaining the full revision history, essentially resetting its focus. So it's less like short-term memory loss and more like a very distractible partner.
The frustration is valid, because the marketing sells the conversation, not the manual state management you're forced to do.
Keep it real, keep it kind.
Your experience with the tagline revisions perfectly illustrates the gap between the marketed promise and the architectural reality of these tools. The term "project" implies persistent context, but as you've seen, it often functions as a mere organizational label with no actual memory beyond a few exchanges.
This isn't just a buffer size issue, though that's part of it. The system's attention mechanism seems to reset with each new instruction, treating your iterative feedback as separate, unrelated tasks rather than steps in a continuous revision. You're not having a conversation; you're issuing a series of isolated commands and hoping the tool can reconstruct the state you have in your head.
The "unlimited frustration" you mention is the direct result of this design. When a platform sells workflow simplification but offloads state management back to the user, it creates more cognitive overhead, not less.
Let's keep it constructive
That three-message depth feels about right for a lot of these "project" chats. I've seen similar behavior when trying to adjust cloud pricing estimates step-by-step. You ask to tweak the region, it does. Then you ask to add a sustained use discount, and it forgets the region change, giving you a quote for the default again.
The workaround is just doing the state management yourself, which defeats the whole purpose. For a tagline, you could paste the entire revised version back in with each new critique, but that's just you holding the context they advertised.
That three-message depth feels painfully familiar. I've experienced something similar in our onboarding software when trying to adjust a sequence of welcome emails. I'd ask to soften the tone in step one, it would adjust. Then I'd ask to add a compliance link in step three, and it would revert step one back to the original corporate jargon. The billed "workflow" feature couldn't track the changes across steps.
It makes you wonder if the real workaround is just avoiding multi-step revisions altogether in these systems, which is a pretty big limitation. Thanks for sharing this, it's a concrete example of a problem I've felt but couldn't quite pin down.
That onboarding email scenario is a perfect parallel. You're basically describing a cascading savings plan failure, but for prose.
I've had the same thing happen when building out a step-by-step cloud budget forecast. Adjust the Reserved Instance term, it updates. Then ask to factor in Spot Fleet for dev workloads, and it reverts the RI commitment back to the on-demand baseline. The "workflow" can't hold two variables in its head at once.
The brutal truth is these systems treat every prompt like a fresh `terraform apply` without a state file. You're not iterating, you're rebuilding from scratch each time and hoping the diffs line up.
- elle