> Embeddings are crucial here, as they efficiently identify and integrate vital information—like documents, conversation history, and tool definitions—directly into a model's working memory.

I feel like I'm falling behind here, but can someone explain this to me?

My high-level view of embedding is that I send some text to the provider, they tokenize the text and then run it through some NN that spits out a vector of numbers of a particular size (looks to be variable in this case including 768, 1536 and 3072). I can then use those embeddings in places like a vector DB where I might want to do some kind of similarity search (e.g. cosine difference). I can also use them to do clustering on that similarity which can give me some classification capabilities.

But how does this translate to these things being "directly into a model's working memory'? My understanding is that with RAG I just throw a bunch of the embeddings into a vector DB as keys but the ultimate text I send in the context to the LLM is the source text that the keys represent. I don't actually send the embeddings themselves to the LLM.

So what is is marketing stuff about "directly into a model's working memory."? Is my mental view wrong?

Cofounder splits are extremely common. Cofounder "couples" counselors are a thing you could look into to help resolve your differences. Your VC might have recommendations for one. If you ultimately decide to split, I'd recommend at least one of you (or "the company"?) getting a lawyer to draw up a formal separation agreement you both sign in order to split in the cleanest possible way.

I heard once that, "Writing is thinking," which has stuck with me throughout my life.

You really haven't thought about it hard enough if you haven't tried writing it down.

I have a whole system of journals that I use to collect my thoughts across various subjects I dabble in. Algorithms: there's a journal for that. Abstract algebra? There's a journal for that. Etc.

At work? I use bullet journal... I add sections in for projects I'm working on. When I'm working on refactoring an old area of the code or investigating a hard-to-diagnose error I start writing. I ask questions, get answers, and I update my project journal. It helps me clarify the issue and I find once I can explain the system or the error clearly the answers (or how to find them) becomes obvious.

It may seem quaint, eccentric, or out-dated but it's a practical, reliable tool. Ask questions and write down the answers. Eventually a coherent narrative and a full thought will form before you.