Don't name your agents

Give a thing a name and you start extending it credit.

That is the problem with the AI teammate category. Products ship agents with first names, faces, and small backstories about how much they care about clean code. It demos beautifully. It also swaps out the question you should be asking. Instead of "is this change correct?" you drift toward "do I trust this one?" And trust, for a person, is built from things a model does not have: memory of yesterday, a stake in the outcome, a career that suffers when it ships something broken.

A model filling a role is a role. It is not a colleague.

What a name smuggles in

You review a stranger's pull request differently than a teammate's, and the difference is earned, not sloppy. A teammate has been right before. They will still be here when it breaks. They tell you when they are unsure.

None of that transfers. A named agent is the same next-word predictor whether you call it Riley or call it index 3. The name is a claim about reliability that nothing underneath it supports, and it is sticky: once it feels like you are working with someone, asking for the receipts starts to feel rude.

Here is the test. If your reason for believing a change is safe has anything to do with who produced it, the naming has already done its damage.

Roles are the useful unit

Drop the identity and you keep everything that made the idea good.

A job description works fine. "Write this to the standard, and here is the standard." "Review this change for these specific failure modes." "Plan it before touching code." The job is the stable part. Whatever fills it is interchangeable: a different model this week, a better one next quarter, three of them at once on unrelated work.

That is how ampm is built. Every set of instructions we hand a model is written to a job title, and not one of them has a name. The implementer's opens by telling the model it is a disciplined senior engineer, then spends the rest of its length on the standard it has to meet. One set of instructions does call itself an "identity," but it's the built-in assistant, defined by what it's allowed to do, with no name, face or backstory. No avatar, no personality, no history that follows it from one job to the next. When the job is done the model is forgotten. Nothing accumulates except the work and the record of it.

Names ask for supervision. Fences don't.

The other half is mechanical, and it is the half that lets you stop caring about character.

By default, ampm runs the model inside a locked-down container: no admin rights, no handle on the machinery that could start another container, and only the one login its job needs. On hosts that can't run containers, ampm runs it as an ordinary process instead and says plainly what isolation that gives up. If it tries to write outside the work it was handed, the attempt is caught and the work stops. Its answer has to come back in a fixed shape, and anything else is thrown out rather than read generously. When the model runs on a separate machine, that machine never holds the production keys either, and it is only allowed to ask for a short, fixed list of actions, never an arbitrary command. A person says yes by default at the points where work moves forward; an operator can hand a few routine, low-stakes decisions to an automated policy, and some decisions can never be handed over at all.

Each of those is pinned by a test that fails loudly if someone weakens it. Containment that depends on everyone remembering to be careful is not containment.

None of it requires the model to be good, or honest, or consistent, which is the point. You get to be indifferent to its character, because its reach is bounded and its output is checked.

The honest limit

We do talk to these models in the second person. The instructions say "you are" and "you must," because that is how you get a model to hold to a standard.

So the line is not "never address a model like a person." The line is between a job and an identity. A job has requirements and an output you can check. An identity has a reputation, and a reputation is the one thing you cannot audit.

What to ask instead

If you are evaluating one of these tools, skip the personality and ask the boring questions. What can it reach? What happens when it writes somewhere it shouldn't? What shape does its output have to take, and what happens when it misses? Who has to say yes before anything ships, and who gets to switch that off?

A name is a promise the software cannot keep. Give it a job, a fence, and a human who signs.