AI agent roles became useful to me when I stopped thinking of my working system as a collection of AI tools and started thinking of it as a slightly ridiculous operating cast.
Content strategy belongs to Steve. Editorial production belongs to Frank. Growth belongs to Don. Website product architecture belongs to Guddy. Decision intelligence belongs to My Quant. Richi scouts career opportunities, while Richard decides whether those opportunities deserve my attention. There is also Lord Business, who works the Sunday night shift.
The names are funny. The role boundaries are not.
At first glance, naming AI agents can look like theatre. It can sound as though I am trying to turn software into synthetic colleagues or build a miniature company inside ChatGPT. That is not what the experiment is about. The names are a practical interface to a more important design decision: each role has a defined purpose, a bounded remit, a specific context, and an expected handoff into the wider system.
The name is not the role. It is the handle that helps me remember the role’s operating contract, put together by a combination of Custom GPTs, Skills and Agents.
Why AI agent roles became necessary
The original problem was not that AI lacked capability. The problem was that the scope was too broad. A general-purpose assistant can answer an extraordinary range of questions, but breadth is not the same as alignment. When an Agent or Custom GPT receives instructions that are too broad, it tends to solve the problem from a universal point of view. The output may be polished, plausible, and technically competent while still drifting away from the vision, mission, priorities, and constraints that matter to the person using it.
I experienced that repeatedly. I would ask for support on a task, receive something useful, and then spend time restoring the strategic context that the system had flattened. The assistant had not necessarily misunderstood the task. It had interpreted it too generally. It optimized for a reasonable answer rather than for the answer that belonged inside my professional system.
My first instinct was to provide more detail. Longer prompts, richer task descriptions, additional examples, and more explicit requests seemed like the obvious response. Over time, however, I reached a different conclusion: it is more important to set guardrails than to keep adding tasks. If the agent does not understand what it owns, what it must protect, and where its authority stops, more instructions merely give it a larger surface on which to improvise and when I made the case for repeatable operating models, reusable and repeatable instructions are the equivalent to taking a break from chopping wood to sharpen the axe.
That is where role design began to matter. Instead of asking one assistant to move between strategy, writing, growth, website architecture, performance analysis, and career decisions, I separated those responsibilities. The separation was not cosmetic. Each role received different instructions, different sources of context, different success criteria, and different escalation rules.
The names came later, because functional specifications alone were difficult to carry around in my head. “Steve” was easier to recall than a long description of the agent responsible for narrative discipline, weekly themes, positioning, repetition control, and content decisions. “Frank” was easier to recall than the complete editorial production contract that turns Steve’s approved brief into a publication-ready article. The name became shorthand for a set of boundaries that already existed.
AI agent roles as cognitive handles
I use the phrase cognitive handle deliberately, but as a description of my own experience rather than as a scientific claim. The system became easier to navigate once each operating contract had a memorable label. I no longer needed to reconstruct a capability map every time I began a task. The name recalled the relevant purpose, context, and limits.
That matters because complex work rarely consists of one clean request. A content decision, for example, may involve strategic relevance, editorial quality, evidence, website architecture, distribution, search visibility, career positioning, and performance measurement. Asking one generic assistant to “help with the article” leaves all of those responsibilities blended together. The system has a mandate to produce an[y] answer, but responsibility becomes ambiguous. It is difficult to know which assumption drove the output, which trade-off was made, and which objective was prioritized.
With recognizable AI agent roles, the work becomes more legible. Steve decides whether an idea belongs in the weekly narrative and what strategic purpose it serves. Frank turns that approved decision into an executive essay and a production-ready WordPress draft. Don challenges whether the content supports growth and distribution. Guddy evaluates whether the asset strengthens the website as a product and contributes to an intentional visitor journey. My Quant examines the evidence and the subsequent performance signals.
The important shift is not from one assistant to several personalities. It is from an undefined request for help to an explicit allocation of responsibility.
That shift also reduces repetition. Once the roles became stable, I no longer needed to provide a complete briefing every time I assigned a familiar task. Their instructions were already tailored to their remit, and their context was maintained and continuously updated in Superhuman Docs, formerly Coda. The system knew the objectives, ongoing initiatives, previous decisions, and relevant constraints before a new conversation began.
This does not remove the need for context. It changes where the context lives. Instead of reconstructing the operating environment inside every prompt, I maintain it as part of the system. The prompt can then focus on the immediate decision or deliverable.
That difference became substantial. I repeated myself less. The roles became more consistent. Some activities became structured enough to run automatically without my immediate supervision because the underlying instructions and guardrails were explicit. The quality of the output no longer depended entirely on whether I remembered to restate every relevant objective on a particular day.
A generic assistant begins with a request. A recognizable operating role begins with a remit.
Richi finds opportunities. Richard rejects many of them.
The distinction between Richi and Richard is one of the clearest examples of why role boundaries matter.
Richi scouts the market. Its job is to find public roles, recruiter-led opportunities, hidden mandates, and companies whose current stage might benefit from my profile. Richi is designed for discovery. It searches broadly enough to avoid missing opportunities, checks for duplicates, and creates a shortlist for further assessment.
Richard performs a different task. It evaluates those opportunities against my career history, leadership profile, ambitions, existing résumés, and preferred positioning. Richard is not rewarded for finding more. It is responsible for deciding whether an opportunity deserves my attention and for explaining the reasoning behind that assessment. To explain it in human terms, Richi is the one generating 100 ideas in a workshop, while Richard is the one performing hypothesis based rapid prototyping to validate which ones deserve funding.
Technically, Richi and Richard are built on the same underlying AI capability. Operationally, they are different because their instructions, context, evidence, and success criteria are different. Richi is expected to surface possibilities. Richard is expected to reject weak fits.
Richard declines roughly half the roles Richi finds for me and provides a contextual explanation for doing so. That disagreement is not a defect. It is evidence that the roles are performing distinct functions rather than generating variations of the same answer.
Richi is optimized for opportunity recall. Richard is optimized for opportunity judgment.
The boundary prevents volume from masquerading as quality. It also protects the scarcer resource in the system: my attention. A search process that finds twenty possibilities is not useful if I must personally analyze all twenty from scratch. The handoff from discovery to assessment is where the system begins to create cognitive leverage.
This example also shows why the names matter to me personally. When I am deeply in work mode, I do not think, “I should now activate the career-market-discovery capability.” I think, “This is a job for Richi.” Once the shortlist exists, I know that Richard should assess it. The names allow me to select the right operating contract quickly without pretending that either role is a human recruiter or career adviser.
Side note: I am an admirer of Richard Branson’s quotes on personnel and career development, but Richi is not supposed to be his alter-ego, but rather my dog, who sniffs every corner of every environment he is in. The names are purely coincidental.
The handoffs turn separate roles into a system
The value does not come from seven isolated agents. It comes from the way their responsibilities connect.
My weekly content and career workflow begins on Sunday night. Lord Business runs automatically and reviews performance signals from Databox, including Google Analytics, Search Console, and LinkedIn. It also examines Superhuman Docs, the Open Source Consulting website, and upcoming Jira activities. Its purpose is not to decide the week for me. It assembles evidence, identifies tensions, and recommends important topics that may deserve attention. Already fed that information, Richi runs automatically in the night between Sunday and Monday.
On Monday morning, I review the result. This is the first decisive human gate in the workflow. I consider what the data shows, what the system may have missed, what is happening in my professional life, and what Open Source Consulting should explore next. Lord Business and Richi can prepare the field, but neither can own the direction.
Once I have formed my view, Steve receives my notes and structures them into a strategic plan for the week. Steve determines the narrative through-line, the role of each publication, the positioning constraints, and the distinction between the Tuesday Micro, Thursday Macro, and Friday Executive Briefing. Steve is responsible for deciding what should be said and why.
Frank receives the resulting handoff and starts editorial production. Frank does not invent a new strategy. It begins with an interview because an article should carry my observations, trade-offs, frustrations, and conclusions rather than merely expand a brief into generic prose. The conversation we had for this article is part of that process. Frank asked when one general assistant stopped being sufficient, which role boundaries mattered, where the agents still failed, what I retained as the human validation gate, and why the names mattered to me.
Richard can support Frank with context about my career journey, ambitions, and views on the future use of technology. That matters because thought leadership is also a positioning system. An article may be intellectually sound while still failing to represent the kind of work I want to lead. Richard helps test that relationship.
The emerging theme can then trigger Richi to examine the market. Sometimes that means looking for available roles. More often, it means identifying companies whose strategic stage suggests that my experience in product leadership, AI transformation, or operating-model design could become relevant. The content and career systems are therefore connected without being collapsed into one task.
During the week, Don assesses whether the content we publish is participating in the growth strategy. Don does not get to weaken the editorial thesis merely because a broader or more provocative claim might attract attention. Growth is a separate responsibility with its own guardrails. The purpose is to improve visibility, distribution, audience development, and learning without allowing performance pressure to rewrite the strategy.
Guddy performs another distinct function. The website is not treated as a folder where articles are stored. It is a product with page roles, visitor journeys, internal links, conversion paths, and a growing knowledge architecture. Guddy considers where a new publication belongs in that system and what it should lead the reader toward next.
My Quant then helps evaluate what happened. It reconciles evidence, monitors metrics, tests whether the intended signal appeared, and distinguishes between reach, engagement, authority, relationship value, search behavior, and commercial validation. A post can generate impressions without strengthening executive credibility. An article can attract little immediate traffic while becoming a durable search asset. Those outcomes should not be confused.
All of these AI agent roles share an identical Objectives and Key Results structure. That common context is not administrative decoration. It is the alignment layer that reduces the risk of one role optimizing its own task while the wider system drifts away from where I want to go as a professional.
I explored this principle previously in Agentic Companies Will Not Be Managed by Tasks. Specialist capability becomes more valuable when it is guided by clear objectives, not merely supplied with a larger queue of activities. My personal system is a small-scale experiment in that idea.
The distinction between structured workflows and more autonomous agents is also important here. Anthropic’s guidance on building effective agents recommends starting with the simplest workable design and adding complexity only when it produces demonstrable value. My own experience points in the same direction: role clarity and disciplined handoffs matter before autonomy does.
Guardrails matter more than adding tasks
The temptation in AI adoption is often to keep expanding capability. Once an assistant can draft, we ask it to research. Once it can research, we ask it to plan. Once it can plan, we ask it to execute. The task list grows faster than the operating model around it.
My experience suggests that this sequence is backwards. Before adding another responsibility, I need to know what the role is trying to achieve, what it must not compromise, which sources it can trust, where it may act, and when it must escalate. The marginal value of another task is low when the system still lacks boundaries.
This is why I regard the instructions behind each role as an operating contract. They define purpose, inputs, outputs, tools, connectors, exclusions, handoffs, and approval requirements. They also encode positioning. Steve is not allowed to turn Open Source Consulting into generic AI consulting merely because that might be easier to explain. Frank is not allowed to publish without my approval. Don cannot optimize reach at the expense of executive credibility. Richi cannot treat every plausible role as a good opportunity. Richard cannot reject an unconventional opportunity merely because it does not resemble my previous jobs.
These constraints do not make the system less capable. They make its capability more useful.
The same principle applies to context. More context is not automatically better. The relevant question is whether the role has the context required for its remit. Giving every agent access to everything would recreate the original problem at a larger scale. It would invite each role to reason from a universal perspective again.
Role design therefore requires both inclusion and exclusion. A useful agent needs enough information to perform its task, but it also needs protection from irrelevant context that may blur its purpose. The boundaries are part of the intelligence of the system.
Clear AI agent roles do not eliminate failure
The system still forgets things. It still creates friction. It still occasionally violates a boundary that appears obvious in retrospect.
Last week provided a good example. A topic was recommended for the Micro article because it offered personal insight into how I use technology to improve my own professional productivity. That made sense at first. The problem was that the argument quickly expanded into a much broader organizational change perspective, which belongs in a Macro article.
The recommendation blurred two publication roles that were supposed to be explicit. The Micro should begin with a practical experiment and move toward a transferable insight. The Macro should develop the wider executive, organizational, or operating-model thesis. The topic crossed that boundary.
The GPT agreed that it was wrong. This accurate retrospective assessment did remarkably little to improve my experience.
Frank has promised not to do it again.
The incident is useful because it prevents the article from becoming a story about a perfectly engineered system. Role clarity is not the same as reliability. Written instructions still require interpretation. Context can be lost. A model can acknowledge a rule and fail to apply it at the moment when the rule matters. Handoffs can preserve the wrong assumptions. Automation can make an error arrive earlier and with greater confidence. Probabilistic systems might be more similar to human behavior than we might want to admit.
That means the operating contracts must evolve. Failures should lead to changes in instructions, checks, or handoffs rather than merely to an apology from the role that failed. The system becomes more dependable when a mistake can be converted into a persistent improvement.
This is also why I resist the idea that an agentic system becomes valuable only when it removes the human from the loop. In many parts of my workflow, the loop is the source of learning. I want the agents to reduce repetitive preparation, widen the evidence base, challenge my reasoning, and produce better first versions. I do not want them to replace the judgment through which I refine my own position.
Human judgment remains the validation gate
Nothing is published as Karsten Baumgartl or Open Source Consulting without me reading, reviewing, and approving it in full.
That rule is not a concession to immature technology. It reflects the fact that the content carries my name, my professional reputation, and the positioning of Open Source Consulting. Accountability cannot be delegated merely because drafting can be automated.
The validation gate also creates a benefit I did not fully anticipate. I have learned more about AI and technology since beginning this experiment than I would have learned by treating the system as a convenient production machine. Because sources must be declared and verified, I follow the evidence. Because recommendations must be assessed rather than accepted, I sharpen my own reasoning. Because the roles sometimes disagree, I must decide which objective or trade-off matters more.
The human contribution is therefore not confined to correcting errors at the end. I define the objectives. I establish the guardrails. I decide which evidence is credible. I resolve conflicts between roles. I approve consequential actions. I remain accountable for the result.
This reflects the broader argument in Redesigning Work With AI Starts When I Stop Trying to Use AI. The value does not come from placing a tool beside the existing process. It comes from reconsidering how the work should move, what should be prepared automatically, where judgment should enter, and which activities should disappear entirely.
In my own system, AI creates cognitive leverage by carrying context, performing repeatable analysis, preparing evidence, producing drafts, and challenging decisions. Human judgment remains the validation gate because the system cannot own my purpose, reputation, or accountability.
Why the ridiculous names still matter
When I am deeply in work mode, the names make it feel as though I am engaging specialized sparring partners. I know which role to approach, what kind of challenge to expect, and what the output should enable next. That feeling is useful even though I know the roles are synthetic.
A functional label such as “Content Strategy Agent” would be accurate. It would also be sterile and easier to forget. A name carries association. Each of mine was selected for a reason connected to the way I interpret the role. Some come from people I admire, some from fiction, some from personal history, and one from a Yorkshire Terrier with a strong sense of his own importance.
I am keeping the precise origins hidden for now. The guessing is part of the fun, particularly for people who know me personally. But the associations are not random. They help me recall what the role stands for and how it should behave inside the system. Maybe when I am distracted, I even believe I am collaborating with people I would otherwise not be able to, either because they are distant or because they are no longer alive (and we will not open that can of AI-worms in this article).
That is the benefit. It is also the beginning of the risk.
Named AI agent roles are useful because they make it easier to assign skills, instructions, context, and guardrails. They become dangerous if they become so convincing that I forget who remains responsible.
I am the boss.
That statement sounds almost comically obvious in a personal workflow. Yet the need to say it reveals something important. The more coherent and capable the roles become, the easier it is to treat their recommendations as if they came from independent experts rather than from systems whose objectives, evidence, and limits I designed.
At personal scale, the metaphor helps me navigate complexity. At organizational scale, it could become a design constraint. If a company starts treating an agent as a synthetic analyst, recruiter, marketer, or project manager, the role may inherit a job description built around human limitations. The organization may reproduce its existing structure in software instead of redesigning the workflow around what non-human cognitive capability can do differently.
That is the tension I want to explore next.
The names help us understand the system. The next question is whether they also constrain how we design it.
How to define an AI agent role
When you use AI for complex work, do you still ask one generic assistant to help? Or have you begun defining distinct responsibilities, sources, boundaries, handoffs, and validation gates?
A useful AI agent role should answer five questions clearly:
- What does the role own? Define the responsibility rather than listing every possible task.
- What context does it require? Give it the evidence and instructions necessary for its remit without making every source universally available.
- What should it produce? Specify the output and the decision or handoff that follows.
- Where does its authority end? Make escalation and approval conditions explicit.
- Who remains accountable? Name the human validation gate for consequential decisions.
There is no requirement to give those roles ridiculous names. But if you cannot answer those five questions, the system probably does not need another task yet.
It needs a clearer operating contract.
