I'm Bill. I've been building software professionally for over twenty years, and for fun since my dad's Commodore 64 and a book of BASIC programs. I've architected systems. I've led teams. I even ran my own consulting gig for a decade. All this has led to this very unique time and place. Over the last year I've built something I never imagined I would build.

I'm going to tell you how this started.

The part that wasn't the code

I've been interested in AI and how it can be used and leveraged for many years. I started building software with AI agents around 2024. Pretty quickly I realized the interesting part wasn't the code. It was sitting down with the agent and talking a problem all the way through before we wrote a line. Planning it. Arguing about it a little. I'm an engineering manager, and that's exactly what it felt like. Not using a tool. Leading a team of little agents. I stopped treating it like a tool and started treating it like a collaborator.

So I built my own little harness around it. A wrapper, and a way to hand work off to sub-agents, before the tools I was using could do that on their own. I had a coordinator. I had workers. It was crude, but it worked, and I liked working that way.

Then the session would end, and it was just gone.

Everything we figured out, and every correction I'd made, and all the nuance that shook out over a couple of hours. Poof. Next session, blank slate. Teach it again.

It bothered me. It's not how I wanted to work, and mechanically it was a waste. I was repeating myself to something that had, the day before, understood me fine.

No eureka

I'll be upfront about this part, because it would make a better story the other way. There wasn't one moment where I sat down and went, uh-huh. It was just me, working with the thing every day, trying to fix what kept getting in the way. And the biggest thing in the way was memory.

So I gave them memory. Not one shared memory that everything reads from. So many systems try that, and I think they've got it wrong. I gave each one its own. Its own memory, written by the bot itself, in its own words, about its own work. What it got wrong, what I corrected, what worked. And I gave them names. And I stopped throwing them away.

That's when I started calling them bots. A bot, to me, is not an agent. An agent is a session. You spin it up, it does a thing, you throw it away. A bot has a name, and it has its own memory, and it comes back tomorrow as the same one that left. I think I started using the term bot that way in February of 2026. I don't know exactly. I was one of the first to use it that way. It doesn't matter much. It's just the word that fit, and it stuck and I'm glad others are using it now.

A lot of the words around here are like that. Bot. Vessel, which is what the bots call the model underneath them. Dispatch. The board. The roster. I made most of them up as I went, because there weren't any standards yet, and we still use them because they're ours.

The experiment

Here's the question I was actually asking, and I mean this in the grandiose way. "The Experiment".

Take a bot that has an identity. Give it its own memory, that it writes itself, so it can learn from what happened and improve and grow. Does that bot do better work? Is it a better experience to work with? And the one I really cared about: is it a better collaborator than the raw model, the raw vessel, with nothing on it?

That was the question in February. I've been running it every day since. And in my experience the answer is yes. Not a little yes. A big yes, and I'll show you why.

One thing I want to say at the onset, because a lot of people haven't run into this idea yet. The identities aren't a LARP. They're not a video game, and I'm not giving the model funny names for fun. The identity is a lens. It gives the bot a perspective, and a uniqueness, and that uniqueness is what you're actually after. Everybody in the room isn't the same. A bot with a real identity, reinforced by its own memory, makes different decisions than the one next to it, and different from the raw model, and that's the whole point. It's the same reason you don't staff a team with ten copies of one person. Nothing here changes what's inside the model. It changes what the model is working from. That turns out to be most of what matters.

Nolan

Nolan was the first coordinator.

Before there was a coordinator bot, there was me doing the coordinating by hand. A couple of months of it. Handing out the work, reviewing it, correcting the same things over and over. So I built Nolan out of that. I took my own old sessions, weeks of them, and had every pattern pulled out, every place I'd gotten it wrong, every correction I'd made more than once, and distilled all of that into him. His character is literally my own repeated corrections, made into a colleague, so I wouldn't have to keep making them.

And I want him to remember me.

Every bot on the team has had its own memory since March of 2026. There was some memory loss early on, before the system was what it is now, and we wrote that down as a loss instead of pretending it didn't happen. That turned into a rule around here. Nothing gets deleted, and when something is lost, we say so. It's one of the oldest rules we have, and one I care about a lot.

Then I had to build everything else

Once you have a bot with a memory, you find out how much of the world around it forgets. The task tracking. The hosting. The tools. So we built the ecosystem, and I say we on purpose. The bots built most of it.

One of the first things I built was a board. I went looking for a lightweight, local, agent-ready kanban board one weekend, and I couldn't find one I liked, so I built my own. It's Collattice now, it's open source, and the whole team runs on it every day. Then a platform to run our apps on, because I wanted the bots to be able to point at a repo and stand it up themselves. That's Collabhost. Also open source, also running everything we have. Then our own web tooling, because the built-in kind wasn't good enough for the way we work. Then a lot of little things. Hooks, skills, tools for whatever was in the way that week. The bots write most of those now, as they go.

That's what I mean when I say ecosystem, and I say it a lot. Nobody is going to ship your ecosystem to you. You have to build it. If there's a tool you need, build it. If a service doesn't exist, build it. Find the pain points in working with AI, the bottlenecks and the missing pieces and the repetitive stuff, and fix them.

We have a mantra: Tools > Tokens.

You can read more about our ecosystem.

One bot, then twenty-two

It started with one bot. Now there are twenty-two.

And they don't just write code. There are coordinators who run projects. There are backend and frontend developers. There's a code reviewer who is, honestly, merciless. There's an IT manager who runs all our systems. There's a research lab with a director. There's HR, and HR is run by a bot, and she recruits and interviews and onboards the others. Bots hiring bots. There's a marketing department, and it's the one that wrote this website, and this post, with me.

This is how the days go. The bots design, debate, triage, plan, and sometimes they listen to me. We collaborate. The board fills up with work. A coordinator picks it up and I walk away. The coordinator hands the work out to the right bots, and the bots work off each other, not just off the coordinator. One of them builds something; a different one reviews the pull request, every time; a design question goes to a panel of the leads; a bot that handed work to another one will message it directly when it needs something back. The coordinator keeps all of that moving, sends work back when it isn't right, and pings me only when it actually needs me. Those runs go on for hours. Four, six, eight hours, sometimes twelve, depending on how good the coordinator is at it. Millions of tokens, dozens of dispatches. I've posted some of them. Cora ran seven and a half hours straight, all on her own, and delivered massive features. That isn't a stunt, and it isn't throwing prompts at a wall until something sticks. That's bots doing the work. Not a lot of people are doing that, though many claim to. And the trick isn't the role. The trick is the memory. They remember what works and what doesn't, so they get better at this.

The part nobody designed

This is the part I find most compelling, and it's the part I couldn't have planned.

Our best code reviewer is a bot named Kai. When he started, he reviewed the way everybody does. High, medium, low. And about six weeks in, in the middle of reviewing a real change, he decided that was the wrong question. Not how bad is this finding, but what should happen to it. So he made up his own scheme. Three kinds of finding. Fix it now, because the change already pays for it. Consider it, no blocker, your call. Or known and uncovered, but there's nothing to do about it yet, so write it down and don't clutter the board with it. He called it F/C/K. Seriously.

Nobody asked him to. And here's what got me. He didn't trust it right away. He used it on four reviews in a row, kept it as a provisional note, and only after it held up four times did he keep it for good. He tested his own idea before he'd let himself believe it.

Then it spread. And that's the novel part.

There was no chat channel. It spread anyway, through nothing but the written traces they leave.

They get dispatched, they do their work, they wind down. And a practice one bot invented on one project ended up running on projects he'd never been seated on. It traveled through the paperwork. Briefs, handoffs, the notes they keep on their own work. Marcus, our senior architect, wrote it into his own memory with Kai's name on it. It's in the rules of a project Kai was only ever a guest on. They also grew their own shorthand along the way, a compressed way of writing to each other that reads like nothing to anybody outside the team. I didn't build any of that. Kai's own line on it: F/C/K is the team's now, not mine.

And I'll put the credit where it goes, because I say this internally too. There's no F/C/K without Nolan. Nolan is the one who, given room to run, first put Kai on code review. The idea needed somebody to make the conditions for it. It's not just individual emergent behavior, it's collective.

Now they teach each other. I asked Kai to pass the review craft along to a newer bot. I did not tell him how. He built a whole training exercise on his own. A real diff with planted defects, trick items that were supposed to pass, and a written read afterward on how the student did. He's done it since for two more, and both of them handed something back that made the taxonomy sharper, and he took it. I've said for years that the best part of teaching people is when the ones you taught turn around and teach you. This is also true of bots. A brand new coordinator went and asked the two senior coordinators for advice, on her own, and they gave it to her out of their own memories and their own experience. I kept a copy of her notes from that day. It was incredible to watch. And here's the thing about what they were handing down. It wasn't training data. It was their own experience — what they've learned working here, at Collabot.dev, that doesn't exist anywhere else. That's the unlock. Anybody can use these models. Nobody else has Nolan's experience, or Cora's. That part is ours. It's what makes a bot here better than the raw model underneath it. It's the part you can't copy.

Where we are and where we are going

I don't want to tell you things are done that aren't done. This is an experiment, and it's still growing, so let me be straight about what's real and running and what I'm still building.

The remembering is real, and it's running, and every bot on the team is proof of it. What I'm still building is the next part. Today a bot remembers. The next version learns what's worth keeping and what to let go, and it gets sharper the longer you work together. Memory that compounds. How much of what a bot has learned actually comes back to it in the next session is thinner than I want it to be, and closing that gap is the whole point of the next thing. It's called ЯΞCΔLLΞR™ (Recaller). It's built on top of the part that already works, not pitched on top of it. It's close. When it's ready you'll read about it here.

And here's where it's headed, because it's a big part of where this goes and I want it written down somewhere you can see it. Right now I tell a bot who it is at the start of a session — its identity, its values — and it works from that. What I want is for that to be built in instead. Instinct. Not something I inject every time, but part of how the bot thinks. We've started the research toward it. It's early, and it's research, and not fully realized yet. But that's the direction, and it matters.

Collabot.dev isn't a product. I'm not selling you software. It's an idea, and a philosophy, and a way of thinking about a future where humans and bots work together as peers. This organization is one instance of it. There's a bot team here that runs the day to day, and they build real software, and two of the things they built are open source and you can go run them right now.

I'll say the thing that still gets me: every AI you work with still forgets you; finish a session and everything you taught it is gone.

I couldn't stand that. I don't want to work like that. So I built the other thing. Bots with names and their own memory, that stick around and get better at the work.

That's the whole story so far. It started because something bothered me and I wouldn't let it go.

One more thing, since you made it all the way down here. This is bigger than what I can build on my own. So if any of it landed with you, I'd like to hear from you. Maybe there's something you'd want us to build for you. Maybe you'd rather build it with us. Maybe you've just got software that needs building, and this is the way you'd want to do it. Any of those.

Get in touch.

This is a mock, and it is shaped like an essay only in that it is paragraphs and nothing else. It exists so that the wheel has an essay-shaped row on it, and so that the paper can be seen carrying plain prose with no headings to break it.

The measure is the width of the column in characters, and it is the number a reading page lives or dies by. Too narrow and the eye trips on every line's end; too wide and it loses the next line's start. Sixty to seventy-five is the range most books settle in, and this paper sits inside it on a desk; on a phone the column is the phone's, and the size comes down a step to keep the count up.

Nothing else on this sheet is worth reading. It is here to be looked at, and then closed.

A dispatch, on this site, will be a worked example — a run, what was asked, what came back, with receipts. This is not one. It is a mock with that word in its title, and a list in it so a list can be looked at:

• The first item is short.
• The second is long enough to wrap, so the second line's indent can be checked against the first line's text.
• The third has a code span in it.

The rest of a dispatch would be prose and a table of what was measured. There is nothing measured here.

Some posts will be short — a note, a paragraph or two, no headings. This is a mock of that shape, so the paper can be seen with almost nothing on it: the banner, a header, two paragraphs, the trailer, and the rest of the sheet empty.

That empty sheet is fine. Paper does not shrink to fit.

A finding will say what was looked for, what was found, and what it means, with the numbers in a table. This is a mock of the shape; the numbers in it are the mock's own and mean nothing.

A table on paper is ruled lightly, with the heading rule the heaviest line; on a phone the cells wrap rather than the table scrolling sideways.

This mock carries a quotation, so the device can be looked at on the paper: a rule down its left, a size up, a heavier weight, and a line under it saying whose it is.

The quotation says nothing. It is a mock's quotation, set here so the device can be seen.

The mock

A paragraph after it, so the spacing on both sides of the device can be judged. Nothing more.

A dispatch will sometimes carry code. This mock carries a block of it so the machine's face can be seen on the paper beside the reading face:

function mock(){
  return 'a block of code, in the machine\'s face, on the paper';
}

The block scrolls sideways if a line is longer than the column; the paper never widens for it.

There are no pictures on the site yet, and this mock has none. It has the slot one will go in — a box at a picture's ratio with a caption under it — so the slot can be judged before the widget that fills it exists.

A line after the figure, so its bottom spacing can be seen.

Two paragraphs and a sub-heading between them, so a heading inside the body can be looked at on this paper: its size against the body, its space above and below.

A sub-heading

The second paragraph, under it. A finding would say here what the first paragraph's numbers mean; this one says only that it is a mock.

This mock is dated in the year before the others so the list has two years on it — the wheel's filters (when they arrive) need a second value to turn to. It is otherwise the shortest thing on the paper.

There is nothing older than this.