Most developers name their AI sub-agents things like stripe-agent or security-checker. I named mine George, Agatha, Ray, and Helen. This isn’t whimsy; it’s how I remember who the work is actually for.

When I need to focus on payment integrations, I don’t invoke stripe-agent or payment-flow-optimizer. I invoke George.

George Washington Carver spent his life transforming overlooked resources into sustainable value. He found hundreds of uses for the peanut, the sweet potato, the soybean (crops that others dismissed). He turned simple inputs into systems that supported entire communities.

That’s what a good payment system does. It takes the simple act of exchanging money for goods and turns it into something that sustains the people who depend on it. When I invoke George while designing webhook handlers and subscription flows, I’m thinking about Carver’s legacy: patient, resourceful, turning small things into something that lasts.

This is how I’ve come to work with AI-assisted development tools. I name my sub-agents after the people who inspire me, not because the tools have personalities, but because I need to stay intentional about who I’m serving. These aren’t chatbots with personalities; they’re specialized configurations I invoke by name to focus my intent.

The Problem With Abstraction

The tech industry loves to abstract away the human. Users become “MAUs.” Problems become “pain points.” Customers become “conversions.” I’ve spent over forty years writing software, and I can’t afford to think that way.

Almost all of my work has served real humans with names and lives. Biologists creating DNA from scratch who needed to manage their labs. Astronomers who needed searchable sky atlases built from radio telescope data. Legal professionals who needed portals into dense law journals. Rural electric engineers who were ready to leave the paper and pencil era behind. Regular people who just wanted to file their taxes without drowning in forms.

And for over twenty years, farmers. Market managers. Neighbors trying to feed their families something better than what the grocery store offers. That’s the work I’ve written about most recently, but it’s one thread in a much longer career of building tools for people I’d never meet but whose problems I came to understand.

Naming my tools after people who inspire me is a small ritual that keeps me from forgetting who I’m building for.

Where It Started

The first agent I named was Ray, after Ray Eames.

I was working on visual design, trying to get an interface right, and the functional name (something like design-system-agent) felt hollow. It reduced the work to a skill to be optimized rather than a craft in service of people.

So I named her Ray instead. And something clicked.

Every time I invoked her, I thought about Ray Eames. About the design revolution she helped create. About her belief that design should serve human needs, not just look clever. About chairs built for sitting, not for winning awards.

The name changed how I approached the work. It wasn’t just “run the design agent.” It was “think about this the way Eames would want me to think about it.” Form serving function. Function serving humans. Touch targets sized for hands that have been working all day. Interfaces that work in bright sunlight or a dim office.

That’s when I realized the naming wasn’t a quirk. It was a practice.

How It Actually Works

I don’t chat with Ray directly. Claude’s sub-agents are specialized configurations that the main agent can invoke for particular tasks. They’re always there in the background, ready to be called on.

But I can suggest them by name. When I know we’re working on a task where I’d want to apply the principles embodied by their real-life human counterparts, I can ask Claude to do the same.

Agatha is a good example. I named her after Agatha Christie, and her focus is security audits. Christie built a career on finding what everyone else missed: the detail that doesn’t fit, the clue hiding in plain sight, the pattern that only becomes clear when you look from the right angle.

When I say “have Agatha review this before we ship,” I’m not asking for a generic security scan. I’m saying that I need to look for what I missed. I need to find the secret traveling farther than it should, the data leaking where it shouldn’t, the assumption I made that an attacker won’t make. I need to be paranoid on behalf of the users whose data and trust I’m protecting.

The names aren’t just labels. They’re invocations. They shape my intent before the work even starts.

The Chorus

Over time, I’ve built a small roster of these named agents. Beyond George, Ray, and Agatha, there’s Ada for performance, Erma for user-facing text, Maya for marketing, Diderot for documentation, and Helen for accessibility. Each is named for someone whose work I admire in that space.

Something interesting happens when I apply multiple agents to the same work. When I’m preparing a feature for launch, I might invoke several of them in sequence, each bringing a different lens. It’s not a literal conversation between them, but their perspectives compound.

I’m applying a chorus of values: Christie’s attention to the telling detail, Eames’s insistence on function serving humans, Lovelace’s vision of what a system could become, Bombeck’s warmth in the everyday, Keller’s understanding of barriers and how to remove them.

On one recent feature, invoking Helen after Ada meant slowing a transition animation that technically passed performance benchmarks but broke screen reader timing. Ada’s lens said it was fast enough. Helen’s lens said it wasn’t accessible enough. The human need won.

These are people who cared about craft and cared about the humans their craft served. I can’t live up to their standards, not really. But I can try, and invoking their names is a way of keeping their values present in the work.

Helen’s Story

I added Helen to my roster just this week.

I’d been writing a blog post for my company about Blue Beanie Day, the annual celebration of web standards and accessibility. The core argument was simple: accessibility should be built in from day one, not retrofitted. When you try to add it after the fact, you’re fighting against architectural decisions that assumed mouse interaction, fixing color choices that were never tested for contrast, spending ten times the effort you would have spent doing it right initially.

After I finished writing, I realized I wasn’t fully practicing what I’d preached.

Ray had accessibility as part of her purview. Her configuration mentions WCAG compliance, color contrast, and keyboard navigation. But accessibility wasn’t her focus; it was one concern among many.

Helen Keller didn’t just understand accessibility. She lived it, advocated for it, made it her life’s work. If I wanted accessibility to get that same dedicated attention in my own work, I needed someone whose entire purpose was watching for it.

So I created Helen. I tuned her configuration with WCAG criteria, screen reader compatibility, keyboard navigation patterns, and the whole audit framework. Then I added her to my roster and ran a full audit.

The audit found things, issues I’d missed even with Ray’s broader design lens. Focus states that weren’t quite visible enough. A few interactive elements that weren’t fully keyboard accessible. Color contrast that passed in most contexts but failed in a few edge cases.

The practice works. The name made me create the agent. The agent’s lens caught real problems. The problems got fixed. The software is better for everyone now, not just users with disabilities, but everyone who benefits from clear focus states and logical tab order and sufficient contrast.

Software as Medium

I don’t think of myself as someone who writes software. I think of myself as someone who solves human problems, and my medium happens to be telling computers what to do.

A carpenter doesn’t love wood for its own sake; they love what wood becomes in service of the people who’ll use it. A chef doesn’t cook to impress other chefs; they cook to nourish and delight the people who’ll eat. The material and the technique matter, but they’re not the point.

When I write code, I’m not trying to impress other programmers with elegance or cleverness. I’m trying to make something that works for the biologist tracking samples, the astronomer searching the sky, the lawyer chasing a precedent, the engineer planning a grid, the taxpayer trying to get through April, the farmer checking their order list.

Naming my tools after humans keeps that truth at the center. The code serves people. The tools serve the code. The names remind me which direction the service flows.

A Small Ritual

I don’t know if this practice would help anyone else. It might be too personal, too idiosyncratic, too tied to the specific way my brain works.

But I offer it anyway, in case it resonates: consider naming your tools after the people whose work you admire. Not as a gimmick, but as a practice. A small ritual that asks you, every time you invoke them, what would they think of what I’m building? Who am I building it for? Am I doing work they’d be proud to be associated with?

The tools don’t care what you call them. But you might find that you care, and that caring might make you better at the work.

George, Agatha, Ray, Helen, and the rest of my chorus. They’re people who made things that mattered. I can’t match what they accomplished, but every time I invoke them, I remember what this is all for.

Software is a means, not an end. The code serves the people. The names help me remember.