Every technology transition in history has created new jobs.
For all the talk about AI being different - in that it may actually result in a net loss of jobs - the exact opposite seems to be happening. The Economist published an article earlier this month making the case that AI has led to a net increase of one million new jobs in America since 2023.
This is the visible part of the AI jobs boom. It’s easy for the Bureau of Labor Statistics to count them because those jobs already have names - electrical contractors, construction workers, plumbers, etc.
But with every new technology platform, entirely new jobs emerge that were previously impossible to conceive of.
Mobile computing created a market for app developers. SaaS helped establish customer success to improve renewal rates. The consumer internet created growth teams that treated marketing like science. Cloud infrastructure gave rise to devops engineers who optimized infrastructure for developing software.
I’ve been thinking about what are the new jobs, especially in the tech industry, that will emerge that didn’t exist prior to this technology cycle.
As AI agents take on more work inside companies, a new role is emerging. Agents can take work off people’s plates, but someone needs to decide what they should do, give them access to the right information, and keep them working as the business changes. Launching an agent is just the beginning of that responsibility.
Which brings me to what I think is potentially the first new job of the AI era.
The Agent Operator
Matthew Busel is the ‘Agent Operator’ at Basis, the AI accounting startup valued at over $1B by Accel, GV, and Khosla Ventures.
Before Basis, Matthew co-founded Whalesync, a Y Combinator backed company. He joined Basis when it had around 35 people. It has nearly 150 now.
Another fun fact about Matthew: He and I went to elementary and middle school together, friends for over a decade as kids and then reconnected recently when we both found ourselves working in tech.
I recently sat down with Matthew to discuss his role in leading what Basis calls the Atlas Team, the team responsible for building internal AI agents. We spoke about the role of an Agent Operator, what an Agent Operations team looks like, what makes a good Agent Operator, and what it actually means to be AI-native as a company.
If William Gibson’s famous quote is true that “the future is here, it’s just not evenly distributed”, then it’s startups that see the future first. When it comes to AI, the most cutting edge startups can provide a glimpse into the future of the economy - and I believe that’s especially true with the role of agent operator.
What interested me most was what pursuing excellence as an agent operator actually looks like. It involves building agents, of course. But it also involves studying workflows, connecting systems, deciding when to buy software, and not only solving the operational bottlenecks of the teams around you, but your own team as well.
How Basis Structures their Agent Ops Team
Think of an agent as an AI-powered system that can use tools and information, take actions, and work through multiple steps toward a goal. A skill or a set of instructions can help it do that work. The agent is the system putting those pieces to use.
At Basis, the Atlas team’s mandate is simple to state but almost absurd to attempt: make everyone at Basis 100x more productive by enabling AI agents across the company.
Matthew’s framing is that the definition of an agent lives on a spectrum, not a binary.
On the simple end of the spectrum is a meeting-notes agent that Matthew’s Atlas team built. It has exactly one job, focused on taking meeting notes and embedding them into a company-wide context layer. Matthew compares it to the butter-passing robot from Rick and Morty, which asks its creator “what is my purpose?” and is told: you pass butter.
Further along the complexity spectrum is Clueso, the on-call investigation agent the Atlas team built, which has extensive access to data across the company, and is given enough compute resources to think for hours about solving bugs in Basis’ codebase.
Matthew and the Atlas team approach building agents in two ways.
Platform. Horizontal agents and AI infrastructure that raise the floor for everyone. Enabling unified data access, building skill libraries, and making Claude and Codex more effective company-wide.
Vertical. Specialized agents that support one function. They work directly with each team to figure out where automation can help. Clueso, Basis’ on-call agent, is an example here where Atlas went deep into an engineering workflow and built around its requirements.
This structure helps enforce depth, because agent operators can get pulled in multiple directions without actually shipping anything that moves the needle.
Atlas starts by asking which function represents the biggest constraint on the business that quarter. It then dedicates people to understanding the bottlenecks and deciding whether the solution should be built or bought.
If an existing product solves the problem, Atlas can help the team procure and adopt it. When the workflow requires capabilities or internal access that available products don’t provide, the team considers building. That distinction matters because the mandate is to make the company more productive, and writing software is one way to get there.
In the case of the on-call investigation agent, that was a vertical-specific agent that had deeper access to internal data and wider latitude of case handling than an external vendor could provide.
On the platform side, an example of what Atlas built is Satellite: a single MCP that wraps more than 25 other MCP connectors, so Basis employees only need to make a single integration in their Claude/Codex, and instantly get access to all of the tools that Basis runs on. While Satellite isn’t an agent, it is an important piece of AI infrastructure that gives leverage to the entire company - and that’s ultimately what the Atlas team’s mandate is.
In this example with Satellite, I pushed on the Atlas team’s decision to build: why would they build an MCP when Claude/Codex have developed so many native connectors? Two reasons: 1) Simplicity for the team, because now each employee only needs to handle installing one connector, Satellite. And 2) In some cases Satellite provides more feature/integration depth than native MCP connectors. If an employee needs a connector to do something the vendor hasn’t built, Atlas can custom build it into Satellite.
How to maximize internal AI leverage
My conversation with Matthew got me thinking deeply about AI leverage, and how organizations can maximize it internally. I came away with three points:
Buy capabilities. Frontier models, coding agents, licenses to AI applications. These off-the-shelf capabilities are the baseline that a company needs to start in adopting AI, before even crafting an Agent Ops team.
Build context. Getting agents into your CRM, your call recordings, your financial ledger, your docs - with the right permissions and the right freshness. Satellite is an example of what you can build once you pull all the right context together. Vendors can sell you pieces of this layer, but nobody can sell you the whole thing, each context layer is different depending on the shape and structure of each company.
Discover processes. The first step to automating a workflow is developing a deep understanding of it. Matthew was clear - process discovery is the real bottleneck in agent operations teams. Spinning up an agent is easy, but understanding the work is hard. If the sales team asks for an outbound agent, someone can ship a version in a week. Making it effective requires knowing how the salespeople actually operate, including what happens when a prospect doesn’t follow the expected path. Automating a process is harder when much of it exists only in people’s heads.
The on-call investigation agent is what effective process discovery looks like. Basis’ Atlas team conducted focused team-specific work with their engineering team, and built an agent that can access all of their systems and reason for hours, and it now does roughly one to two people’s worth of work per year.
Electra and Reducing the Maintenance Burden
The Atlas team’s most ambitious achievement came when they applied their own mandate (productivity) to themselves: build AI systems that take work off the team’s plate.
Atlas has made a big push toward “AI teammates”, agents that can proactively contribute work and own their own responsibilities, as opposed to merely responding to prompts and tasks.
The clearest example of that ambitious shift is Electra.
Electra is a true “AI teammate”. It operates like a developer on the Atlas team, able to complete internal engineering tasks end-to-end. Electra works proactively to maintain all of Basis’ internal tools, and lives in Slack just like the human teammates at the company.
As an example of how it works, someone at Basis wrote a Slack message to the Atlas team requesting to add a Salesforce MCP to Satellite, the unified MCP discussed earlier.
Electra saw the Slack message, and began building a Salesforce MCP into Satellite. However, it got blocked when it realized it needed a Salesforce API key. So the agent looked at Basis’ internal directory to find the person most likely to have access to that key, DM’d them in Slack, and they sent the key to Electra. The agent then tested the Salesforce MCP connector live, confirmed it worked, and then followed up with the original requestor in Slack letting them know it had added it.
Here’s how Electra works.
Under the hood, Electra is powered by Devin, the software engineering agent from Cognition. Electra has access to Devin, and spins up its own sessions via API to write code whenever it needs to.
Electra has access to Slack to communicate with the human teammates at Basis. It scopes work based on tasks assigned or opportunities it finds, then sends off a plan to Devin which writes the code. Electra receives the code once Devin is done, validates the code, and follows up in Slack with any next steps.
As needed, Electra asks for help from the Basis team. But they gave Electra access to a variety of tools, so often that’s not the case. For example, Electra has access to Satellite, their unified MCP, so Electra has immediate access to tools. It uses Notion to write notes and track the status of projects. And it can spin up its own developer environments to test its code as it builds.
Electra was a significant unlock for the Atlas team. Before Electra, roughly a third of Atlas’s time went toward maintaining what it had built. Matthew says Electra has dramatically reduced that burden.
In fact, Matthew mentioned agent maintenance was the biggest challenge he’d underestimated in getting Atlas off the ground. Ambitious agent ops teams need to solve it, because when agents get deployed edge cases emerge, lead to failures, expose missing requirements which in turn contribute to part of the roadmap to maintain the agent.
Reliability matters because an agent’s mistakes create work for someone else. If teammates have to keep fixing its mistakes then the time savings can disappear.
No matter how ambitious the agent ops team is though, it’ll still occasionally run up against potential capabilities from the AI labs as they ship their own agent innovations and push frontier models forward. Matthew’s phrasing stuck with me: you ship something genuinely cutting-edge, and within two months it’s the norm and everyone has copied it.
The Agent Operator Job Description
When I asked Matthew what type of background/skillset in a person would make for a good agent operator, he pointed to four traits: systems thinking, product taste, the ability to drive projects to completion, and user empathy.
In some ways, you’d want these four traits in any senior product hire. The difference is two-fold: your users are your teammates sitting next to you, and the level of AI fluency required for the job.
However, notice what’s not on the list - an engineering background. Matthew doesn’t have a CS degree; his background is as a product manager. And yet he ships code constantly - though most of the engineering on the Atlas team is done by their team of 4 engineers (and they’re actively hiring).
What makes that workable is a distinction Basis draws internally between vibe coding and agentic engineering. Vibe coding is for low-stakes internal tools - nobody reads the code, and if it breaks, nothing happens. Agentic engineering is for production systems: you still don’t read every line, but you’re accountable for understanding and testing what you shipped.
The difference between those two is what lets a non-engineer contribute to systems the company depends on - without generating anxiety among the engineers of letting a non-engineer touch production systems.
Another role on the Atlas team that Basis is hiring for is what they call intelligence architects - people whose entire job is context quality. Prompts, skills, data access, the details that determine whether an agent works with a complete picture or a partial one. If context sets the boundary for how good internal agent ops can be, someone should own that boundary and be responsible for pushing it forward.
And if you want this job? Sharpen the four traits I mentioned at the top of this section, and be able to make a case that you have them. Stay personally at the frontier of model capability, because a role defined by knowing what’s currently possible decays in about 2 months in 2026.
Matthew’s habit for exploring the model frontier is a great one to copy: he builds things on weekends that are experiments - things no one will ever use, specifically because they’re unbound by whether a customer might touch them. Those projects should be messy - a terrible idea for production but a great idea for a Sunday.
The Future of Agent Operations
With how quickly frontier models are developing, AI companies are growing, and the role of Agent Operator is maturing, I was curious to ask Matthew his view on how he sees Atlas team structure developing in the future, and what it might mean for the structure of agent operations teams more broadly.
Matthew expects the verticalization + platform depth to deepen. He expects each functional vertical, such as sales, to have a dedicated agent operator.
I agree with Matthew, and in fact I think that’s already happening as ‘GTM engineer’ roles are becoming ubiquitous at tech startups. We’re hiring one at Qualitate - if you’re interested, apply here!
As agents absorb more of the knowledge work that humans did before AI, we’ll require a growing percentage of employees to oversee the agents. Today, Basis has 20 employees for every person on that Atlas team, and Matthew expects that to compress to 10 to 1, and maybe even 5 to 1.
That’s pretty amazing - at 5 to 1, one in five employees spends their day building and maintaining AI systems that do the work for the rest of the company. It’s a complete upending of what org structure looks like at tech companies pre-AI.
The consensus story is that AI will shrink headcount. But the Basis story is that AI reallocates it.
What it means to be AI-Native
The term ‘AI-native’ is thrown around constantly to describe startups that have been started in the last 4 years.
What does it actually mean to be AI-native though?
Matthew told me a story about a recent conversation he had with a friend who ran the agent operations team at a very well known AI startup. The two of them were discussing what it meant to be AI-native, and came to the conclusion that there is no real end-state of being AI-native, but rather it’s about being in the state of ‘figuring it out’.
Model capabilities are changing so fast that there’s really no other answer than constantly staying on the cutting edge, and figuring out ways to leverage new AI capabilities to improve your business’s operations.
Meanwhile, if you look at what Basis actually has shipped - something like Satellite, their unified MCP, it’s not the most glamorous AI use case. In fact, they debated whether or not to publish a blog post about it. Unifying a pile of MCP connectors is not a very exciting story - but it does work, and that is what matters.
Which begs the question: how much of being ‘AI-native’ is theater vs. reality? Matthew and I agreed, it’s quite a bit of theater, but to be fair - the theater is needed. Companies need to tell a story about the future and sell that future to recruit candidates, raise capital, and sign customers. The art of building startups is shipping that future as fast as you can.
The problem comes in if you’re an employee considering joining an “AI startup”, or an investor looking to invest in one - how can you distinguish hype from reality?
Here are four questions Matthew pointed to that can help define if a startup is actually AI-native:
1. What are you doing that other companies aren’t? This is Peter Thiel’s ‘secret question’ pointed at internal operations. “We use Claude and Cursor” is not an answer to this question, because everyone uses Claude and Cursor. Matthew’s answer for Basis is a list of what they’ve shipped: Building the Atlas team before it was a trend, shipping a unified MCP before their software vendors offered one, and now hiring intelligence architects before everyone else has realized the importance of that role.
2. What’s your agent operations team ratio? What’s the ratio of people building internal agents, divided by total employee count.
3. How are your internal AI systems maintained, and who does that work? At Basis, maintenance initially consumed roughly a third of Atlas’s time. Electra now handles much of that burden.
4. Which agent would cause the most disruption if you turned it off tomorrow? Companies that can answer this have agents in production. Companies that can’t have demos.
When to Build an Agent Ops Team
Matthew had specific advice for founders considering building an agent ops team.
Before hitting product-market-fit, ignore all of this - the only job is getting customers.
After hitting product-market-fit, Matthew’s advice was to make the first agent operator hire earlier than it feels comfortable. Somewhere in the 10-to-20-person range. Basis did it at 35, which felt aggressive at the time. The economics work because the alternative is headcount: build an on-call engineering agent, and require less time from your engineers doing on-call engineering operations.
The 100x Mandate
My conversations with Matthew reinforced my belief that agent operators will become common across tech companies. Some will work on centralized Agent Ops teams like Atlas, while others will sit within individual functions, much like GTM engineers are starting to do today.
What stood out most from our conversations was how much of this new job involves not just understanding the frontier of model capability, but rather of understanding the company itself: how people work across teams, what information that doesn’t get written down is required to perform a job, and where bottlenecks lead to workflows breaking.
And over the course of our conversations this summer, as Atlas launched Electra, which took over much of the maintenance work, it became clear that even the agent operator’s work will keep changing.
As agents can increasingly own tasks end-to-end, the role of people will likely shift toward deciding which responsibilities to hand over, how to best enable them, and judge whether the agents’ work is getting done properly. Most importantly, that will allow people the time to turn their attention to problems they previously didn’t have time to tackle.
The AI models will keep improving. But - at least until we reach true recursive self-improvement - turning model improvements into useful work inside a business will be an ongoing responsibility. And increasingly, an exciting job to take on.