AI agents shouldn't have a job title

Agents are better when they stop pretending to be people

Here’s a mental model we keep coming back to: humans are deep and vertical, agents are shallow and wide. A human owns a role end to end — the judgment, the context, the edge cases, the cross-team coordination that never makes it into a job description. An agent, by contrast, handles the learnable tasks that exist across multiple adjacent roles simultaneously. The shared context across those roles can actually make it better at each one. However, agents often fail at the messy edge cases that take up lots of human time

This distinction sounds simple, but it has profound implications for how you build agents — and how you talk about them. The right way to design an agent is to start from what humans struggle to do at scale: process large volumes of data without fatigue, consider many possibilities in parallel, or find an interesting detail to personalize sales outreach.

Source: Gemini.

This is a critical distinction in how you explain, build, and iterate on your product. You can choose to focus on cooperating with humans – an agent designed around what humans can’t do and built to hand off gracefully when things get messier than expected. Or you can choose to copy-paste a human job description into a product spec with a rigid set of requirements, something that will inevitably disappoint customers with mismatched expectations.

The AI industry has, almost universally, chosen the second path. You can’t take a step in San Francisco without seeing a billboard for an AI SDR, an AI SOC analyst, or an AI SRE. We understand why — customers are searching for these terms, and if your website doesn’t speak their language, you’ll lose the SEO battle before you get to make your pitch. But we think the race to anthropomorphize agents is setting the entire industry up to fail.

Why job-title naming creates a trust crisis

When you name your agent after a job title, you’re making an implicit promise: that your product can do what that person does. That includes everything that never appears in the formal job description.

Take an AI SDR. The pitch is intuitive: identify the right prospects, send them the right message, and generate pipeline. In our experience, agents are genuinely good at account research, ICP matching, and identifying the right person to contact at a given company. Where they fall short is the second part. What a customer buying an AI SDR expects is to turn it on, feed it some messaging, and come back to a healthy pipeline. What they mostly get is good targeting attached to generic outreach that doesn’t convert.

The gap is the messy bits that humans often intuit well. Good outbound sales requires creativity and the ability to build rapport with a stranger in a single sentence. Humans who are good at sales have spent years developing that instinct. Agents, today, produce messaging that sounds automated, and we’re all inundated with that nonsense. It’s easy to imagine an agent that does all the research and hands off to a human to get the prospect over the line. But that’s not the expectation the name set.

We could make this argument across every anthropomorphized agent market. In our own experience, the phrase “AI SRE” is frankly a poor description of what our product actually does — but it’s what customers are searching for, which creates a genuine tension we’ll come back to.

What good naming looks like

The most instructive counterexample is coding agents. Cursor didn’t call itself an AI software engineer. It started off as an AI-powered IDE — a tool that generates code effectively across a complex codebase. They didn’t set the expectation of being an autonomous engineer that ships features end to end.

This wasn’t just semantic humility. The people building these products had a good understanding of software engineering to know that everything a software engineer did was not immediately in scope for automation. Humans would still be responsible for the architectural decisions, the cross-functional coordination, the customer conversations that shape what gets built.

By scoping the promise to a task – generating code – rather than the role, they gave themselves the opportunity to match (and beat!) users’ expectations. Engineers who adopted these tools didn’t feel like they were being replaced. They felt like they were getting faster at the part of their job they liked least. Over time, trust built through thousands of small interactions where the tool did what it said it would do. That trust is what eventually opened the door to agents taking on more.

It’s not a coincidence that coding agents have the deepest adoption, the strongest data flywheels, and the most widespread acknowledgment of quality in the entire AI application landscape.

What agents should actually be built for

The deeper issue with anthropomorphizing isn’t just the naming — it’s that job-title thinking constrains product design in ways that limit what agents can actually become.

Most agent products today are built around a simple idea: observe what a human does, then automate it. For an AI SRE, most products are asking their customers to write a runbook for every alert type. Then they build an agent that follows the runbook, posts a summary in Slack, and pretends to have capabilities that auto-remediate an issue. This approach produces passable results but creates tons of process overhead that users quickly learn to ignore – and it doesn’t create the opportunities for users to actually trust the end-to-end resolution workflow. This is marginally better than the human workflow it replaces, but you’ve left most of the agent’s actual capabilities on the table.

The more productive question to ask is what can an agent do that a human fundamentally can’t? Not something that an agent is slightly faster or cheaper at — what is truly different about an agent’s capabilities? Continuing the AI SRE analogy, an agent can monitor thousands of signals simultaneously without fatigue. It can run dozens of hypotheses in parallel and discard the ones that don’t pan out. It can surface patterns across an entire customer base that no individual human would ever accumulate enough exposure to recognize.

This realization meaningfully changed how we’re building RunLLM. Rather than following fixed alert thresholds the way a human on-call engineer would, we detect incidents by analyzing the frequency and content of observability data to surface anomalies before they’ve been formally flagged. Rather than working through a runbook linearly, we spin up multiple subagents in parallel to evaluate many hypotheses simultaneously. And rather than claiming that we’re going to automate end-to-end resolution, we give users the option to pick the handoff point that they prefer. The agent does not try to map a human workflow; it focuses on automating things that humans can’t do and letting humans handle the rest. That’s why our product delivers outcomes that a copy-pasted human workflow never could.

Where this is all going

The implication of this argument extends beyond product design and naming. If agents are genuinely shallow and wide — good at the learnable, scalable slice of many adjacent roles — then the natural endpoint isn’t one agent per job function. The boundaries between traditional roles will naturally become less fixed over time. Humans already manage multiple agents across overlapping domains, and that will only increase.

A software engineer who uses an SRE agent to monitor production isn’t doing an SRE’s job. They’re doing their own job better, with more visibility. An SRE who uses a coding agent to patch a bug during an incident isn’t moving into software engineer. They’re resolving the incident faster. The agent isn’t replacing either person — it’s dissolving a boundary that only existed because humans have limited bandwidth.

The companies that stop asking “which human job does this agent replace?” and start asking “what can this agent do that the human couldn’t?” are going to build products that are genuinely differentiated, not just incrementally better. The rest will keep fighting over SEO terms while quietly underdelivering on the promises those terms imply.