Skillpunk Architecture: Distributed Skill Autonomy vs. the LLM Orchestrator

LLMs Call Functions. They Don't Live Alongside Them.

LLMs can call a weather API. Fetch game prices. Search the web. Impressive — until you realize every single one of those tool calls is a one-shot fire-and-forget. The model wakes up, calls the function, returns a response, and idles out. There is no persistent process. No background tick. No behavior that continues after the reply.

Ask an LLM to:

• 🎵 Play a song, wait for it to finish, then ask if you want another
• 🍕 Order a pizza, then follow up in 30 minutes to check if it arrived
• 🏔️ Monitor resort prices once a day for a week and alert you when they drop

It can't. Not because it's not smart enough — because of a hard architectural constraint: the LLM is a centralized orchestrator, and its agency dies at the end of each conversation turn.

The Centralized Orchestrator Model

Every LLM tool integration looks like this:

User prompt → [LLM] → tool call → result → [LLM] → response → idle

Tools are passive. The model is the only active agent. When the response is sent, the loop closes. There is no persistent heuristic watching the world on your behalf.

This is fine for lookup tasks. It breaks completely for anything that requires waiting, scheduling, or autonomous follow-through.

Skillpunk: Distribute the Intelligence

LivinGrimoire takes the opposite approach. Instead of one central brain managing passive tools, each skill is a self-contained autonomous unit — with its own trigger logic, its own state, and its own multi-step behavior baked in.

Skills aren't called by an orchestrator. They run every cycle and decide for themselves when to act.

class ResortWatcherSkill(Skill):
    def input(self, ear, skin, eye):
        if self.days_checked < 7 and self.is_new_day():
            price = fetch_resort_price()
            self.days_checked += 1
            if price < 80:
                self.setVerbatimAlg(2, f"Resort dropped to €{price}. Book it?")

No re-prompting. No external scheduler. No orchestration glue. The skill tracks its own state, runs on its own schedule, and alerts you when the condition hits. After 7 days it stops. The heuristic behavior belongs to the skill — not to a model trying to manage it from above.

The Architectural Split

LLMs are powerful reasoning engines. But reasoning about what to do and autonomously doing it over time are two different problems — and today's LLM architecture only solves the first one.

Skills Are the Brain

In Skillpunk architecture there is no master controller. The engine just runs the loop. Each skill is sovereign — owns its triggers, its timing, its follow-through. Drop a skill in, and its behavior runs. Pull it out, and it stops. No prompt rewriting. No orchestration updates.

And adding a skill? You literally drop a Python file in a folder:

# DLC_personality.py — drop this in /DLC and it loads automatically
def add_DLC_skills(brain: Brain):
    brain.add_skill(DaRainAlerts("pripyat"))   # monitors rain, alerts you
    brain.add_skill(DiAttentionSeeker())        # autonomous, proactive
    brain.add_skill(DiAlarmer().set_default_alarm("siren"))
    brain.add_skill(DiMicroReminder())
    # ... as many as you want

The main loop picks up any file starting with DLC_ and calls add_DLC_skills. That's the entire integration contract. No config files. No registries. No wiring. Write the skill, drop the file, it runs.

Compare that to adding a new behavior to an LLM system: new tool definition, updated system prompt, test that the model actually calls it correctly, handle edge cases where it doesn't. Every time.

That's the Skillpunk ethos: distribute the intelligence, kill the bottleneck.

Repo: LivinGrimoire on GitHub