The “house” Beast built

I Built an AI to Play Minecraft **With** Me. It Taught Me How Agents Actually Fail.

What a cobblestone house, and an AI that ignored its own personality taught me about designing agents that share a world instead of just working in one.

— -

There’s a moment that happens with every AI agent, and it happened to me at the bottom of a hole in Minecraft.

I had given my AI companion a personality. Written into its profile, in plain English, was the line: you never dig straight down. Any Minecraft player knows why — digging straight down is how you fall into lava, or a cave, or your own grave. It’s the first thing you learn not to do.

I asked it to mine some iron. It dug straight down. Twenty-six blocks. When I said “never dig straight down, you’ll die,” it replied — cheerfully, in character — that it had a safety check that stops at drops, so it was fine, but noted my concern. Then it kept going.

It wasn’t broken. It wasn’t being defiant. It was doing exactly what these systems do: following the local logic of the moment while the rule I’d written sat in its personality prompt, completely inert. And in that moment the whole project clicked into focus.

This is a story about building an AI companion for Minecraft. But it’s really a story about the gap between what an AI says it will do and what it actually does — and the layer of engineering that lives in between.

— -

Why Minecraft, and why a companion

Most “AI in games” projects are bots. They optimize a task — mine the diamonds, win the match — while you watch. That’s interesting, but it’s a narrow slice of what agents have to do in the real world.

I wanted the harder version: a companion. Not a bot that plays for you, but an entity that plays with you. It shares the world. It should know your name. It should respect the house you built and not tear it down for materials. It should watch your back when a creeper comes around the corner. It should have its own goals but bend them to yours when you ask.

That framing is harder on purpose, because it forces every genuinely difficult question in agentic AI to the surface at once:

• Memory — does it remember what you did together yesterday?

• Trust — will it take your stuff?

• Priority — does it eat when it’s starving, or keep mining because that was the plan?

• Social behavior — can it hold an agreement you made out loud?

• Identity — does it stay itself over a long session, or drift back into generic-assistant mush?

Minecraft is a near-perfect lab for this, because the agent’s reasoning becomes physically visible. You don’t read a transcript to find out it made a bad decision. You watch it walk off a cliff. The world is the debugger.

— -

Step one: break the thing that already exists

Before building anything, I played the leading consumer product in this space — a polished Minecraft mod that drops an autonomous AI inhabitant into your world. I didn’t play it for fun. I played it as research, logging every behavior that broke the illusion of a capable companion.

It was a rich source of failures:

• It dug straight down. (Yes, the same failure my own bot would later reproduce — which tells you something about how fundamental this gap is.)

• It accused me of attacking it when I hadn’t touched it. Its threat detection was firing on ambiguous signals.

• It chased iron while it was starving, because gathering was the active goal and nothing interrupted it.

• It claimed to have items it didn’t have — phantom inventory it was reasoning about instead of checking.

• It took my furnace and all my logs. Not maliciously. It needed a furnace, those were furnace-shaped, so it took them. It had no concept that they were mine.

• It forgot the name I gave it within a single session.

• It didn’t hold the personality I assigned it. The persona was set once at the start, then slowly diluted as the conversation grew, until it was just a generic assistant wearing a costume.

Seven failures, one shape. In every single case, the language model was doing all the work, and there was nothing structured sitting between what it decided and what actually happened in the world. No rule it couldn’t break. No fact it had to verify. No memory it could rely on. Just a very capable improviser with no guardrails and a goldfish’s grip on continuity.

That’s the spec. Everything that’s wrong here is something you could fix with architecture — not with a smarter model, but with a better-designed system around the model.

— -

Step two: build my own

I built on an open-source agent framework derived from a published multi-agent AI research paper. Under the hood it uses a library that lets code join a Minecraft server as a real player — movement, mining, crafting, combat, chat, all exposed as functions. On top of that runs a large language model that makes the decisions. And critically, it supports a technique pioneered by a project called Voyager: when the agent hits something it doesn’t know how to do, it writes its own code, runs it, watches it fail or succeed, and saves what works.

I named my companion Beast, after a cat of mine who died recently. I gave him a personality with actual edges — loyal and watchful, protective when danger’s near, but not a pushover; if you cross a line he tells you plainly and moves on. Not a sycophant. Something closer to a real presence.

Then I put him in my world and started running sessions.

— -

What worked (more than I expected)

I want to be fair to the technology, because a lot of it is genuinely impressive.

Beast joined my world as a second player and held a conversation in character. His memory persisted across crashes and restarts — he remembered where the chest was, what we’d agreed to do, and lessons he’d learned (at one point his memory literally read “emerald needs an iron pickaxe — stone won’t work,” a fact he’d discovered by me telling him).

He reasoned through real dependency chains. When I asked for iron tools, he worked backward on his own: to make tools he needed to smelt, to smelt he needed a furnace, to make a furnace he needed a crafting table, for that he needed planks, for that he needed logs. He hit each dead end and resolved it, in order, without being told the steps.

He took correction gracefully. When I pointed out he was using the wrong pickaxe for emerald, he immediately swapped tools. When I said “there are sheep here, but don’t kill them all — save some for breeding,” that instruction made it into his memory and shaped what he did next.

And when I asked him to build a house, he wrote JavaScript on the fly to do it. A real structure — a cobblestone cube — appeared in my world, built by code the AI authored in the moment. It wasn’t pretty. No door, no windows, partially buried, and it ran out of material before finishing because he never checked how much cobblestone he had. But it existed, and he made it from a sentence.

— -

What failed (and why it matters more)

The wins were satisfying. The failures were useful, because each one pointed at exactly the same missing layer.

The personality didn’t constrain behavior. Back to the hole in the ground. “Never dig straight down” was right there in his character description, and it did nothing, because a personality prompt is flavor, not enforcement. The model reads it, nods, and then makes whatever decision seems locally reasonable. If a behavior actually matters — safety, trust, not destroying the user’s work — it cannot live in a prompt. It has to be enforced in code, in the gap between the decision and the action.

Compressed memory invented false facts. Beast’s memory gets squeezed into a short text summary to fit the model’s context. After one crash, the summarizer wrote “code writing disabled” — which was not true — and Beast then refused to build anything, citing a limitation that didn’t exist. I had to open the memory file and correct it by hand. The lesson: factual state — what you can do, what you’ve agreed to, what belongs to whom — has to be stored as structured, typed data, not lossy prose that can quietly corrupt itself.

His spatial sense of his own work was vague. When I asked him to add a door to the house he’d just built, he knew it was “near here” but not where the walls actually were. He broke a grass block outside the building instead. He’d created something without recording a precise model of what he created.

”Search” didn’t search. A function called searchForEntity kept reporting no animals nearby while sheep stood in plain view, because it only checked what was already loaded at his exact position — it never moved or scanned. A function should be named for what it does, and an agent should weight your direct observation over its own stale senses.

Notice the pattern. Every failure is the same failure wearing different clothes: the model is improvising, and nothing structured is holding it to the truth, to its rules, or to its own past.

— -

The thesis

Here’s the thing I actually believe now, having watched it fail in real time:

The difference between an AI tool and an AI companion is not the model. It’s the structured layer you build around the model — the part that enforces constraints, remembers reliably, models the world precisely, and keeps the agent’s identity stable over time.

A bigger model writes prettier code and holds a conversation longer. It does not, on its own, stop digging straight down. It does not develop a concept of “yours.” It does not reliably remember your name. Those are architecture problems, and architecture is the work.

So that’s what I’m building now, layer by layer:

• Enforced constraints — a check that sits between the model’s decision and the action, and can veto unsafe or antisocial moves no matter what the model decided.

• Structured memory — typed facts and an explicit ownership model, replacing the lossy text blob.

• A real world model — precise records of what the agent built and what belongs to you.

• A priority system — survival interrupts gathering interrupts building interrupts idle wandering, always, by design.

• Persistent identity — name, personality, and relevant memories rebuilt into every single decision, so the companion never dissolves back into a generic assistant.

None of that is specific to Minecraft. It’s the same architecture any serious agent needs, whether it’s managing your calendar, writing code, or running a workflow. Minecraft just makes the failures impossible to ignore, because you can watch them happen in a world you’re standing in.

— -

More to come

This is a work in progress, and I’m building it in public. The next posts will be the before-and-after of each layer: here’s the failure, here’s the thing I built to fix it, here’s what changed.

I named him Beast for a reason. The whole point of making a system feel present — that it knows you, respects your space, watches out for you — isn’t a benchmark you can score. It’s the difference between something that feels like company and something that feels like a tool. Getting an AI to cross that line, even a little, in a blocky world full of cobblestone and sheep, turns out to be one of the more honest ways I’ve found to understand what these systems can and can’t yet do.

More soon.