What If an AI Agent Was Just a Tiny Container?

I started building Spore because my AI agents were getting too big.

Not intellectually big. Literally big.

At the time I was building agents in TypeScript. Each agent was its own application with a Node environment, dependencies, framework code, tool plumbing, and everything else needed to make the thing run.

Then I'd put all of that in a container.

That made sense when I thought of an agent as an application. But the more agents I built, the stranger it started to feel.

Most of what made one agent different from another wasn't the application code.

It was the instructions.

So I started wondering how much of the rest I could get rid of.

The basic idea behind Spore was pretty simple.

I wanted a tiny generic runtime that knew how to run an agent, but didn't know what agent it was running.

The actual agent would be defined by a Markdown file.

Conceptually:

tiny runtime
    +
agent.md
    +
configuration
    +
tools
    =
running agent

If I wanted a different agent, I shouldn't need another TypeScript project.

I should be able to start the same runtime, mount a different agent.md, inject whatever configuration it needed, and let it go.

The Markdown file would define the agent's purpose and instructions.

The runtime would provide the machinery required to execute it.

I liked that separation.

I've spent a lot of my career building distributed systems and microservices, so I naturally started thinking about agents the same way.

Instead of creating one large agent responsible for everything, I wanted small agents with narrow responsibilities that could be spawned when they were needed.

And I wanted to run them in Kubernetes the same way I'd run other services.

The difference was that these things should be tiny.

My goal was to keep an agent image under about 5 MB.

There shouldn't be a Node runtime and a large dependency tree inside every agent container. There shouldn't be a bunch of framework scaffolding repeated across every image.

Just enough runtime to execute the agent.

That meant starting an agent could be cheap:

router
  │
  ├── spawn container
  │
  ├── mount agent.md
  │
  ├── inject configuration
  │
  └── attach tools
         ↓
     running agent

If the runtime is tiny and the image is already available on the node, there's very little standing between "I need this agent" and a running process.

That was the part I wanted to explore.

Once I started stripping things out of the agent itself, tools became another obvious target.

I didn't want every agent image containing implementations for everything it might need to do.

I wanted tools to be configurable.

An agent might have access to a streaming MCP tool:

agent → MCP → tool

or something exposed through a normal REST endpoint:

agent → HTTP → service

The agent definition determines what it can use.

The runtime knows how to communicate with those capabilities.

The implementation doesn't have to live inside the agent.

That made the agent itself even less interesting from a deployment perspective, which was exactly what I wanted.

The next question was how to compose them.

If I have a bunch of tiny specialized agents, something needs to decide which one should handle a task.

So I started thinking about agent routers.

A request could come in, a router could determine which kind of agent was appropriate, and the system could spawn or route to that agent.

For larger processes, I was also thinking about durable workflows.

Instead of making one agent responsible for an entire process:

do everything agent

I could eventually have something closer to:

workflow
   │
   ├── agent A
   │
   ├── agent B
   │
   └── agent C

The workflow owns the durable process.

Each agent owns a small piece of work.

I still think there's something interesting in that model.

At the time, I wasn't thinking of Spore purely as a side project.

I thought there might be a business in it.

I had the domain aeoniq.io and was considering building a hosted platform around the idea.

Define an agent, attach its tools, and deploy it without having to build and operate all of the infrastructure around it.

Routers and workflows could compose those agents into larger systems.

That was roughly as far as the business idea got.

I never reached the point where I knew whether anyone actually wanted to buy it.

I was still figuring out whether I liked the architecture.

According to the Git history, I started Spore on March 17.

We left for vacation on March 20, and I kept working on it through March 23.

Then I stopped.

There wasn't some important technical failure that caused me to abandon the idea. I didn't do a bunch of customer discovery and conclude there wasn't a market. I didn't prove that micro-agents were a bad architecture.

I was on vacation and something else got my attention.

From the 23rd through the 27th, I had a new side gig and spent some time creating UI mockups from my phone while sitting by the pool or on the beach.

That was fun.

Then on March 27 I found a Pokémon database.

So naturally I started building a custom Pokémon battle app for my son and me.

The next day I made it work on mobile.

Then we drove home.

That was pretty much the end of my Spore development sprint.

I didn't touch Spore again until June, when I came back, added an MIT license, cleaned up the README, and did some work to make the repository presentable.

I still haven't really answered the original question.

I still think small, specialized agents that are cheap to create and dispose of are probably useful.

I still like the idea that an agent can be mostly declarative rather than another application that needs to be built and maintained.

I still like separating the runtime, instructions, tools, routing, and workflow concerns.

What I don't know is whether that needs to be a platform or a company.

I also don't have enough evidence to tell you that micro-agents are a better architecture than larger general-purpose agents. I built Spore far enough to explore the idea, not far enough to prove it.

A couple months later I started working on a separate project called Spore Core after becoming interested in a different question: what should an agent harness actually look like?

Despite the name, Spore Core didn't grow out of Spore. I eventually intended to bring that work back and replace Spore's existing agent implementation with my own harness, but that's a different experiment with a different origin.

Maybe I'll get back to Spore eventually.

That's usually how these things work for me.