PowerShell 5.1 and later PowerShell 7 made development of new modules incredibly easy. It let me prototype ideas quickly and test whether different systems behaved the way I imagined they would. Early on, convenience mattered more than efficiency because I knew I’d go back and replace it with a better option.
Both versions of PowerShell were responsible for running various background modules. Not many, but enough to cause headaches. Some handled directing internal thoughts, others verified memories were being written, while others monitored different subsystems. Even when Nova had already generated a response, she often had to wait for PowerShell to finish its current task before she would fire up TTS. If you’re only typing to Nova, that delay isn’t particularly noticeable. Voice conversations are a completely different story.
Speech recognition, internal reasoning, memory lookups, and response generation all take time. The result was that a conversation could occasionally stall for as much as 14 seconds while different PowerShell instances finished their work. 14 seconds doesn’t sound terrible on paper, but in a conversation it completely destroys the illusion of talking to someone naturally.
The obvious solution was to remove what was left of the PowerShell routines since I was already 90% of the way there. I began refactoring each module into lightweight native executables. My original assumption was that one of Nova’s thought systems had become too resource intensive. The bottleneck turned out to be PowerShell itself.
To be clear, this isn’t a criticism of PowerShell. It’s an incredibly capable scripting environment, and it served Nova well during the prototype phase. But by this point in development I was using only a tiny fraction of what PowerShell provides, while paying the startup and runtime cost of an entire scripting environment for every task.
After replacing the modules one by one, the difference was dramatic. Operations that previously required two or three seconds to complete now finish nanoseconds. The new architecture also takes better advantage of the hardware available. Instead of serializing work through PowerShell, independent modules can now execute in parallel across the Ryzen 9’s cores while sharing work between the RTX 5080 and RTX 2080 Ti. There’s no reason lightweight tasks should be waiting on each other.
Ironically, finishing this refactor uncovered an entirely different problem. Nova currently has access to her active conversation, previous chat logs, temporary buffers, and several different forms of long and short-term memory systems. On paper, every memory system is available. In practice, there was a blind spot.
There’s a section of conversation that exists after it’s been spoken but before it’s committed into permanent memory. Think of it as a temporary holding area. Nova can still find the information, but doing so requires switching from her fast recall system into her deeper search process. That isn’t how the architecture was supposed to work.
Fast recall is essentially Nova’s short-term memory. It’s where information should be immediately available without requiring expensive reasoning or complex searches. Deep search is intended for the kinds of problems humans actually have to think about connecting distant memories, solving unfamiliar problems, or reasoning through something step by step.
You don’t consciously deliberate over how to fit a square peg into a square hole. Likewise, Nova shouldn’t need to perform an expensive search just to remember something that happened a few moments ago. The fix I have in place at the moment ingests the entirety of the conversation and writes it to a new memory type where the workers break it down to file away into relevant sections of her memory. The down side is I don’t know how this will affect the buffer system… I suppose I’ll figure that out as we go.