What is an Agent Operator — the role Aaron Levie says 500,000 companies are about to hire for
In brief
Aaron Levie says 500,000 to 1 million companies will hire for this role. Most won't call it 'Agent Operator.' Some will call it an AI program manager, an automation lead, an AI systems admin. Whatever the title, the job is the same: you are responsible for making AI agents actually work inside your company.
Contents
In May 2026, Aaron Levie — CEO of Box, someone who has tracked enterprise software for two decades — posted a prediction that most people in tech dismissed as hype and most people inside companies quietly recognized as already true: between 500,000 and 1 million "Agent Operator" roles will exist in the near future. He published a specific job spec. Not a vague "AI skills required" paragraph — an actual eight-part description of what this person does every day.
The jobs are already appearing. They just don't have consistent names yet.
At some companies it's an AI Program Manager. At others it's an Automation Lead, an AI Systems Administrator, a Digital Transformation Specialist, or just "the person who handles the AI stuff." The titles vary. The job is the same. And millions of people are already doing it, usually without having been hired for it, often without being paid for it, and almost never with adequate support.
This is the article that explains what this role actually is — and whether you're already in it.
The definition
An Agent Operator is the internal person responsible for deploying, maintaining, and improving AI agents across their company.
Not a consultant who sets things up and leaves. Not a developer building a product for external customers. An employee — with ongoing accountability for whether the agents keep working.
That accountability is the key distinction. It means when an agent breaks at 2pm on a Tuesday and the customer service team can't process claims, you're the one who gets called. When the CEO asks "so what has the AI actually delivered this quarter?" you're the one who has to answer. When a department wants to expand the agent to cover a new workflow, you're the person who figures out if that's a good idea and makes it happen.
How it's different from other roles people confuse it with
It's not the same as IT administration. IT admins manage systems that already exist — they configure, maintain, and troubleshoot. Agent Operators redesign workflows. You're not just keeping the lights on; you're rebuilding how work gets done.
It's not the same as software development. Developers build products, usually for external customers or internal platforms. Agent Operators operate and evolve systems that are running inside the business. The work is closer to running a business operation than building software. You don't need to write code from scratch. You need to understand systems deeply enough to configure, connect, and maintain them.
It's not the same as project management. Project managers coordinate between people and track deliverables. Agent Operators get hands-on with the systems themselves — writing system prompts (the instructions that tell an agent how to behave), building evaluation test sets, connecting data sources, diagnosing failures.
The closest existing analogy: a Salesforce admin. Salesforce admins don't build Salesforce — they configure it, customize it for their company's workflows, maintain the data quality, train users, and figure out what to turn on next. That's exactly the relationship an Agent Operator has with AI agents. Except the toolset is newer, the job is less standardized, and there's no Salesforce certification equivalent yet.
The eight things an Agent Operator actually does
Levie's job spec was specific. Here's what each item means in practice:
1. Map out new workflows with agents.
Before you can deploy an agent, you have to understand the workflow you're replacing or augmenting. That means talking to the people who do the work, understanding the exceptions and edge cases, and deciding what the agent should handle and what should stay human. This is half operational analysis, half systems thinking.
2. Implement new systems to deploy agents.
The "implementation" at the Agent Operator level is usually not code — it's configuration. Writing a system prompt. Setting up a Claude Project. Connecting a Google Drive folder. Building the Zapier flow that keeps context current. Technical, but not engineering.
3. Make sure agents have the right, up-to-date context.
An agent is only as good as what it knows. If the agent is answering questions using a policy document from last year, the answers will be wrong. Keeping context fresh — knowing which documents feed each agent, knowing when they need to be updated — is one of the most important and most neglected parts of the job.
4. Wire up internal systems to connect to agents.
Eventually your agents need to talk to the systems where work actually happens: your CRM, your ticketing system, your ERP, your documents. The Agent Operator figures out how to make those connections, at whatever level of integration the company can support right now.
5. Create evals for agents.
An eval (short for evaluation) is a documented set of test cases — real examples of inputs and expected outputs — that you run regularly to check whether the agent is still working correctly. Most Agent Operators haven't built one yet. The ones who have are the ones who catch problems before users do.
6. Figure out where the human is in the loop.
Not every output from an agent should go directly to the user or directly into a system. Some decisions need human review. Some outputs need spot-checking. The Agent Operator decides which ones, and designs the workflow so humans are in the right places — not so many that the agent adds no value, not so few that errors compound unchecked.
7. Manage the system when there are new upgrades.
AI models get upgraded. When Claude releases a new version, or when Anthropic changes default behaviors, your agents may behave differently. The Agent Operator needs to notice this, run tests, and either accept the new behavior or adjust prompts to maintain consistency.
8. Help with change management of existing business processes.
The technology is often the easy part. Getting people to actually use the agent — to trust it, to change their workflows, to stop doing the task manually — is the hard part. Agent Operators are on the front lines of this.
Where this role comes from in the org
Levie was explicit about this: the role will come from IT, engineering, or directly from business functions. That's not a vague "it could be anyone." Those three paths correspond to three different types of Agent Operators:
From IT: Technically grounded, already trusted on systems questions, may need to build more business workflow instinct. Strong at integration and reliability.
From engineering: Deepest technical capability, may need to build more tolerance for ambiguity and organizational dynamics. Strong at evals and debugging.
From the business function itself: Deepest understanding of the actual workflow, may need to build more technical confidence. Strong at identifying the right use cases and getting team adoption.
All three can do this job. The combination Levie described was "technical-yet-business-savvy." The technical part means you can understand how these systems work well enough to configure and maintain them. The business-savvy part means you understand what the workflow is actually supposed to accomplish, who uses it, and what failure looks like.
Who is becoming this right now
Look around any mid-size company and you'll find people already doing this work without the title. The IT manager who got asked to "figure out the AI stuff" six months ago. The operations analyst who built three Zapier flows and a few Claude Projects and somehow became the internal expert. The business analyst who noticed their team was spending 15 hours a week on a task that an agent could handle in two, and decided to fix it.
These people are Agent Operators. They didn't choose the role so much as the role found them.
The skill profile that keeps appearing: systems thinkers who can read documentation, who understand both how software works and how work actually gets done in their organization, and who are comfortable operating without a playbook. Former Salesforce admins, business systems managers, ops analysts, IT generalists. People who have always been the person who "figures out the new tool."
What to do if this is you
If you've read this far and recognized yourself in the description, the next question is how to build the role into something durable — and how to do it without burning out trying to do everything at once.
The place to start is with a disciplined 90-day plan: one team, one workflow, one agent that actually works. Everything else flows from that first win. The 90-day Agent Operator playbook covers exactly this — what to build in what order, what to defer, and what to avoid.
The role Levie described isn't hypothetical. It's already here. And most people in it are figuring it out without a roadmap.
Try this today
Write down the agents you're currently responsible for — even informally. For each one: is there a written description of what it's supposed to do? Is there a way you'd know if it stopped working? Is the context it uses current?
If the answer to any of those is "not really," that's where to start. The role of Agent Operator isn't just building agents — it's maintaining the ones you've already built.