Why AI Agents Feel Like the Next Computer

If you have followed our work, you will have noticed a pattern: we talk and write a lot about coding agents.

Not only because they are useful for writing code, although they clearly are. We are increasingly interested in coding agents because they point to a very new kind of software experience. These agent-based systems can start with a task, inspect their environment, change it, run tools, remember what happened, and gradually expand what they are able to do.

That is the magical part. The system does not just answer. It acts. And over time, it can start to feel less like a chatbot and more like an intelligent system.

Marc Andreessen gave an interview on Latent Space, where he discussed tools such as Pi and OpenClaw and drew an interesting analogy to Unix. His framing is worth writing out in more detail.

The core idea is simple:

An agent is not just a model. It is a model connected to a shell, files, memory, and a loop.

That combination is the breakthrough.

The Unix analogy

A useful analogy is the Unix mindset.

Unix, an operating system from the 60ies, was powerful because it did not try to put everything into one giant system. Instead, it privded a terminal, a shell, files, small tools and a way to chain things together.

A DEC VT100 terminal. In spirit, not so far from the machine I used during student work in the physics department. Source: Wikipedia.

That sounds simple, but it turned out to be incredibly powerful. Functionality could live in small modules. You could combine them. You could script them. You could build complex systems from simple pieces.

And Unix won. The internet runs on Unix-like systems. macOS is Unix-based. iOS and Android are Unix-derived. The shell-and-file-system model became one of the most durable abstractions in computing.

Coding agents apply a similar idea to AI. They marry the LLM mindset with the Unix shell mindset. The agent does not need a brand-new universe. It can inherit the existing power of the computer.

Agents finally became concrete

For years, “agent” was a vague term. It often meant something like “an AI system that does things,” which is not a very precise definition.

Coding agents make the idea concrete. A practical agent is a composition of familiar pieces: a language model, a Unix shell, a file system, readable state, often in Markdown, tools and command-line interfaces, and a loop that keeps the agent going.

Each component is crucial. The model gives the system reasoning and language. The shell gives it action. The file system gives it memory. Markdown makes the state readable to both humans and models. Tools and CLIs give it capabilities. The loop keeps the system running.

It turns out that this is an agent. Not a mysterious new category of software. Not a magic personality trapped inside a model. An agent is a model embedded in a working system — what is now often called an agent harness.

Why the shell matters

Lets talk about the shell. The shell is not an implementation detail. It is where a lot of the computer’s latent power already lives.

Through the shell, an agent can inspect files, run programs, install packages, call APIs, use command-line tools, invoke scripts, and operate applications such as browsers. This is why the architecture is so powerful. You do not need a special protocol for every single capability. Very often, a command-line interface is enough.

Once the agent has shell access, computer use becomes much less mysterious. Browser access is just another capability. APIs are just commands or libraries. Local files, web pages, scripts, services, and databases can all become part of one common action layer.

This is also why coding agents generalize beyond coding. Code is not only the output. Code is the medium through which the agent interacts with its environment.

The agent is just files

This may be the most important conceptual shift: if the agent’s memory, state and behaviour live in files, then the agent is not identical to the LLM.

The model becomes more like a replaceable engine. You can run the same agent on Claude today, GPT tomorrow, and maybe a local model later. The behavior may change a bit, but the important parts remain: its files, memories, and tool definitions.

That sounds almost too simple. But simplicity is exactly why the idea is powerful. Files are inspectable. Files are portable. Files are editable. Files can be versioned. Files can be copied. Files can be backed up. Files can be read by humans and machines.

Migration: agents can move themselves

If the agent is mostly files, it becomes portable.

It can move to another machine, another file system, another shell, another runtime, or another model. This is very different from traditional software, where migration is usually something humans have to plan and execute carefully.

With this architecture, the agent can potentially help with the migration itself. It can inspect its own files, understand what needs to move, adapt to the new environment, update paths, reinstall dependencies, test what broke, and continue from there.

Introspection: the agent can inspect itself

Traditional software usually cannot understand itself. It runs, but it does not really know what it is made of.

Agents built this way are different. They can inspect their own files. They can read their instructions, memory, logs, tool definitions, and current plans. That gives the system a new property: it can reason about its own structure and update parts of itself.

There have been systems that explored parts of this idea before like Smalltalk. But coding agents bring this kind of self-inspection into whole new level. The agent does not need to understand everything perfectly. It only needs enough structure to read what exists, make a change, test the change, and record what happened.

Self-extension: the real wow moment

The real wow moment is that the agent can add new capabilities to itself. Either you ask it to-do so or it does it by itself in order to achouve a task. It can search the docs, write code, update its files, test the integration, and remember the new capability for next time.

This changes the feel of software. The system is no longer only something you configure from the outside. It becomes something you can ask to extend itself.

In this example, OpenClaw has taught itself to work with voice messages. Peter didn't instruct it todo so it just used the shell and available tools to do so.

That is why coding agents are interesting beyond coding. Code is the medium through which the agent changes what it can do.

Why this matters

None of the individual components are new. Shells existed. Files existed. Markdown existed. Cron existed. Language models existed. Command-line tools existed. The breakthrough is the composition.

Like Unix, the power is in how the pieces fit together. Once you connect a model to a shell, a file system, readable state, tools, and a loop, you get something that feels fundamentally different from a chatbot. It becomes persistent. It can act. It can remember. It can inspect itself. It can move. It can extend itself.

That is why this architecture feels like such a conceptual breakthrough. It makes agents simple enough to understand and practical enough to build. And the capability unlock is enormous. It feels like the next generation of computers.

This is why we are building systems based on coding agents. They are not just developer tools. They are a practical foundation for the next computing interface.