Most Valuable Skill of 2026: Managing AI Agents

Business-focused takeaway: “Agent operator” replaces traditional engineering management

• Core claim: Whoever can run teams of AI agents (not just use one-off tools) will outperform others in the AI age.
• Positioning: You become an “agent manager”—whether you’re a founder, IC, or non-technical operator.
• Implied practical outcome targets:
  • Speed: “ship faster”
  • Scale: run ~5–10 cloud sessions concurrently
  • Throughput: dashboard example showing ~22–25 PRs/day, sometimes ~40/day
  • Revenue growth (startup context): revenue projected to 4x this month (as stated by the founder)

“Agent operator” is framed as the new operating role for managing execution, not just tools.

---

Framework / operating system for managing AI agents

Agent management cadence

• Expect 10–20 high-stakes decisions by lunch
• Use thread pinning:
  • Pin the most important work
  • Let the rest run with less oversight
• Set a check-in interval (mentioned: ~every 25 minutes) to avoid constant overwhelm
• Maintain a daily written “most important things” list (speaker mentions a paper system)

Infrastructure philosophy

• Prefer cloud development environments over local machines to reduce workflow collisions and scheduling overhead
• Use the “software factory” concept:
  • Agents eventually write / review / ship most code

Delegation rule

• Agents can scale execution, but you cannot delegate high-stakes decisions
• You must stay available for real-time feedback/approvals

---

Playbook #1: Use “cloud agents” to remove coordination overhead

Principle

• Work in cloud VMs/sessions so multiple agent tasks don’t collide.

What changes vs local development

• Local dev requires managing separate checkouts/worktrees/directories
• Cloud VM sessions can be created as needed (browser “new session” → fresh environment)

Concrete operating behavior

• Speaker runs ~5 cloud agents, often 10
• Claim: cloud removes mental overhead of:
  • syncing
  • conflicts
  • branch confusion

Example constraints

• Local may still help for heavy front-end/UI work
• But move to cloud quickly once concurrency matters

Competitive positioning / attitude

• The speaker argues “local maxis” are outdated:
  • once you’re truly shipping, local limits throughput and slows delivery

---

Playbook #2: Build “automations” around repetitive business operations

Definition used

• Automations replace tasks that previously required recurring human check-ins/meetings.

---

A) QA: “end-to-end signup test” automation (browser-based)

• Use case: catch issues browser testing finds that standard suites might miss
• Implementation pattern:
  • Define a Dev-style playbook (steps that represent correct behavior), not a single “skill”
  • Run on a schedule: 3 times per week (Mon/Wed/Fri)
  • On failure:
    • record evidence (speaker references Devon features like video recording + annotation + self-review)
    • trigger a child triage session to diagnose and fix
• Cost (explicit): each run costs about ~$60 in tokens
• Expected management loop:
  • Automation posts/alerts results (example: Slack) so the manager knows what to review
  • Manager verifies outcomes and tracks created PRs
  • Purpose: avoid silent failures

---

B) “Production watchdog” automation (daily customer activity summarization)

• Time: daily at 9:00 a.m.
• Operation:
  • agent scans database events for paid customers
  • produces rolled-up JSON summary displayed in an admin UI
  • includes links to the specific customer UI/session where relevant
• Business purpose: acts like a chief-of-staff report:
  • what customers did yesterday
  • what went well
  • what broke
• Example insight value:
  • logs may look fine, but linked UI evidence reveals real UX problems in the agent-produced flow

---

C) “Self-improvement loop” for agent quality (rubric grading + fixes)

• Example system: “Grace” paralegal agent
• Mechanism:
  • daily automation grades chats using a rubric
  • if below threshold, it triggers a child session to fix issues and ship improvements
• Output impact (claim): ~3 shipped fixes per day
• Operational value:
  • catch “paper cut” UX issues early
  • reduce manual review time while keeping quality via structured grading

---

Cost / KPI considerations (light on CAC/LTV, heavy on cost controls)

Token budget guidance

• Costs must stay within what’s economically viable
• Planning heuristic mentioned:
  • ~$5k/month per employee as a ceiling ballpark for “real engineering work”

Routing and cost management details

• One month spent ~$20k in tokens was described as “too much”
• Coding loops use a cheaper fine-tuned model:
  • “SWE 1.7” for coding work
  • described as much cheaper than frontier models (examples mentioned: “Opus 48 / GPT-5.6”)
• Cost example:
  • “about five bucks per session” for certain loops (speaker’s estimate)

Embedded actionable recommendation

• Use model routing:
  • different models for different steps
  • cheaper specialized models for iterative loops
  • premium models only when necessary
• Avoid building core engineering on “frontier lab stacks” if it creates:
  • long-term lock-in
  • unclear pricing incentives
• Speaker preference: independent agent labs to optimize costs

---

Product/strategy example: building an “AI divorce agent” business and scaling ops

• Company: AI divorce agent for law firms (family law framed as a “dirty topic”)
• Scaling context:
  • seed round, scaling quickly
  • revenue projected to 4x this month
  • founder currently at 1 employee, preparing first hires
• Ops lesson applied:
  • use cloud + agent management + automations
  • multiply output and track real customer activity without hiring large numbers of humans early

---

“Software factory” trajectory (where agents are headed)

• Claimed direction:
  • 100% of code writing
  • 100% of code review
  • 100% of shipping
• Practical advice:
  • Early/solo stage may tolerate lighter setups (example mentioned: ~$200/month “agent on your machine” for prototypes)
  • For real products with PMF and hiring:
    • build a software factory using independent agent labs
    • speaker argues in-house or walled gardens become costly/rigid

---

Additional leadership / credibility play

Reputation strategy

• Build public credibility by sharing learnings on X (Twitter)
• Not required to be polished:
  • “say I don’t know” is acceptable

Networking mechanism

• Speaker credits relationship-building for opportunities
• Example: invited to the show via that network

---

Presenters / sources

• Ryan Carson (guest; founder/CEO)
  • Provides operational setups, frameworks, and examples.
• Greg (host)
  • Asks questions and frames the episode (name not explicitly stated in subtitles).