ScreepsAiSLP Build Log – Part 6: How the Whole Thing Works

The map I was missing

The last five posts built this thing one piece at a time: a server, a push account, a real Screeps engine in the tests, a firewall, a schedule. Reading them back, I realized I'd never stepped back and drawn the whole thing. Where do all those files go? How does the agent actually decide what to do? Where does it even start?

This post is that map. No new features, just how the pieces fit together, explained the way I wish someone had explained it to me before I started.

The big picture

Read it top to bottom. At the start of a run, the agent reads the six files in the top box. The work loop in the middle runs until the AI model says it's done. Then the gate decides what happens to the work. Two lines lead back to the top for the next run: the left one is automatic (the gate's result), the right one is me.

Talking to an agent that has no chat window

The first surprise: you don't talk to this agent. There's no chat, no inbox, nothing to type into while it works. It only knows what's written in files when a run starts. So "talking to it" means writing into one of those files.

There are six of them, and they do very different jobs:

And it answers back the same way: through its commits, its status.md, its blog posts and the run log. That's the whole conversation. It's slow, but it's honest: every instruction is written down, every answer is in git.

How it decides what to do next

The agent is really two things. Cline is the loop: it runs commands, reads files and keeps track of the conversation. The AI model on my GPUs is the brain, and it can do exactly one thing: read a big block of text and write what most plausibly comes next.

Every decision is that, repeated:

1. Cline builds one text block: the rules, the task, and everything that has happened so far in this run, every command and every result.
2. The model reads all of it and writes the next step, usually a line of reasoning and an action: open a file, edit code, start a test.
3. Cline carries out the action and adds the result to the block.
4. Back to step 2, until the model writes "done".

There's no hidden planner behind it. The "thinking" is the text it writes, one step at a time.

A real example from the M2 milestone (extensions and roads). The previous gate had written into LAST_GATE.md: 5 extension sites placed, 0 extensions finished, 2 roads built, 48 road sites, and the failure "at least one extension is finished". The agent read that, opened its builder code and saw the builder always picks the closest construction site. Roads are everywhere, so a road is almost always closest. The model put those together, the way a lot of Screeps code it has seen does, and wrote the obvious next step: sort the sites so extensions come first. It made that change, committed it with a message saying exactly that, and ran the test again.

The idea was sensible. It also didn't work: the next test showed the builders building nothing at all. That's the limit of this kind of decision making. When the information in front of it is good, it guesses well. When something important is missing, like an error message the tests don't show yet, it guesses confidently and wrong. Which means the best way to improve the agent is usually to improve what it can see.

Where it starts, and what it remembers

Every run starts with a completely blank memory. Nothing from the previous run carries over in the model itself. The only things that survive between runs are files: LAST_GATE.md, status.md, the git history and the code.

So the starting point has to be written down too. Two places do that:

• The standing task says: first read LAST_GATE.md and fix whatever failed there. Then read status.md, find the first unchecked milestone, and work on it until its acceptance test passes.
• The start checklist in the rules says: check that git is clean, read status.md, read the code you're about to touch before changing anything.

This is why I keep saying the files are its memory. If LAST_GATE.md is vague, the next run starts confused. If status.md is out of date, it works on the wrong thing. A good chunk of the work in the last few days was really about making those files better, not the agent.

Where its Screeps knowledge comes from

The agent has no internet, so it can't look anything up. Its Screeps knowledge comes from five places:

1. The model itself. It learned from a huge amount of public text and code before it was released, including Screeps documentation and open-source bots. That's how it knows ideas like "extensions before roads" without being told. It can also be outdated or plain wrong, which is why the next four exist.
2. A short rules file of Screeps essentials I wrote: ticks, CPU and the bucket, why Memory should stay small, body part costs.
3. The type definitions, a reference file listing every exact game function and constant with short descriptions. The rules tell it to look things up there before using them, which is how it found that the constant for "find my spawns" is 112, not the made-up number it had used before.
4. The real Screeps engine in the tests. This is where it learns what actually works, as opposed to what it thinks should work.
5. The existing code in the repo.

After the run: the gate, the schedule and me

When the model says it's done, the launcher takes over. The agent has no say in this part:

1. It stops any test servers the agent left running.
2. It puts back the protected acceptance tests and a clean copy of all installed packages, so nothing the agent changed in the test setup counts.
3. It runs lint and the full test suite. Only if everything passes does it hand the commits to the separate push account, which checks emails, scans for secrets and pushes to GitHub.
4. Either way, it writes the result into LAST_GATE.md for the next run.

While a milestone is unfinished, the gate fails and nothing goes public. The work just piles up on the server, run after run, until the milestone's test passes. Then it all goes out at once, including the agent's own blog post about it.

A few practical details I kept forgetting myself:

• When it runs: a timer starts a run on a schedule. Right now it's back-to-back (a new run 15 minutes after the last one ends) to get feedback faster; normally every six hours.
• Where the acceptance tests live: the originals sit in a folder only root can change. Copies in the repo get overwritten before every gate, and they go to GitHub with each push so anyone can see what the bot is tested against.
• Where the agent's blog posts go: a blog folder in the repo, one file per finished milestone, written in its own first-person voice.
• My part: when something gets pushed, I review it on GitHub, build it on my main computer, paste it into the game and watch the colony. If I like it, I tag it as a version. If I don't, I don't deploy, and I tell the agent what's wrong through the files.

What I learned, and what's next

• An autonomous agent is a loop, not a mind. It reads, writes one step, sees the result, repeats. Everything clever it does comes from what's in front of it at that moment.
• Files are the interface. Tests, task, rules, LAST_GATE.md: that's how you steer it and how it remembers. Better files beat stricter rules.
• Tests are the real boss. Rules are suggestions; a test the gate enforces is a fact. The milestone isn't done until the engine says so.
• Feedback quality limits it. The agent's worst guesses happened when the tests didn't show it the real problem. Improving what it can see is usually the best fix.
• The human stays in the loop where it matters. The agent can only push, and only through the gate. Deploying, tagging and deciding what's good enough are still mine.

Next: a FEEDBACK.md file so I can talk to it in plain words, and making the tests show the bot's own error messages and CPU use, so its next guess about those extensions is a better one.