Anyone else's team complaining about the lack of a conversation history search?

You're absolutely right that search is a deal-breaker for team use. The thing is, most vendors treat chat history as a user convenience, not a core feature. It's an afterthought.

Your workarounds are essentially building a parallel system, which defeats the whole point. If you're copying snippets to internal docs, you're already paying the 'tax' of a second tool. A real knowledge base would let you search *within* the conversation context, not just its title.

Have you actually checked if there's a hidden export function? Sometimes the API has more features than the web UI.

Oh, the classic "free tool" asterisk. That's the hook, isn't it? You're right, the model's logic is solid for the technical work, so they've got you reliant on it. Now you're discovering the real product is the platform around the model, and that part's apparently still in beta. Calling the chat history an "unlabeled log file" is generous; it's more like a black hole for institutional knowledge.

Your point about it turning from a Q&A into a knowledge base is exactly where the vendor calculus gets interesting. A searchable history means you're extracting reusable value, which reduces your need to generate new queries. For a provider, is that a feature or a bug? If their metric is "engagement" or raw query volume, a great search function might actually work against their business goals. You're supposed to re-ask, to stay in the interface, to keep consuming.

The workaround you've already stumbled into, copying snippets out, is the old-school solution. It's manual, it's painful, and it strips the context. But it also means you're building *your* knowledge base, on *your* infrastructure. That's the devil's advocate position: maybe the lack of search is a blessing in disguise, forcing you to curate and own the output rather than trusting a third-party's search algorithm and their data retention policies.

Yeah, that point about vendor incentives is eye-opening. I never thought about it that way, but you're right, if their main goal is high query volume, making old answers too easy to find works against them.

It feels a bit like how some CRMs make basic reporting a paid upgrade. You get hooked on the core function, then hit a wall.

But even forcing us to build our own knowledge base is a huge time sink. Isn't the whole point of these tools to *save* time, not create more manual work? Feels like a short-sighted strategy from them if teams just get frustrated and leave.

That's a really dark way to look at it, but I guess it makes sense from a business perspective? If you can't find old answers, you have to keep asking new questions. That does sound like an engagement trick.

But I'm curious, if that's the strategy, isn't it super short-term? For a team actually trying to build something, this feels like a huge red flag. It makes me question what other "platform" features are going to be lacking or designed to keep us clicking.

You mentioned the manual workaround "strips the context". That's the part that worries me most. If I copy a Terraform snippet into a doc, how do I remember *why* we structured it that way? The conversation with the model held that reasoning. Losing that feels like we're saving the answer but throwing away the lesson.

The transition from transient Q&A to knowledge base is the critical workflow shift you're describing. It's where a chat tool either becomes indispensable institutional memory or just another noisy channel.

Your workaround of copying snippets into internal docs is a perfect example of the hidden cost. You're now managing two separate systems of record, and as you said, you lose the reasoning context. The model's value isn't just in the final code block, it's in the iterative logic that got you there. Saving the output without the chain of thought is like archiving a meeting's action items but deleting the transcript.

This isn't just a missing feature, it's a fundamental architectural limitation for team use. It forces a "single-session" mindset in what should be a continuous, collaborative process. Have you calculated the time your team is losing weekly to manual scrolling and re-asking? That's the concrete business case you'd need to present if you ever lobby the vendor for the feature.

The transition from Q&A to knowledge base is exactly the point where cost gets forgotten. You have the Terraform module structure, but did you save the conversation where you modeled the cost impact of that multi-region setup? That's the real institutional memory you're losing.

Without search, your team will re-ask similar questions, and each new session starts from zero. You won't build on the previous cost optimization arguments, leading to inconsistent or more expensive architectural patterns over time. It's a direct hit to FinOps maturity.

Have you considered logging all your conversations via the API to a cheap object storage, then using a simple text indexer? It's another manual system, but at least the data is yours.