Home
May 25, 2026
View All

What AI Agents Actually Need: Terminology, Autonomy, and Job Displacement

The Short Version#

Today's research clusters around a single tension: the more capable AI agents get, the more urgent it becomes to define what they actually are, who controls them, and what they displace. Thomas Wolf published a glossary that cuts through agent terminology confusion, Benedict Evans analyzed which jobs are actually exposed to AI disruption, and Dan Shipper's Lenny interview articulates why more automation means more humans needed — not fewer.

Hugging Face (Thomas Wolf) — Harness, Scaffold, and the AI Agent Terms Worth Getting Right#

Source: https://huggingface.co/blog/agent-glossary Credibility: High (first-party post from Hugging Face CSO, one of the most credible voices on open AI infrastructure)

What happened: Thomas Wolf published a glossary post attempting to standardize the vocabulary around AI agents — specifically distinguishing between terms like "harness," "scaffold," "orchestrator," and "agent." The goal is to reduce the ambiguity that makes agent system design conversations go sideways. Wolf argues that the field has been talking past itself, using "agent" to mean everything from a single LLM call to a fully autonomous multi-step system, and that this sloppiness in language is causing real design errors in production systems.

Key conceptual patterns:

  • "Harness" refers to the outer wrapper that controls LLM calls (prompts, context injection, response parsing) — the static shell
  • "Scaffold" is the dynamic structure around LLM calls that changes based on output — loops, branching, retries
  • "Orchestrator" is the controller that directs multiple agents or tools toward a shared goal
  • "Agent" proper is a system that perceives state, decides on actions, and executes them — the full loop
  • Wolf's point is that most things people call "agents" are actually harnesses or scaffolds, and that matters because it changes what guarantees you can make about behavior

Why it matters for PMs: Imprecise terminology isn't just an engineering problem — it's a product spec problem. If your PRD says "the agent will handle X autonomously," you need to know whether you're building a harness (predictable, constrained) or an actual agent (adaptive, harder to test). The distinction also affects how you set user expectations. A "harness" can be described to users with high confidence; an "agent" requires communicating uncertainty and error recovery paths. This post gives you the vocabulary to have that conversation with your engineering team at the right level of precision.

Critical questions:

  • Does this taxonomy hold up when systems combine all three layers? Most production systems aren't cleanly one thing.
  • Wolf is coming from an open-source, research-adjacent context. Does this vocabulary map cleanly onto how enterprise buyers and enterprise engineers talk about these systems?
  • At what point in the build process should PMs care about this distinction? Is it spec-time, architecture review, or QA?
  • How do you write user-facing copy that reflects this difference without confusing people?

Action you could take today: Pull up the spec or PRD for any agentic feature you're currently building and audit whether you've been using "agent" as a catch-all. If you have, rewrite the relevant sections using Wolf's framework — harness, scaffold, or orchestrator — and see if the implied product guarantees change.

Benedict Evans — Predicting AI Job Exposure#

Source: https://www.ben-evans.com/benedictevans/2026/5/24/ai-job-exposure Credibility: High (Benedict Evans is one of the most rigorous independent tech analysts; his posts are evidence-driven and regularly cited by product leaders)

What happened: Evans published an analysis of how to think about which jobs are actually exposed to AI disruption — pushing back on the frameworks that simply ask "can AI do this task?" He argues that task-level analysis misses the point. What matters is whether the task is the bottleneck in the job, whether the human in the role can redirect their time to other tasks when AI handles part of their work, and whether the economic structure of the role changes when AI reduces time-on-task. His conclusion: exposure to AI is not the same as displacement by AI, and most prediction frameworks conflate the two.

Key analytical patterns:

  • Task automability doesn't equal job displacement — you have to ask what the worker does with the freed time
  • Jobs where the AI-automatable task is the core value-generating activity (not just the overhead) are most exposed
  • Roles defined by judgment, relationship management, or physical presence are less exposed even when their admin work is automatable
  • The economic question is whether AI reduces the unit cost of output — if it does, demand may increase (Jevons paradox) rather than headcount decreasing
  • Evans flags that prediction models tend to overcount displacement in complex, multi-task roles

Why it matters for PMs: This is directly useful for any PM building AI features that touch knowledge worker workflows. The common pitch — "our AI automates X, saving users Y hours" — looks different under Evans's lens. If X is overhead and not core value creation, users will adopt it happily and redirect to the work that actually matters. If X is the core work, you're in more complicated territory: is your feature a productivity multiplier or a headcount reduction tool? That framing affects how you position it, how buyers evaluate it, and what retention looks like. It also connects directly to the open question of how user expectations for AI-powered features evolve over time.

Critical questions:

  • Evans's framework is analytically sharp but he doesn't publish the underlying data. Is this descriptive or prescriptive?
  • How should PMs use this when their product spans multiple user segments where the same feature has different job-exposure profiles?
  • Does the Jevons paradox argument hold for all knowledge work, or only roles where demand for output is elastic?
  • If you're building a B2B AI product, does your buyer's procurement team evaluate "job exposure" and how do you get ahead of that?

Action you could take today: Pick one of your AI features and apply Evans's test: is the task it automates the core value-generating activity in the user's role, or is it overhead? Write down your answer and check whether your positioning, onboarding, and retention hypothesis reflect that distinction.

Dan Shipper on Lenny's — The AI Paradox: More Automation, More Humans, More Work#

Source: https://www.lennysnewsletter.com/p/the-ai-paradox-dan-shipper Credibility: High (Dan Shipper is founder of Every, has been building AI products hands-on since 2022, and this interview was published by Lenny Rachitsky — both are credible voices)

What happened: Dan Shipper joined Lenny's podcast to argue a specific and counterintuitive point: as AI gets better at autonomous work (inside tools like Codex and Claude Code), the demand for human judgment doesn't shrink — it grows. His core claim is that the CLI era is already here and most "future of coding" discourse is running behind it, that every agentic workflow needs a human to define the goal, review the output, and handle edge cases, and that this creates a massive opening for PMs and designers who understand both the user problem and how to direct AI work effectively. Shipper is also making a structural argument: the bottleneck in AI-augmented teams isn't code generation, it's knowing what to build.

Key patterns from the interview:

  • "Most work will happen inside Codex or Claude Code" — not inside chat interfaces or wrapped consumer apps
  • The CLI era means work is increasingly defined by written specs, structured prompts, and agent configurations rather than GUIs
  • Every agent needs a human in the loop: not to supervise line by line, but to define intent, handle ambiguity, and close the feedback loop
  • Shipper is "wildly bullish on PMs and designers" because their core skill — translating user needs into clear requirements — is exactly what agent orchestration requires
  • The "after automation" paradox: better models create more total work because they lower the activation energy for starting new projects, which means more projects get started

Why it matters for PMs: This is a direct argument that PM skills are not being automated away — they're becoming the bottleneck. If the hard part of software production shifts from "write the code" to "know what to build and specify it clearly," then PMs who invest in clear problem articulation, user research, and structured spec-writing become more valuable, not less. The flip side: PMs who lean on vague requirements and iterate through developer conversations will struggle as the human-agent interface increasingly requires precision. This connects directly to the open question of how PM roles and team structures are changing with AI.

Critical questions:

  • Shipper is building AI products at Every, which skews toward small-team, high-autonomy contexts. Does this "more humans needed" argument hold in larger enterprise organizations where AI adoption is more constrained?
  • Is the bullishness on PMs and designers contingent on those PMs actually learning to direct AI work, or does it apply broadly?
  • The CLI era framing assumes a level of technical comfort that most PMs don't have. What's the realistic path for PMs who don't write code or use terminal tools?
  • How does the "more projects started" dynamic affect product teams' capacity to maintain and iterate on what already exists?

Action you could take today: Write a one-paragraph, structured problem statement for your next feature — as if you were briefing an AI agent rather than a human developer. Notice where you reach for vague language or implicit context. That's your gap.

Quick Hits#

  • Thomas Wolf / Hugging Face: Published a companion piece on Nemotron-Labs diffusion language models and speed-of-light text generation — relevant if you're evaluating inference latency as a product constraint (2026-05-23): https://huggingface.co/blog/nvidia/nemotron-labs-diffusion

  • Simon Willison: Shipped datasette 1.0a30 and datasette-agent 0.1a4 in the same week — the agent layer is getting closer to the 1.0 release, worth watching for anyone building analyst-facing AI tools on top of structured data (2026-05-24): https://simonwillison.net/2026/May/24/datasette-agent/#atom-everything

  • Lenny Rachitsky / Felix Rieseberg (Anthropic): Interview with the engineer behind Claude Cowork showing how he uses Claude to build 3D house walkthroughs from floor plans, track promises automatically, and create a $20 hardware buddy — concrete examples of what applied Claude usage looks like from inside Anthropic (2026-05-25): https://www.lennysnewsletter.com/p/how-the-engineer-behind-claude-cowork

  • Chris Olah (Anthropic): Spoke at the presentation of Pope Leo's first encyclical on AI, calling for "earnest, thoughtful critics" and flagging three urgent areas: widespread job displacement, unequal distribution of AI benefits, and the unsolved problem of interpreting complex system behavior (2026-05-25): https://x.com/ch402/status/2056406734454067560

  • ElevenLabs: Crossed $500M ARR — the fastest voice AI company to hit that milestone, now backed by BlackRock and NVIDIA. If you're making build vs. buy decisions on voice features, this signals the category has real enterprise momentum (2026-05-05): https://elevenlabs.io/blog/500m-arr-and-new-investors

The Thread#

The job displacement question is getting more specific, and that's actually useful. Evans is asking which tasks matter within jobs; Shipper is arguing the bottleneck is shifting from execution to intent; Olah is calling for critics who engage seriously rather than dismissing concerns. What's emerging isn't consensus — it's a better set of questions. For PMs, that precision matters: "will AI automate my users' jobs?" is too blunt. "Will AI automate the part of their job that creates the most value?" is the question worth tracking.

Sit With This#

Dan Shipper argues that as AI handles more code execution, the bottleneck shifts to knowing what to build — and that PMs who can specify intent clearly become more valuable. But that's a best-case framing.

For your product team: Is the quality of your team's written specs and problem statements actually good enough to direct an AI agent effectively? And if not, is that a skill gap you're actively closing — or one you're hoping won't matter?