AI Agents as First-Class Platform Citizens: Building for AI Coworkers or Automating Ourselves Into Irrelevance?

General
1

The conversation in platform engineering circles has shifted dramatically in the past year. We’re no longer just asking “how do we integrate AI tools?”—we’re asking “should AI agents get RBAC permissions and resource quotas like any other user?”

If you’re running a modern platform team, you’ve probably already answered this question. According to recent research, 94% of organizations now identify AI as either ‘Critical’ or ‘Important’ to the future of platform engineering. And the architectural decisions we’re making today reveal something profound about what we think we’re building.

The Technical Reality

Here’s where we are in 2026: Platform teams are treating AI agents as first-class citizens. That means:

  • RBAC permissions defining what agents can and cannot access
  • Resource quotas limiting token usage and inference costs
  • Audit trails tracking every agent action for compliance
  • Governance policies that mirror human user controls

This isn’t theoretical—organizations are implementing permission-aware access, runtime enforcement, and tamper-evident audit logs for AI agents right now. We’re introducing AI-specific budgets to manage token and inference costs with the same precision we apply to cloud infrastructure spending.

From a pure engineering standpoint, this makes sense. AI agents consume resources, access data, and trigger actions. Of course they need governance.

The Philosophical Question

But here’s what keeps me up at night as a product leader: Are we building infrastructure for AI coworkers, or are we architecting our own irrelevance?

The data points in both directions:

The Replacement View:

  • McKinsey deployed 20,000 AI agents
  • Amazon cut 16,000 roles
  • Investors explicitly see “2026 as the year of agents as software expands from making humans more productive to automating work itself”

The Augmentation View:

The truth? Both are probably happening simultaneously.

Why This Architectural Decision Matters

When we grant AI agents the same infrastructure privileges as human users, we’re making a statement about permanence. We’re not building “tools that might help”—we’re building infrastructure for entities we expect to persist as first-class participants in our systems.

This has downstream effects:

  1. Budget allocation: AI agent resource consumption becomes a line item, competing with human hiring
  2. Security posture: Agent permissions become attack vectors we must defend
  3. Organizational design: Teams optimize for agent utilization, not just human productivity

From a product strategy perspective, the question isn’t just technical—it’s about what business we think we’re in. Are we building platforms that make human teams more effective? Or are we building platforms that gradually need fewer humans?

Where I Land (For Now)

I believe we’re in a “both/and” moment, not an “either/or.” Some roles will automate. Others will augment. Most will transform in ways we can’t fully predict.

But the architectural choice to treat AI agents as first-class platform citizens forces us to confront these questions now, not later. And that’s probably healthy.

If you’re implementing RBAC for AI agents, you should also be asking:

  • What jobs are we designing agents to do?
  • Are we investing in reskilling humans for “higher-value work”?
  • Do we have transparency with our teams about this strategy?
  • Are we optimizing for augmentation or replacement?

My Question to This Community

For those of you building or working with platform teams:

What are you actually building for—enhancement or replacement?

And more importantly: Do your engineering teams know which one you’re aiming for?

I’m genuinely curious how others are navigating this. The infrastructure decisions we make today will shape the workforce reality we live in tomorrow.

2

David, you’ve nailed the tension that every CTO is wrestling with right now. But I want to push back on framing this as a philosophical question—it’s actually a governance imperative that we’ve dressed up in existential clothing.

Why RBAC for AI Agents Isn’t Optional

Last year during our cloud migration, we discovered AI agents were consuming 40% of our API quota without anyone tracking it. Developers had spun up coding assistants, chatbots for customer support, and automated testing agents—all legitimate use cases—but none were governed.

The result? We hit rate limits during a critical deployment. Production impact. Customer-facing incident.

That’s when we implemented token budgets and RBAC for AI agents. Not because of ideology, but because ungoverned AI agents are an operational liability.

The Governance Without Bureaucracy Challenge

Here’s what treating AI agents as first-class citizens actually looks like at our company:

  • Permission boundaries: Agents can read docs, write tests, analyze logs—but cannot deploy to production or access customer PII
  • Resource quotas: Each team gets a token budget that they allocate between human and AI usage
  • Audit trails: Every agent action is logged, just like we log privileged user actions
  • Review process: High-risk agent permissions require approval, just like database access

This isn’t about replacing humans. It’s about preventing chaos.

The False Binary of Augmentation vs Replacement

You asked whether we’re building for enhancement or replacement. I think that’s the wrong question because it assumes a universal answer.

The reality we’re seeing:

  • Some roles automate: Tier-1 support, basic code reviews, log analysis
  • Some roles augment: Senior engineers use AI to write boilerplate faster, allowing them to focus on architecture
  • Most roles transform: DevOps became SRE, SRE is becoming platform engineering, platform engineering will become… something else

Our support team is a great example. We deployed AI agents for tier-1 tickets. We didn’t lay anyone off—we shifted the team to tier-2/tier-3 work and customer success. Net result: better customer experience, more fulfilling work for humans, lower cost-per-ticket.

But that required intentional reskilling investment. If we’d just deployed agents without a people strategy, you’re right—we’d be automating ourselves into irrelevance.

My Answer to Your Question

What are we building for? Organizational capability, not headcount reduction.

Do our teams know? Yes, because we communicated it explicitly:

  • “AI agents handle toil so humans can focus on judgment”
  • “If an agent can do your job, we’ll train you for a better job”
  • “Budget for reskilling is non-negotiable”

The architectural decision to grant agents RBAC permissions doesn’t determine the outcome. The leadership strategy around that architecture determines the outcome.

Treating AI agents as first-class citizens is table stakes for modern platform engineering. The question is whether you’re using that capability to augment your team’s effectiveness or quietly planning their replacement.

We chose augmentation. But it required deliberate effort, not just good intentions.

3

Michelle, I appreciate the pragmatic take on governance—you’re absolutely right that RBAC for AI agents is an operational necessity. But I want to surface something we don’t talk about enough: the signal this sends to our human teams.

The Morale Question Nobody’s Asking

When we started implementing AI agent permissions at our financial services company, one of my senior engineers asked me directly: “Are we building our replacements?”

I gave him the standard answer about augmentation and focusing on higher-value work. He responded: “That’s what they told the bank tellers when ATMs rolled out.”

He wasn’t wrong to be skeptical. And treating AI agents like users—granting them permissions, allocating budgets, tracking their productivity—reinforces the perception that we’re building infrastructure for entities that will eventually need fewer humans to operate it.

The Data Is Mixed (And That’s The Problem)

David cited the Federal Reserve research showing AI augments experienced workers but substitutes for entry-level workers. In financial services, we’re seeing exactly this pattern.

Our senior architects? More productive than ever. AI helps them scaffold code, generate test cases, analyze system logs.

Our junior engineers? Struggling. The tasks they used to learn from—writing straightforward CRUD APIs, debugging common errors, writing basic tests—are increasingly done by AI agents.

So what’s their learning path now? How do they become senior engineers if the junior-to-mid progression is automated?

The Compliance Angle (Which Forces Our Hand)

Here’s the uncomfortable truth: In regulated industries, we have to implement RBAC and audit trails for AI agents. It’s not optional.

When AI agents access customer financial data, regulatory frameworks require:

  • Audit trails showing what was accessed and why
  • Permission controls preventing unauthorized access
  • Accountability for agent actions

So we’re implementing exactly what David described—RBAC, resource quotas, governance policies—not because we’re philosophical about AI’s role, but because compliance demands it.

But Michelle’s point stands: Governance doesn’t dictate intent. We can govern AI agents responsibly AND use them to augment our teams.

What We’re Actually Building For (And Whether We’re Honest About It)

To answer David’s question: We’re building for competitive necessity.

If we don’t implement AI agents with proper governance, our competitors will. And they’ll ship faster, operate cheaper, and outcompete us.

But here’s what I told my team:

“We’re implementing AI agents because we have to. But we’re also committing to reskilling anyone whose job gets automated. If AI takes your work, we’ll train you for new work. No layoffs due to AI adoption—full stop.”

Do I know if we can keep that promise? No. But I’d rather set that intention explicitly than pretend we’re not making consequential decisions about people’s careers.

The Question I’m Wrestling With

Michelle, you said “if an agent can do your job, we’ll train you for a better job.” I love that framing.

But what happens when “better jobs” require a skill ceiling that not everyone can reach? What happens when the remaining human work requires senior-level judgment that takes 10 years to develop?

We can’t all be architects and principal engineers. Someone has to do the junior and mid-level work. If AI agents do that work, what’s the new career ladder?

I don’t have answers. But I think platform teams have a responsibility to partner with engineering leadership on this, not just build infrastructure and hope for the best.

Real talk: If we’re granting AI agents first-class citizenship in our platforms, we need to ensure our human employees feel like first-class citizens in our organizations.

4

Okay, I need to come at this from a different angle because as a designer, I can’t stop thinking about what our infrastructure choices reveal about our values.

Infrastructure as a Mirror

When we design systems, we reveal what we care about. And right now, we’re designing AI agent permission systems with more intentionality than we ever designed career development systems for humans.

Luis’s point about junior engineers losing their learning path? That’s not a side effect of AI agents—that’s a design failure. We optimized for agent efficiency without designing for human growth.

And that tells me something about our actual priorities.

A Story From My Failed Startup

During my startup’s final months, we were hemorrhaging cash. Our CTO suggested automation to “free up the team for higher-value work.”

Sounds familiar, right?

Here’s what actually happened: We automated customer support (AI chatbot), content moderation (ML classifier), and data entry (RPA). The people who did those jobs? Laid off. The “higher-value work” we’d supposedly freed them for? It didn’t exist.

We weren’t automating to make our team more effective. We were automating because we couldn’t afford the team.

But we told ourselves—and them—a story about augmentation and upskilling. We lied. Or maybe we lied to ourselves first.

The 9% Stat That Nobody’s Talking About

David mentioned that only 9% of executives want to replace their entire workforce with AI.

But here’s what bothers me: 91% don’t want FULL replacement, but how many are okay with PARTIAL replacement?

If you’re implementing RBAC for AI agents, you’re allocating resources. Michelle mentioned token budgets that teams allocate “between human and AI usage.” That’s literally a zero-sum game—every dollar spent on AI agent compute is a dollar not spent on human hiring.

I’m not saying that’s wrong. I’m saying we should be honest about it.

What Transparent Design Would Look Like

If we’re serious about designing AI agent infrastructure that augments rather than replaces, here’s what I think that requires:

1. Parallel investment in human growth

  • For every dollar spent on AI agent infrastructure, allocate proportional budget for reskilling
  • Make career ladders that explicitly show post-automation roles
  • Design learning paths that prepare people for the work AI can’t do (yet)

2. Permission parity

  • If AI agents get resource quotas, do humans get protected development time?
  • If agents get audit trails showing productivity, do humans get protection from surveillance?
  • If we optimize agent utilization, are we equally optimizing human fulfillment?

3. Honest communication

  • Stop saying “this will free you up for higher-value work” without defining what that work is
  • Be explicit: “These 5 roles will likely automate in the next 2 years, here’s the transition plan”
  • Share the business case: Are we doing this to grow capability or reduce headcount?

Why I’m Not Anti-AI (But I Am Pro-Transparency)

I use AI tools every day. They make me better at my job. I’m genuinely excited about what we can build with AI augmentation.

But I watched my startup automation rollout destroy people’s livelihoods while we used augmentation language to avoid accountability.

So when I see platform teams building RBAC for AI agents, I don’t question the technology—I question the intent.

Are you building this to make your human team more capable? Or to make them more optional?

And more importantly: Are you being honest with them about which one it is?

My Challenge to Platform Teams

Before you implement AI agent governance, ask:

  • Have you invested equally in human career development systems?
  • Have you communicated the business case transparently?
  • Have you designed for augmentation, or are you retrofitting that narrative onto cost-reduction?

Because the infrastructure you build reveals what you actually value. And right now, a lot of companies are building infrastructure that treats AI agents like first-class citizens while treating humans like resources.

That’s a design choice. And design choices have consequences.

:artist_palette: (Okay yes, ONE emoji. I earned it.)

5

Maya, your design lens just reframed this entire conversation for me. You’re absolutely right—infrastructure reveals values. And if we’re building sophisticated governance for AI agents but not investing proportionally in human development, we’re showing what we actually prioritize.

But I want to share what intentional augmentation looks like when leadership commits to it, because I think it’s possible—just rare.

What We Did (And Why It Worked)

At our EdTech company, we implemented AI agents for tier-1 customer support, basic code reviews, and documentation generation. Classic automation targets.

But before we deployed a single agent, we did three things:

1. Mapped the impact honestly

We identified which roles would be affected:

  • 12 tier-1 support specialists
  • 8 junior engineers doing primarily code review and testing
  • 4 technical writers doing documentation maintenance

We didn’t sugarcoat it. We said: “These specific tasks will be automated. Here’s the timeline.”

2. Designed new roles collaboratively

We didn’t just tell people “you’ll do higher-value work.” We worked WITH them to design new positions:

  • Support specialists → Customer success strategists (analyzing AI support data to improve product)
  • Junior engineers → Product engineers (focusing on feature development, mentored by seniors)
  • Technical writers → Developer experience engineers (owning documentation architecture, not just content)

Key point: We created these roles before we deployed the agents. Not after. Not “we’ll figure it out.”

3. Invested in the transition

  • 3-month training programs for each role transition
  • Mentorship from existing team members
  • External courses and certifications (company-paid)
  • No loss of compensation during transition

Total cost? About $400K. Roughly the same amount we spent on AI agent infrastructure.

The Results (Good and Complicated)

What worked:

  • Zero involuntary turnover due to AI implementation
  • Team morale actually improved (people felt valued during change)
  • Product velocity increased because humans focused on strategic work
  • Customer satisfaction scores went up (AI handled volume, humans handled complexity)

What was hard:

  • Not everyone made the transition successfully. 3 people decided the new roles weren’t for them and left voluntarily.
  • The training timeline was longer than we projected. 3 months became 5-6 for some folks.
  • Some senior engineers resented having to mentor during the transition (we addressed this in performance reviews)

The honest truth:
We didn’t preserve every job in its original form. We transformed roles. And transformation is uncomfortable, even when it’s well-supported.

Responding to Luis’s Concern About Career Ladders

Luis asked: “What happens when remaining work requires senior judgment that takes 10 years to develop?”

This is the hardest question, and I don’t have a perfect answer. But here’s what we’re seeing:

The junior-to-mid progression IS changing:

  • Traditional path: Write CRUD APIs → Debug production issues → Design features → Architect systems
  • AI-augmented path: Partner with AI to implement features → Own product outcomes → Lead cross-functional initiatives → Drive platform strategy

The new progression accelerates some skills (strategic thinking, product sense, cross-functional leadership) while de-emphasizing others (syntax mastery, basic debugging).

Does this mean fewer engineers overall? Maybe. But it also means different engineers.

We’re hiring fewer junior engineers, but we’re hiring more “experienced product engineers” who can work at the human-AI boundary—people who can prompt effectively, review AI-generated code critically, and focus on outcomes over implementation.

Maya’s Challenge: Are We Being Honest?

Maya asked if we’re being honest about intent. Here’s my honest answer:

We ARE using AI agents to reduce operational costs.

But we’re ALSO using them to expand capability. Our support team now handles 3x the ticket volume with the same headcount—but that headcount is doing fundamentally different (and more valuable) work.

The World Economic Forum’s projection of agents handling 30% of repetitive tasks is playing out in our org. But “freeing workers for higher-value work” only happens if you create that higher-value work and train people to do it.

Most companies skip both steps and then act surprised when “augmentation” turns into “replacement.”

To David’s Original Question

What are we building for? Organizational capability that requires fewer people to operate but creates more value per person.

Do our teams know? Yes. We’re transparent:

  • “We’re using AI to handle volume so you can focus on impact”
  • “Some traditional entry-level paths will change—here’s the new onboarding plan”
  • “We’re investing in your transition, but the job you have today won’t exist in this form in 2 years”

The hard part: Even with investment and transparency, not everyone will successfully make the transition. And that’s a loss we need to acknowledge.

The Platform Team’s Role in This

Platform teams building AI agent infrastructure have a responsibility beyond just technical implementation:

  1. Partner with People teams on transition planning
  2. Quantify the impact on roles, not just efficiency gains
  3. Build transition costs into the ROI (don’t treat human investment as separate)
  4. Communicate transparently about what work is being automated

If you’re implementing RBAC for AI agents without parallel investment in human development, you’re not building for augmentation—you’re building for replacement and calling it something else.

The infrastructure choice doesn’t determine the outcome. But infrastructure without a people strategy has a very predictable outcome.

And it’s not augmentation.