For most of working history, a person's role was defined by their mastery in one craft. You were the expert in your respective lane, building on years of specialization, and that encompassed the vast majority of what the job asked of you. 

But this tendency towards hyper-specialization was rarely about the limits of the individual. It was about time. 

Learning and going deep in a second or third discipline cost more hours and resources than any single job could spare. AI has now changed that math. The costs associated with learning the basics of an adjacent discipline have dropped far enough that the old trade-off — time poured into a core function where deep expertise is needed vs. time spent adding value in other areas — no longer holds. 

At TRM, we’re seeing this manifest in a new way of shaping roles: a master of one and a jack of all trades.

What we built

We recently stood up six company-wide cortexes (what we’re calling our internal AI transformation initiatives), one for each major org. Each one models how that org actually works: its AI architecture, its infrastructure, and the agents running inside it.

Some agents sit at the front line, handling routine “run the business” and day-to-day tasks. Others watch that front-line work, track what gets done, and turn it into reports and analytics. Building systems capable of doing both meant designing something akin to a neural network for each department: empowering employees to build agents for their own unique needs, teaching them how to wire feedback loops around those agents, and building best practices for reading and continually optimizing agent-produced data.

Three months ago, 226 people were working in Claude Code and TRM Agent (our terminal-based build tools) in a given month. Today we’re up to 405, with nearly all of that growth coming from non-technical teams. 639 of the tools built now run across our repositories — 544 skills and 95 internal apps.

What makes a great agent?

There are a lot of posts out there right now about people hiring and firing their agents. Most of the time that means someone built an agent and didn't like its output, so they redesigned it.

Designing an agent well leverages skills people normally collect across different roles or glean from working in different disciplines. When you sit down to build one, you have to answer design-related questions that touch other teams and roles across the business:

• Is this agent's output visible only to me, or to my colleagues?
• Can what my agent produces feed the source another agent pulls from?
• Am I building a closed loop for myself, or a shared knowledge base where agents hand work off to each other?

A good agent takes repetitive or routine work off the builder’s own plate. A great agent does work that improves outcomes for more than just one person. It contributes to a shared environment where agents build on each other's outputs, and where one agent can hand work to another colleague's agent the same way a person would.

To show employees how to do this, we decided to teach all TRMers the foundations of four other roles that were previously unknown or outside the traditional scope of most of our non-technical employees:

1. Product management
2. Engineering
3. Management
4. Data engineering

Role 1: Product management (deciding what is worth building)

When you design an agent, you’re seeking to solve a problem (and ship a solution) that helps you and your colleagues. So the first questions to ask will naturally be about product-market fit: Is this even worth building? Am I the only one who has this problem?

We looked across the company and found that our product managers already had the strongest instinct for answering these kinds of queries. So now, with their help, our AI enablement team teaches the rest of the org the foundations of product management in the context of AI agent design. We provide guidance on topics like:

• How to decide which problems to tackle first, using the Eisenhower Matrix to find high-impact, low-effort work and avoid the low-impact, high-effort trap
• How to embed the instructions for using a tool or agent inside the agent itself
• How to identify who the consumer is for the problem you are solving

Our product managers are well-versed in doing this every time they build a feature or update functionality in the products and platforms our customers rely on. Now they’re passing on that knowledge via co-hosted enablement sessions that empower the rest of the company to think and build like product managers themselves. 

Role 2: Engineering (shipping and maintaining what you build)

Once an agent is designed, a different set of skills comes into play —  requiring know-how most of our non-technical employees had never had to worry about before: maintaining a product, making updates, and integrating what they’d built into the cortex.

This involves asking questions like, “How do I make my solution accessible to other people?” and “How do I push an update without asking everyone to download a new file every time?” That’s the world our developers and engineers live in. So our team now partners with them to teach the rest of the company how to:

• Open a pull request so others can review the agent they built
• Confirm a change won’t break something else, leak data, or violate our security expectations
• Follow the peer-review process engineers have relied on for years

To get people started, we worked with our engineers to host a session introducing non-technical teams to GitHub, repos, and pull requests.

As of today, across our three repositories (internal apps, docs, and plugins), 72 people on non-technical teams have opened a pull request — including TRMers working in revenue operations, growth marketing, legal, TRM Academy, and more than twenty other departments. Three months ago, none of them had.

Role 3: Management (everyone now manages something)

Every TRMer is now a manager. Some manage people and agents, while others manage only agents. But the same foundations of management apply either way.

You review an agent's performance and output and ask, “Does it meet the standard we hold as a company?” If not, you coach it, reconfiguring the agent and its skills, instructions, and pathways until the output improves. Then you measure the performance of your agentic teammates, and keep them current as standards and business needs change.

For TRM, this means creating dashboards that collect agent outputs and understanding what needs to be measured to discern between positive or negative results. As part of their own routine, every TRMer now knows to review how their agents are performing so they can understand the impact they’re making on their role and the org.

Role 4: Data engineering (the database under the application)

The fourth area our employees are now growing expertise in is data engineering. Because now that they’re running agents that are collecting data (and feeding it into the apps they’ve built), they need to know how to make it actionable.

We’ve partnered with our data and analytics teams to provide guidance to non-technical teams around data management questions like:

• What is a database? 
• Why do I need one? How does it feed an application? 
• How do I configure my agent's output to populate the tables and schemas I am working with?

This shifts us away from having hundreds of ad hoc agents running every day, to building an organized agentic enterprise with each agent reporting somewhere.

The learning curve has never been this flat

For an individual who has never shipped a product or built an AI agent before, the learning curve to build and deploy has never been as flat as it is right now.

In the last three months at TRM, our roster of skill authors grew from zero to 81, app builders from one to 39, and non-technical pull-request contributors from zero to 72. Of the 52 people we coached directly — in office hours, one-on-ones, and guilds — 18 now have a build running in production. It’s been incredible to see our non-technical teams, in particular, expand their skill sets from mastery in one craft to fully capable builders of apps, agents, and products.

On the AI enablement team, our job is to help everyone across the company feel comfortable and fluent in the foundations and best practices of building agents. As an organization, this continuous cycle of teaching and learning has become one of the most important ways we keep pace with and develop mastery of AI.

Sound like a learning and growth environment you’d like to be part of? TRM is hiring across all teams.