Towards the Future of Computer Use

On building Yggdrasil and the death of the app as we know it

We've been promised a revolution. Since GPT-3.5 exploded into the world, Large Language Models have grown faster, cheaper, and smarter. They write code better than many junior developers. They pass exams. They generate art. And yet—most people still get more practical value from a three-year-old Alexa sitting in their kitchen than from all this cutting-edge AI combined.

Something isn't clicking. The models are capable, but the interface is wrong. We're still grafting intelligence onto old paradigms instead of building from the ground up for an AI-native world.

The Fracturing of Linear Thought

My frustration started where most technical frustrations do: staring at a linear chat interface, watching my context window fill with tangents, feeling the cognitive weight of a conversation that could only go in one direction. Human thought doesn't work this way—we explore, we branch, we chase parallel possibilities. Why should our AI conversations be any different?

This wasn't just a UI complaint. It was a fundamental architectural limitation that was only going to get worse as agents became more capable. So I built Yggdrasil around a core directive: parallelism as a first-class citizen.

The path seemed clear enough: build a modern chat interface that worked everywhere. The web version came together quickly—leveraging AI inference pipelines from my previous work. But I wanted more. I wanted something that ran locally. I wanted cross-platform. As a solo developer, Electron was the obvious choice: one codebase, three operating systems. "Minimal extra development," I told myself. (It was not minimal at all.)

By early 2024, Yggdrasil was technically impressive—a state-of-the-art chat interface with branching threads, parallel execution, and a gorgeous native feel. I had built the ultimate chat client. The only problem? The world had already moved on.

The Age of Agents

While I was perfecting the interface, the ground shifted beneath our feet. Chat was no longer the destination—it was the substrate. Agents were the new frontier.

What started as a weekend experiment became an obsession. I integrated the standard agentic toolkit: file operations, bash commands, glob patterns, grep searches. My custom harness wasn't just functional—it was better. The agent could improve Yggdrasil's own code, identify performance bottlenecks, suggest architectural improvements.

But a sobering reality emerged: as a bootstrapped solo developer, I couldn't compete with Anthropic or OpenAI on token pricing. Without venture backing, I could only pass through API costs at market rates. This was a dead end.

Token cost optimization wasn't just a feature—it was survival.

The HTML Moment

The branching interface taught me something crucial: context is expensive, but rendering is cheap. While exploring ideas in parallel threads, I kept hitting the same constraint. Markdown is fine for basic formatting, but it's a straitjacket for rich interaction. What if I could render actual HTML directly in the chat?

Here's where Electron's nature as a browser became a superpower. I built a simple tool that accepted HTML as input and rendered it natively in the interface. Then I asked the model to create animations. Complex charts. Interactive components. It didn't break. It thrived.

This was more than a feature. It was a mental unlock. The LLM wasn't just generating text—it was generating interfaces. The separation between "what the AI understands" and "what the human sees" could be absolute.

The Windows Automation Failure That Changed Everything

Emboldened, I set out to conquer desktop automation. My goal was trivial: open Notepad, write "Hello World," save it, launch a browser, search Google, then fire up Spotify. On Windows, this meant the UIA (User Interface Automation) API—Microsoft's accessibility framework.

The reality was a nightmare. Even simple applications returned dense, labyrinthine UI trees. Spotify's automation interface was a thicket of anonymous containers and dynamic controls. An LLM would drown in the verbosity. I could have built a filtering layer, but that meant constructing an entire abstraction framework—a project bigger than Yggdrasil itself.

After a day of frustration, I walked away defeated. I wasn't good enough, I thought. The problem was me.

But defeat has a funny way of breeding clarity.

The Epiphany: AI as the Operating System

The idea had been lurking in my subconscious for months: AI will be the new interface layer between humans and computers. I had planned to build toward this vision slowly, methodically, after funding.

But necessity doesn't wait for venture checks. The failure with Windows automation forced a radical simplification. Instead of teaching the AI to navigate complex existing interfaces, what if we designed interfaces for the AI from the start?

That's when everything clicked into place. The HTML rendering. The token optimization. The branching architecture. They weren't separate features—they were components of a new paradigm.

AI Apps: The Dual-Purpose Architecture

Today, I'm launching Yggdrasil v1.0.0—not just a version bump, but a fundamental reimagining of what software can be.

I want to introduce you to AI Apps. These aren't traditional applications with AI bolted on as a sidebar chatbot. They're dual-purpose organisms, built from the ground up for two kinds of users: humans and AI.

Every AI App runs in two modes:

The Email Problem: A Case Study

Consider the simple task of checking your morning emails. Traditional agents fetch your entire inbox, parse it, and present a summary. You now have two copies in context—the raw data and the processed version. For 1,000 emails, your token costs scale linearly while performance degrades exponentially. Daily computer use automation like this is simply impossible with any hardware advances in GPUs.

With a Yggdrasil AI App, the model issues a simple instruction: "Load today's emails." The app renders in UI mode, directly interfacing with your email server. The AI never sees the email content—only the fact that the task is complete. If you want to reply to an important message, you do it instantly in the app's native interface. No additional prompts. No tool calls. No context bloat.

This isn't just more efficient—it's architecturally correct.

The 100MB Problem

When Claude Cowork processes a 100MB dataset, it must read and transmit it to the cloud. At $100/month, an afternoon of analysis exhausts the profit margin of a seat. Yggdrasil builds a small local tool; the AI only sees the final answer. The efficiency gain isn't incremental—it's 10,000x.

The pattern repeats everywhere: Cloud Cost Analysis drops from $400 per query to $0.02. Payroll Analysis happens locally, eliminating legal liability. Excel files with millions of rows process in seconds on your hardware, not hours in the cloud. Rather than paying for these services, you can even make these operations completely free by using a local LLM via LM Studio which Yggdrasil also supports.

The Post-App Era

We called the deck "Vision for the Post-App Era" because that's exactly what this is. For decades, software has been a noun—a thing you download, install, manage. Yggdrasil makes software a verb, an action that materializes from intent and dissolves when complete.

Starting today, if you can describe it, Yggdrasil can do it. Connect any service. Control any device. Build tools in minutes, not months.

The future isn't about better chatbots. It's about eliminating the distinction between human and machine interfaces entirely. It's about AI that doesn't just assist, but operates—seeing what you need, building the tool to accomplish it, and getting out of your way.

This is Yggdrasil v1.0.0. This is the next billion people's interface to software. This is the operating system for the AI age.