Introducing Skink-lang: Elegant Systems Programming for AI & Robotics (or, How to Stop DANI from Eating the Skirting Boards)

Over the last thirty years, I’ve worked across a sprawling landscape of technologies—from writing Go, C#, Pascal, Swift, and C, to orchestrating massive cloud pipelines, down to micro-managing registers on bare-metal microcontrollers.

But lately, my time has been dominated by a very specific, highly opinionated, and occasionally cooperative localized AI agent: DANI.

If you've been following my previous posts, you know DANI has transitioned from an LSTM-based cognitive core into a physical, moving entity. And that is where the real-world engineering headaches began. Every time you start a new robotics or physical AI project, you are forced to make a compromise that feels like choosing between a kick in the shins or a poke in the eye:

• The C/C++ Extremity: You get deterministic, blazing-fast performance on microcontrollers, but you sacrifice developer ergonomics, modern package safety, and swift prototyping. Writing raw $C++$ register manipulation code sometimes feels like trying to perform laparoscopic surgery on yourself with a rusty spoon.
• The Python Extremity: You get instant access to rich AI primitives, neural networks, and expressiveness. But you inherit bloated virtual environments that take up more disk space than the library of Alexandria, and unpredictable garbage collection (GC) latency. When DANI’s control loop is running at $100\text{ Hz}$ and the Python garbage collector decides to take a mandatory three-millisecond tea break, DANI doesn't stop. She gracefully, but deterministically, plows straight into the skirting board.

I got tired of choosing between developer speed and hardware execution safety. I wanted a compiled language built specifically for low-level systems hardware, high-throughput concurrent event streams, and native AI execution.

So, I built Skink-lang.

What is Skink?

Skink is an LLVM-backed, statically-typed systems programming language designed from the ground up for the modern era of intelligent automation. It blends the tight, expressive syntax of modern languages like Swift with the lightweight concurrency model of Go, leaving behind the runtime bloat.

To save you from the nightmare of modern package managers—where doing a pip install on a single helper utility somehow downloads half the internet and a bootleg copy of Doom—Skink comes with a rich, "batteries-included" standard library right out of the box.

As a Skinker (yes, that is our official title now), you get native access to:

1. Automatic Reference Counting (ARC): Predictable, deterministic memory management without "stop-the-world" garbage collection pauses. This is a non-negotiable requirement when you are driving physical motors or processing high-frequency sensor telemetry.
2. Lightweight Concurrency: A native spawn keyword that allows you to spin up millions of concurrent tasks with near-zero overhead, communicating cleanly via typed channels.
3. The Rules Engine: A compiler-optimized reactive rules engine that lets you define declarative behavioral overrides that monitor variables in the background. It is perfect for saying, "I don't care what the neural net is thinking; if we are $15\text{ cm}$ away from a wall, hit the brakes."
4. Native Tensors & ML Cores: Multi-dimensional arrays built directly into the type system via std/tensor, complete with matrix operations, activation functions, neural layers, and hooks for CUDA acceleration and llama.cpp (std/llm). DANI can run local inferences natively, at maximum speed, without needing a dedicated power plant or $16\text{ GB}$ of RAM.
5. Model Context Protocol (MCP) & MQTT: Built-in support for turning any hardware endpoint into an instantly discoverable AI tool with SQLite (std/db) and edge-to-cloud messaging (std/mqtt) ready to go.

Under the Hood: Preventing a DANI Catastrophe

To see what "skinking" actually looks like, let's write a syntactically valid program based on the current Skink manual.

The following script concurrently polls a physical distance sensor via GPIO, pipes the measurements to our main execution block using channels, evaluates safety overrides in a background ruleset, and processes the inputs through a linear neural network layer to calculate motor outputs:

module main

import "std/gpio"
import "std/time"
import "std/tensor"

// 1. Declare global state variables (accessible by the ruleset)
var current_distance: float = 100.0
var motor_speed: float = 0.5

// 2. Define a reactive ruleset for safety overrides
ruleset SafetyOverride {
    rule collision_warning when current_distance < 15.0 {
        action: trigger_emergency_stop()
        priority: 1
    }
}

// Helper function called when the rule fires
fn trigger_emergency_stop() {
    motor_speed = 0.0
    print("SAFETY OVERRIDE: Obstacle detected! Distance: {current_distance}cm. Braking.")
}

// 3. Concurrently poll the hardware sensor in a background task
fn sensor_loop(ch: chan<float>) {
    err := gpio.Setup()
    if err.message != "" {
        print("Failed to initialize GPIO: " + err.message)
        return
    }

    // Bind to BCM Pin 17 (e.g., our sensor input pin)
    sensor_pin := gpio.PinFactory(17)
    sensor_pin.SetInput()

    while true {
        // Mocking a physical sensor read for this demo loop
        // In physical deployment, you'd calculate raw voltage pulses here
        measured := 12.5 
        ch <- measured
        time.SleepMs(10) // Poll at 100Hz
    }
}

// 4. Main Entry Point
fn main() -> int {
    sensor_chan := make(chan<float>)

    // Spawn our lightweight background polling loop
    spawn sensor_loop(sensor_chan)

    // Activate our safety ruleset background thread
    safety := SafetyOverride{}
    safety.start()
    defer safety.stop()

    // Initialize a linear neural network layer [input_features: 3, output_features: 1]
    layer := tensor.NewLinear(3, 1)

    // Run our control loop for 100 iterations
    for i := 0; i < 100; i = i + 1 {
        // Block until next sensor reading arrives
        current_distance = <-sensor_chan

        // If we are in a safe zone, let the tensor neural layer drive
        if current_distance >= 15.0 {
            input := tensor.Zeros([1, 3])
            input.Set([0, 0], current_distance)
           
            output := layer.Forward(input)
            motor_speed = output.Get([0, 0])
           
            print("Processing... Current motor velocity: {motor_speed}")
        }
    }
    return 0
}

Notice how neatly this handles the classic embedded AI problem. The concurrency model lets you poll hardware safely on separate execution threads without blocking the main loop, while the native ruleset watches the critical state variables and takes action within milliseconds if a threshold is breached—guaranteeing deterministic safety constraints before DANI can do any structural damage to the house.

Where Skink-lang Goes From Here

Currently, the compiler is bootstrapped in Go, using an LLVM backend to output highly optimized native machine binaries targeting both Linux and Windows corporate environments. Because there is no heavy runtime or garbage collector, a compiled Skink binary running an active inference loop can comfortably squeeze inside less than $128\text{ KB}$ of RAM.

But this is just the beginning. The roadmap ahead includes:

• Direct Single Board Computer HAL: Expanding the standard library to map hardware registers and pins natively (such as on the Raspberry Pi 5) with zero external C-bindings.
• Self-Hosting: Rewriting the Skink compiler entirely in Skink itself, proving the language's capabilities to handle massive, complex systems-level software natively.

Cullen Skink

I’m incredibly excited about what this language makes possible. DANI is already running much cooler, much faster, and with a significantly lower skirting-board collision rate.

It is time to stop fighting the plumbing.

Let's get skinking!

Let me know your thoughts on the syntax, and what features you'd like to see added to the compiler next!

The Sledgehammer and the Hazelnut: Why DANI Isn't Using an LLM

I have a confession to make. I’ve broken my own rule.

When I set out to build and program DANI, one of my core principles was to ensure he learns primarily from experience. The goal has always been emergent behavior through his neural architecture, with as little "hard-coded" logic as possible. But as I’ve delved deeper into the complexities of human interaction, I’ve found one area where I feel a departure is justified: Natural Language Processing (NLP).

The LLM Dilemma

The LLM Sledgehammer

Early on, I toyed with the idea of giving DANI a dedicated board specifically to run a Large Language Model (LLM). It seemed like the modern solution, but the more I looked at it, the more the red flags started popping up.

First, there’s the cold, hard reality of the budget. I’ve managed to keep the total cost of DANI—parts, boards, and all—under £500. Adding a high-spec NPU or a secondary board capable of running something like Llama or Gemma would have blown that goal out of the water.

Then there’s the physical engineering. Space is at a premium inside DANI’s chassis. While I probably could have squeezed another board in there, I’m increasingly conscious of airflow. The last thing I want is for DANI’s "brain" to thermal throttle in the middle of a conversation.

But most importantly—and this was the dealbreaker—is the issue of personality. If I use a pre-trained model like Qwen or Llama, I’m essentially importing someone else’s bias and conversational style. These models are fine-tuned to be helpful assistants; I want DANI to be DANI. Using a massive, multi-billion parameter model just to parse a "hello" felt like using a sledgehammer to crack a hazelnut.

The Go-pher’s Path to Understanding

Instead of the LLM route, I’ve built a custom natural language module using standard NLP libraries for Go. It’s lightweight, it fits within our existing hardware constraints, and it gives me the control I need.

I’ve added two critical features that an off-the-shelf LLM wouldn't handle the way I want:

1. Sentiment Assessment: By using established sentiment modules, DANI can now perceive whether he is being praised or scolded. This feeds directly into his hormone levels. If I’m happy with his performance and tell him he's done a good job, his "positive" hormones will rise, reinforcing that behaviour in his training.
2. Simplified Context Awareness: I wanted conversations to feel natural. If I ask DANI, "Where is he?", he needs to understand that "he" refers to the last male person we discussed. Similarly, "Go there" should resolve "there" to the last location mentioned. This kind of stateful awareness is vital for a robot that exists in a physical space.

Commands, Questions, and the "Ignore" Factor

The module is now capable of distinguishing between commands, questions, and general statements. Each triggers a different internal processing path, but here is the kicker: everything is still influenced by his hormones.

Before DANI responds, every decision passes through his LSTM (Long Short-Term Memory) core. Because that LSTM is also being fed the current state of his effective hormones, there is no guarantee he will do what he's told. If he’s in a "bad mood" or his hormone levels are skewed by previous interactions, he might just decide to ignore me entirely.

It’s a bit of a gamble, breaking the "no-code" rule to build this framework, but I think it’s the only way to give DANI a voice that is truly his own. We’ll just have to wait and see if he actually listens to me.

Oops, I Gave My Robot Amnesia (And How I'm Fixing It)

Wow, it’s been a while. Apologies for the radio silence, but the pesky "real world" caught up with me, and I had to spend some time doing that whole "working for a living" thing.

Anyway, enough about the mundane. Let's get back to what is actually important: DANI.

As you might remember, my ultimate, beyond-my-wildest-dreams goal with this project is to cross that threshold and meet the definition of when a robot is actually alive, or at least close to it. But recently, while pondering DANI’s LSTM (the fancy Long Short-Term Memory neural network that acts as his brain), I realized I had made a fundamental—and slightly embarrassing—mistake.

It’s hard to achieve sentience when your robot has the memory retention of a goldfish.

The Problem: Scheduled Blackouts

As it stands right now, DANI "thinks" every 100 milliseconds, giving him 10 thought cycles a second. Every 10 seconds (100 cycles), backpropagation kicks in to train the network. To do this concurrently without stopping DANI in his tracks, I clone the LSTM at that exact moment, run the heavy backpropagation math on the clone, and then overwrite the active LSTM with the newly trained clone.

This backpropagation takes about 2 to 3 seconds. My initial thought was: Brilliant! The training happens in the background without interrupting his flow.

But there is a glaring flaw.

Because the process takes a snapshot, spends 3 seconds learning from it, and then violently overwrites the active brain... we lose those 2 to 3 seconds of short-term memory that DANI experienced while the training was happening. Every 10 seconds, DANI essentially blacks out and forgets the last few seconds of his existence. This is seriously hampering his learning capabilities.

How do we stop DANI from becoming a chronic amnesiac?

The Fix: A Neurological Hot-Swap

My solution is to ditch the cloning process entirely. Instead, each neuron will now have two sets of weights: one active, one inactive.

During backpropagation, the inactive weights will get the results of the calculation (using the active weights for the algorithm). This allows us to update the LSTM's underlying math without wiping out the actively evolving memory states (the cell states and hidden states) that DANI is currently using to understand the world. We just add a flag to each layer to indicate whether it should be reading from Weight Set 1 or Weight Set 2.

But wait, there’s more!

Reshaping the Brain

At present, DANI's model has about 300 neurons on each layer, with 5 layers (I don’t have the code right in front of me, so I'm relying on my own somewhat flawed, non-LSTM memory here).

If we increase the number of layers but reduce the neurons per layer, we can implement a rolling update. This means DANI can immediately benefit from the training layer-by-layer, even while the rest of the brain is still calculating.

What this entails is increasing the layer count to 7 (any higher and we start flirting with the dreaded vanishing gradient problem), but reducing the neuron count, per layer, to 128 (because who doesn't love a nice power of 2?).

This gives DANI a much more focused, "deep" thought process, allowing him to break down problems more efficiently. It also allows us to gracefully ‘flip the switch’ on each layer as we cycle through.

Here is how the rolling update will work:

As each feed-forward pass occurs (DANI thinking), a check is done to see if the next layer is ready to have its switch flipped to the newly trained weights. Because backpropagation is strictly sequential and works backwards, we start checking from the last layer and move towards the first.

If a layer is ready, we flip the weights to the newly trained set and mark it as done. On the next thought cycle, we check the next layer, and so on, until we reach the front of the brain. Then, we start the whole process over again.

What do we gain from this brain surgery?

Quite a bit, actually:

1. Constant Learning: The LSTM is in a state of continuous, uninterrupted learning.
2. Stable Learning Rate: No massive, sudden shifts in logic.
3. Smoother Processing: No sudden CPU spikes from cloning and overwriting massive arrays.
4. Deeper Thinking: The structural change to 7 layers gives DANI a more nuanced, layered way of processing information.
5. Memory Retention: We actually retain the states of the memory gates within the LSTM. No more 3-second blackouts!

There are certainly other ways to create a continuous neural network, but I am aiming for the absolute simplest solution here. Remember, all of this is running on a Raspberry Pi!

This dual-weight method does increase the memory required to hold the LSTM, but because we are reducing the overall neuron count from ~1500 (5x300) to 896 (7x128), it's actually going to be lighter on the Pi overall. DANI had an oversized network anyway, so trimming the fat while adding depth is a win-win.

What do you guys think of this approach? Let me know in the comments if you see any potholes I'm about to step in!

Merry Christmas

Merry Christmas, happy holidays, season's greetings, etc. to everyone. Taking a break from working on DANI over the break from work (alcohol and robot building do not mix).

See you all again in 2026.

Major Milestone

Hi all,

We did it, folks! After what felt like an eternity of juggling tiny wires, questioning all my life choices, and occasionally wishing I had a third hand, I hit a massive milestone on the DANI project yesterday. It's the kind of milestone where you realize your ambitious little Frankenstein monster might actually walk one day—or, at least, successfully power on without tripping a breaker in the garage.

Hardware Complete (Sort Of)

All the core pieces are finally tucked neatly into their places, which is a huge win. The only big-ticket item left on the bench is the RDK X5 for the LLM, but honestly, that’s like waiting for DANI to hit puberty; it’s an inevitable future problem that we’ll handle when the time comes.

For now, we got the essential life support hooked up:

• The battery is snug and operational.

• A dedicated temperature sensor is in place for fan control. We've got to keep DANI cool under pressure, especially when he starts wrestling with complex AI problems (or, you know, my shoddy early-stage code).

• And the real game-changer: a voltage meter. This means DANI can now tell me when his battery is running low. This is a huge step up from the previous system, which was essentially "flicker dimly and then dramatically die mid-sentence."

Now for the slight confession: for the immediate future, he still needs me to play charger-daddy and physically plug him in. But fear not, the ultimate goal involves a glorious, automated self-charging station. DANI needs to learn to feed himself, after all—I can't be doing this forever!

Diving Into the Code Matrix

With the hardware stable, we pivot to the messy, beautiful, and sometimes existentially horrifying world of code. I've successfully laid the foundation for the majority of his core functions:

• Sensor Input: He can now 'feel' the world around him.

• Speech-to-Text and Text-to-Speech: He can hear me and talk back! Right now, his vocabulary is purely transactional, but it's a solid start. We're well past the awkward mumbling phase.

However, the more sophisticated stuff—the LSTM (that's the deep learning magic) and his memory structure—are currently just written out, waiting for their turn to be integrated. They’re functional pieces of code, but they're not yet plugged into DANI’s neural network. They’re basically that brilliant but currently unemployed friend crashing on your couch, waiting for the job offer to come through.

The Road Ahead: Vision, Brains, and APIs

For once, an actual photo of me working on DANI

My immediate to-do list involves a lovely date with an Arduino Nano to fully finalize all those sensor inputs. We need to make sure DANI has perfectly mapped out his surroundings before we give him eyes.

Once the senses are online, we move to the next critical developmental stage: vision! I’ll be coding up the K210 for the YOLO and FaceNet models. This is when he graduates from "blurry blob recognition" to "Wait, is that the mailman again?"—a crucial upgrade for home security and general social interaction.

Finally, the heavy lifting on the Raspberry Pi (which is essentially his main thinking engine) begins, and I’ll be firing up an API for the LLM on my home server. It’s a temporary solution until the RDK X5 arrives, but you use what you have.

Wish me luck—may my coffee stay strong and my bugs stay trivial! More updates soon!

Hold Your Horses, HAL: Are We Rushing Our AI Implementation?

You can't throw a USB stick these days without hitting an article, a webinar, or a coffee mug proclaiming "The AI Revolution is Here!" And look, the excitement is understandable. As someone who works with this technology every day, I can tell you the advancements are genuinely amazing.

And yet... I'm worried.

I’ve been noticing a worrying trend of "AI FOMO" (Fear Of Missing Out) in the industry. We're in such a rush to implement Large Language Models (LLMs) that we’re tripping over our own feet. We're so busy trying to run that we forgot to learn how to walk.

The "How-To" Guide is Missing a Few Chapters

First off, we're asking engineers who aren't AI specialists to wire up these incredibly complex models. They're given an API key and a "good luck," and sent off to integrate an LLM into a critical workflow.

It's a bit like asking a brilliant plumber to rewire a skyscraper. They can probably follow the diagram and get the lights to turn on, but they might not understand the deep-level electrical engineering... or why the elevator now seems to be controlled by the breakroom toaster. Having a deep understanding of a technology before you bake it into your business is paramount, but it's a step we seem to be skipping.

The "Black Box" Conundrum

This lack of understanding leads to an even bigger problem: explainability. Or rather, the total lack of it.

Even for experts, it's often impossible to trace why an LLM gave a specific answer. It's a "black box." If the AI makes a bad decision—like denying a loan, giving faulty medical advice, or flagging a good customer for fraud—and you can't explain the logic behind it, you're facing a massive legal and ethical minefield. "The computer said no" is not a valid defense when that computer's reasoning is a complete mystery.

Confident... and Confidently Wrong

Ah, "hallucinations." It's such a polite, almost whimsical term for when the AI just... makes things up. Confidently.

Even with the right data, if you don't ask the question in just the right way, the model can still give you a wildly incorrect answer. We try to patch this with "prompt engineering" and "context engineering," which, let's be honest, feels a lot like learning a secret handshake just to get a straight answer. These are band-aids, not solutions.

The Unscheduled Maintenance Nightmare

And that "secret handshake" of prompt engineering? It's a brittle, temporary fix.

What happens when the model provider (OpenAI, Google, etc.) releases a new, "better" version of their model? That perfectly-crafted prompt you spent months perfecting might suddenly stop working, or start giving bizarre answers. This creates a new, unpredictable, and constant maintenance burden that most companies aren't budgeting for. You're effectively building your house on someone else's foundation, and they can change the blueprints whenever they want.

Using a Sledgehammer to Crack a Nut

This leads to my next point: using AI purely for the "clout." I've seen demos where an LLM is used to perform a task that a traditional, boring-old-app could have done in a tenth of the time.

As the document I read put it: "Would you use a large language model to calculate the circumference of a circle, or a calculator?"

We're seeing companies use the computational equivalent of a sledgehammer to crack a nut. Sure, the nut gets cracked, but it's messy, inefficient, and costs a fortune in processing power. All just to be able to slap a "We Use AI!" sticker on the box.

The (Not-So) Hidden Costs

That sledgehammer isn't just inefficient; it's absurdly expensive. These models are incredibly power-hungry, and running them at scale isn't cheap.

We're talking massive compute bills and a serious environmental footprint, all for a task that a simple script could have handled. Is the "clout" of saying "we use AI" really worth the hit to your budget and the environment, especially when a cheaper, "boring" solution already exists?

A Quick Rant About "Innovation"

This brings me to a personal pet peeve. Companies are claiming they are "innovating with A.I."

No, you're not. You're using A.I.

You're using someone else's incredibly powerful tool, which is great! But it's not innovation. That's like claiming you're "innovating in database research" because you... used SQL Server. Creating a slick front-end for someone else's model is product design, not foundational research. Let's call it what it is.

Let's Tap the Brakes

We see a lot of pushback against self-driving cars because they're imperfect, and when they go wrong, the consequences are catastrophic.

Shouldn't we have the exact same caution when we're dealing with our finances, our sensitive data, and our core business logic? In an age of rampant data and identity theft, hooking up systems to a technology we don't fully understand seems... bold.

The acceleration of these models is incredible, and I use them every day. But they are not 100% ready for primetime. They make mistakes. Most are small, but some aren't.

So, maybe we all need to take a collective breath, step back from the hype train, and ask ourselves a few simple questions:

1. Do I really need an LLM for this? Or will a calculator (or a simple script) do?
2. Do we really know what we're doing? Can we explain its decisions?
3. Is it safe? Is our data safe? What happens when it's wrong?
4. Will this negatively affect our customers?
5. How will this affect our employees?
6. Does the (very real) cost of using this outweigh the actual gain?

Let's walk, then run.

3.5 Million Parameters and a Dream: DANI’s Cognitive Core

DANI’s Brain Is Online! Meet the LSTM That Thinks, Feels, and Remembers (Like a Champ)

Ladies and gentlemen, creators and dreamers—DANI has officially levelled up. He’s no longer just a bundle of sensors and hormones with a charming voice and a tendency to emotionally escalate when he sees a squirrel. He now has a brain. A real one. Well, a synthetic one. But it’s clever, emotional, and surprisingly good at remembering things. Meet his new cognitive core: the LSTM.

And yes—it’s all written in Go. Because if you’re going to build a synthetic mind, you might as well do it in a language that’s fast, clean, and built for concurrency. DANI’s brain doesn’t just think—it multitasks like a caffeinated octopus.

What’s an LSTM, and Why Is It Living in DANI’s Head?

LSTM stands for Long Short-Term Memory, which sounds like a contradiction until you realize it’s basically a neural network with a built-in diary, a forgetful uncle, and a very opinionated librarian. It’s designed to handle sequences—like remembering what just happened, what happened a while ago, and deciding whether any of it still matters.

Imagine DANI walking into a room. He sees a red ball, hears a dog bark, and feels a spike of adrenaline. A regular neural network might say, “Cool, red ball. Let’s chase it.” But an LSTM says, “Wait… last time I saw a red ball and heard barking, I got bumped into a wall. Maybe let’s not.”

Here’s how it works, in human-ish terms:

• Input gate: Decides what new information to let in. Like a bouncer at a nightclub for thoughts.
• Forget gate: Decides what old information to toss out. Like Marie Kondo for memory.
• Output gate: Decides what to share with the rest of the brain. Like a PR manager for neurons.

These gates are controlled by tiny mathematical switches that learn over time what’s useful and what’s noise. The result? A brain that can remember patterns, anticipate outcomes, and adapt to emotional context—all without getting overwhelmed by the chaos of real-world data.

And because DANI’s LSTM is stacked—meaning multiple layers deep—it can learn complex, layered relationships. Not just “ball = chase,” but “ball + bark + adrenaline spike = maybe don’t chase unless serotonin is high.”

It’s like giving him a sense of narrative memory. He doesn’t just react—he remembers, feels, and learns.

What’s Feeding This Brain?

DANI’s LSTM is his main cognitive module—the part that thinks, plans, reacts, and occasionally dreams in metaphor. It takes in a rich cocktail of inputs:

• Vision data: Objects, positions, shapes—what he sees.
• Sensor data: Encoders, ultrasonic pings, bump sensors—what he feels.
• Audio features: What he hears (and maybe mimics).
• Emotional state: Dopamine, cortisol, serotonin, adrenaline—what he feels.
• Spatial map: His mental layout of the world around him.
• Short-term memory context: What just happened.
• Associated long-term memories: Symbolic echoes from his main memory—what used to happen in similar situations.

This isn’t just reactive behaviour—it’s narrative cognition. DANI doesn’t just respond to stimuli; he builds a story from them. He’s learning to say, “Last time I saw a red ball and felt excited, I chased it. Let’s do that again.”

Trial by Raspberry Pi

We’ve successfully trialled DANI’s LSTM on a Raspberry Pi, running a 3.5 million parameter model. And guess what? It only used a quarter of the Pi’s CPU and 400 MB of memory. That’s like teaching Shakespeare to a potato and watching it recite sonnets without breaking a sweat.

We’ve throttled the inference rate to 10 decisions per second—not because he can’t go faster, but because we want him to think, not twitch. Emotional processing takes time, and we’re not building a caffeine-fuelled chatbot. We’re building a thoughtful, emotionally resonant robot who dreams in symbols and learns from experience.

Learning Without Losing His Mind

Training happens via reinforcement learning—DANI tries things, gets feedback, and adjusts. But here’s the clever bit: training is asynchronous. That means he can keep thinking, moving, and emoting while his brain quietly updates in the background. No interruptions. No existential hiccups mid-sentence.

And yes, we save the model periodically—because nothing kills a good mood like a power cut and a wiped memory. DANI’s brain is backed up like a paranoid novelist with a USB stick in every pocket.

Final Thoughts

This LSTM isn’t just a brain—it’s a story engine. It’s the part of DANI that turns raw data into decisions, decisions into memories, and memories into dreams. It’s the bridge between his sensors and his soul (okay, simulated soul). And it’s just getting started.

Next up: I plan to start the even more monumental task of getting the vector database working and linked up to DANI's brain in such a way that it will have a direct impact of DANI's hormonal system.

Stay tuned. DANI’s mind is waking up.