How Bishop Actually Started: Five Agents and One Expensive Night

In the last article I said AI works for me because I built it around the way I already work, rather than the way everybody else said it should be worked.

This one is about what that actually turned into.

It’s called Bishop. It isn’t a prompt, and it isn’t a product. It’s a harness: a set of agents with defined roles, hard rules about what each one is allowed to touch, and a review path between them. And it started a lot smaller than it sounds.

I Got Lucky With the People Around Me

I mentioned last time that I’m surrounded by good developers. CTOs, system administrators, infrastructure people. That helps.

But the more useful luck was being surrounded by people who adopted AI early and weren’t developers at all.

My brother’s background is psychology. A business colleague of mine comes from the marketing side. Both of them went at AI hard and early, from prompt engineering through to genuinely extensive workflows.

Because they weren’t thinking about code, they were thinking about behaviour. How you get a model to actually hold a role instead of drifting out of it. How you frame a task so the output is usable rather than just impressive. How you chain steps together so a process survives contact with reality.

I got to watch that, argue about it, and borrow from it. Then I took it back to the development side, where the consequences are a bit more literal.

A badly framed marketing prompt gives you weak copy. A badly framed development prompt gives you code that ends up on a live site.

Why It’s Called Bishop

I’m a huge Aliens fan. It’s one of my favourite franchises, and Bishop is the synthetic in the film.

He’s calm. Neutral. Clinical. Never hurried. Very dry sense of humour. Never loud.

Less volume, more precision.

That became the base personality for the whole harness, and it wasn’t decoration. Tone changes behaviour.

Bishop leads with the finding rather than the flourish. It doesn’t assume. It protects the codebase before it worries about looking clever.

And that’s the part that matters most. Almost everything written about AI is about making it faster. The point of the Bishop personality was to slow the agent down.

Quick answers were never my problem. Quick answers are exactly how you get confidently wrong code.

The First Two Agents

I built the first two together: an orchestrator and a developer.

The separation was the idea. I wanted the orchestrator to plan, and only plan.

Its non-negotiables:

It never writes code.
It never edits files.
It never executes commands directly.

It isn’t blind, though. It has web search. It can read the codebase and gather what it needs to build a sensible plan. It just can’t act on any of it.

It’s a delegator. That’s non-negotiable.

I’ll be honest, it took me a while to get that written correctly. Models want to be helpful, and helpful looks like doing the work. It kept quietly taking over tasks it was supposed to hand off. Getting that rule to actually hold was one of the first real pieces of work in the whole thing.

Then the developer, which does the actual work. I gave it a coding skill, a documentation skill, and a WordPress development skill.

That last one carries a lot of weight, because most of my work is WordPress: themes and plugins for clients, and my own plugins. A general coding model knows PHP. It doesn’t know how this platform expects you to behave.

The Planner Shouldn’t Mark Its Own Homework

This worked. Tasks went out, work came back.

But the orchestrator was the one checking the work, and that just didn’t make sense. The agent I’d deliberately built so that it never touches code had somehow become the last line of defence on code quality.

There was a second problem too, and it was a practical one. Everything was running on very capable models. I was getting good answers, but they were getting expensive.

So I added a code reviewer, and it solved both problems at once.

The reviewer is much more structured than the developer. It looks at WordPress security. It checks that best practice is being followed, that the documentation is complete, that nothing obviously nasty has been introduced. It tests rather than trusts.

And once it existed, I could rebalance the models. I lowered the model on the developer and raised the model on the reviewer.

A cheaper agent produces, an expensive agent judges.

That costs less than one expensive agent doing both jobs, and the output was as good or better. Reviewing is where careful reasoning actually earns its money.

I also had to give the reviewer a sense of severity, because a reviewer that blocks on everything ships nothing. Critical issues get sent straight back. Warnings get noted and the work continues.

That feedback loop worked well. Which is a nice thing to say right before the part where it didn’t.

The Night It Ate All My Tokens

I set it running one night on a task and left it to work.

It got stuck. Developer to reviewer, back to developer, back to reviewer. Hundreds and hundreds of rounds. It burned through my tokens very quickly and produced nothing I could use.

Nobody has to teach you that lesson twice.

And the fix wasn’t a better prompt. This is the bit I’d underline for anybody building something similar. A loop is not a prompting problem. It’s a structural one.

Junior Dev, Senior Dev, and a Hard Limit

So I split the developer role in two: a junior dev and a senior dev.

The senior dev can never be called directly. Everything enters through the junior.

Then the rule that mattered: no more than two junior dev rounds. Junior dev to code reviewer, back, junior dev to code reviewer again. If it still isn’t right after that second pass, it escalates to the senior dev, which has access to more tools and a stronger model to work the problem properly.

Two wasn’t a guess. Most tasks were already clearing the junior and reviewer on the first pass, and that path is cheap. Two rounds gives an honest second attempt without letting anything spiral.

I’ll be honest, the senior dev does get called every now and again. But with the two-round limit in place it seldom gets that far.

Which turned out to be the real value of escalation. It’s more useful as a ceiling than as a workhorse. Its main job is to end the loop.

The Fifth Agent: Someone to Write It Down

The last one I added was a document writer.

It writes the context and progress documents, and it reports back to me through Discord, so I could see what was actually going on without sitting and watching a terminal all evening.

That agent is also where the next problem came from. Once something is writing down what happened, you very quickly start asking why none of it carries forward. That’s the memory question, and it’s the whole of the next article.

The Five Core Agents

Orchestrator — plans the work and delegates. Never writes code.
Junior dev — does the work. The only way into the development path.
Code reviewer — reviews and tests the work. Security, best practice, documentation.
Document writer — writes context and progress, and reports to Discord.
Senior dev — escalation only, after two failed junior rounds.

Sitting underneath those are the skills: coding, code review, documentation, junior coding, senior architecture, and a specific WordPress development skill.

That’s the core, and it’s the part I keep coming back to. I’ve expanded it, contracted it, added things and stripped things out again, and I always end up back at those five roles and the rules about how they talk to each other.

Take It and Break It

The repo is here: Bishop on GitHub.

Please use it. Read the agent definitions, look at where the hard rules are, and see how it behaves for you.

And then change it. That was the whole point of the first article. This is what shaping AI around my process looked like, with my platform, my clients, and my instincts about where things go wrong. Some of that will fit you and some of it won’t.

Take what’s useful. Throw out the rest.

Next up: Bishop’s memory. Five agents that forget everything between tasks will only take you so far, so the next article is about how I organised memory for the harness, what gets stored, what gets thrown away, and how the agents actually use it.