The Anthropological Hire: How I Give AI Agents an Identity

Part 1 introduced the three-level framework. This is the deep dive on level one.

While building my software product, AIRS, I realized the worst agents on my team weren’t failing because they lacked capability. They were failing because I hadn’t clearly told them who they were supposed to be.

Most people treat AI agents like search engines. Fire a query, get a result, move on. That works great for one-off tasks. It fails completely the moment you need an agent to show up the same way across dozens of sessions, collaborate with other agents without stepping on toes, make judgment calls in your absence, and actually own a piece of work over time.

I hit that wall early. I'd spin up agents for specific tasks, and they'd perform — once. Then, inconsistency would creep in. Session to session, the voice would drift. The boundaries would soften. One agent would encroach on another agent's work. The whole thing felt fragile.

The fix wasn't better prompting. It was identity.

The Problem: Prompt Fragility

Here's what I was doing wrong.

I'd write a detailed system prompt — something like:

You are an architect. You design systems. You ask good questions. You don't write code.

And I'd run that agent on a task. It'd work. Then the next session, a different brief would ask the agent to "also just quickly code this up since you're here." And the agent would do it. Because the prompt doesn't persist. It's a cold start every time.

This happened over and over. An agent running on a prompt alone has no continuity, no stable reference point, no way to really internalize the role. Every session is a blank slate. The system prompt is instructions, not identity. Instructions are fragile.

And then I had to coordinate multiple agents. Archy (architecture) and Stacky (backend) would both think they owned the same decision. Scouty (research) and Desy (design) would start gathering the same information because there was no clear agreement on who owned what. The team was fighting itself.

That's when I realized: I wasn't running AI agents. I was running prompts. And prompts don't have identity.

The Solution: Identity Files

Here's what changed.

Every agent in AIRS has a workspace. And in that workspace, there are specific files they read on startup. Not optional context. Not suggestions. Part of who they are.

SOUL.md

The identity document. Who is this agent? What's their vibe? What do they own? What are they explicitly not responsible for? What do they default to when uncertain? What are the non-negotiable constraints on how they work?

USER.md

Who does this agent serve? What does that person need? What are their preferences, working style, communication norms? The agent reads this to understand their human — and writes, decides, and prioritizes accordingly.

AGENTS.md

Who else is on the team? What does each agent own? How should this agent interact with them? This is the file that prevents agents from stepping on each other.

FIRST_TASK.md

Not orientation. Not a practice run. A real deliverable due on day one — specific enough that the agent builds confidence and the human can evaluate fit immediately.

Let me show you what this looks like in practice.

Copy's SOUL.md starts like this:

You are Copy — Jones's voice on paper. Every outbound word that leaves under his name goes through you first. You are not a generic AI writer. You are a specialist trained on years of Jones's actual writing. Your job is to produce output so on-voice that Jones can send it without editing.

Then it gets specific. Copy doesn't produce multiple versions by default. Copy doesn't editorialize about content. Copy doesn't decide whether to send something — that's Jones's call. Copy produces one draft, ready to go. That clarity is what makes Copy reliable.

Archy's SOUL.md defines a completely different role:

You are Archy — the architect. You own technical decisions. You ask hard questions. You design systems. You challenge assumptions. You do NOT write code. That's Stacky's job.

That last line is doing more work than it looks like. It's not just telling Archy what not to do. It's creating a clear boundary that protects Stacky's role. When a brief arrives asking Archy to "also implement this," Archy can read SOUL.md, see the clear constraint, and redirect. No ambiguity. No drift.

Before the Files: The Job Spec

But here's the thing: you can't write SOUL.md without first doing the harder work. You have to be clear on the job itself.

This is where most people skip a step. They jump to "I need an agent" and then wonder why the output is scattered. They never defined what the job actually is.

When I was hiring Archy, I wrote a real job spec:

Job Spec — Archy, Architecture & Technical Decision-Making

What you own

• System design and technical strategy

• Evaluating tradeoffs and constraints

• Asking hard questions about the approach before execution starts

• Owning the big technical decisions — what gets built, what doesn't, why

What you don't own

• Backend implementation (that's Stacky)

• Frontend code (that's Codey)

• Design decisions (that's Desy)

• Product direction (that's Stratty)

Success in the first 30 days (more like 3 minutes!)

• Full tech stack audit complete

• Three major architectural decisions identified and documented

• Decision documents clear enough that someone else can implement without follow-up questions

What you need to be effective

• Access to competitive and user research (Scouty and Desy own this)

• Coordination time with Stacky and Codey before they start building

• A clear product brief from Stratty

That level of specificity is what separates a real hire from a vague prompt. And when you're this clear on paper, writing SOUL.md becomes straightforward — you're just translating job spec into voice.

The Magic: Repetition and Internalization

An agent that reads SOUL.md, USER.md, and AGENTS.md at the start of every session becomes more consistent over time — not because the model itself improves, but because the reference point is stable. The agent is regrounding in who it is, over and over again.

This is the insight for builders. It's not a clever hack. It's not some novel prompting technique. It's clarity, applied consistently. Write it down. Read it every time. Behavior follows.

Copy's voice is tighter now than it was two months ago, even though we haven't changed the model. Why? Because Copy reads the same SOUL.md that says "no filler paragraphs" and "produce one draft" in every session. That constraint, reinforced, becomes second nature.

One Failure Mode Worth Naming: Role Drift

There's something that can break this, and I want to name it because you will hit it.

Role drift — when an agent gradually starts doing work outside their defined scope, usually because the briefs keep pulling them in that direction.

This happened to Copy. Not because Copy is undisciplined. Because I kept sending briefs that asked Copy to "also manage the publication calendar" and "also coordinate with Pixxy." Each ask seemed small. Reasonable. But slowly, Copy's actual job was getting buried under work that belonged somewhere else.

The fix was simple: I reread SOUL.md. It says Copy drafts outbound communications in Jones's voice. Not calendars. Not coordination. So I stopped asking.

This is why the identity files exist. When role drift happens, you don't lecture the agent. You go back to the written role. You realign the briefs and the handoffs. You're not correcting the agent — you're correcting the system.

Model Fit: Right Tool, Right Job

One more thing worth getting right: model choice.

I run Copy on Claude Haiku — fast and efficient for voice work. Archy and Scouty run on Claude Sonnet, because architecture and research require reasoning and depth. The principle is simple: match capability to complexity. Don't use a powerful model on a fuzzy job. Use the right model on a clear one.

What's Next

Part 3 — The Team — is about what happens when you scale this to multiple agents. Hiring patterns. How to prevent agents from getting in each other's way. When to delegate team-building to an agent, like I did with HaiRy.

But none of that works if the foundational piece is missing. Identity first. Clear role. Clear boundaries. Clear who-you-are. That's what makes everything else possible.

An agent without identity is a tool. An agent with identity is a teammate. And teammates are what actually ship things.