Home
Apr 14, 2026
View All

Frameworks for AI Agents and Why Relationship Work Still Matters

·2 underrepresented voices

The Short Version#

Three distinct takes on agent work landed today that connect in a useful way: Lenny published a framework for categorizing agent initiatives, Maggie Appleton diagnosed why multi-agent systems break down at the team level, and Teresa Torres reminded us that even the most technical product work is fundamentally relational. Cursor 3.1 also shipped real agent workflow improvements worth noting.

Lenny Rachitsky — Not All AI Agents Are Created Equal#

Source: https://www.lennysnewsletter.com/p/not-all-ai-agents-are-created-equal Credibility: High (Lenny's Newsletter, first-party analysis from a recognized PM practitioner with strong sourcing)

What happened: Lenny published a framework for how PMs should categorize and prioritize their agent initiatives — arguing that treating all agents as equivalent leads to poor investment decisions. The core idea: different agent types carry fundamentally different risk profiles, user trust requirements, and success metrics, so the same prioritization framework you'd use for a feature doesn't apply cleanly across agent types.

Key PM patterns:

  • Categorize before prioritizing: Agents that execute autonomously (file actions, send emails, submit forms) require different confidence bars and error-recovery design than agents that advise or summarize
  • Trust asymmetry: Users tolerate more errors from read-only agents than write-capable ones — this should directly inform where you invest in human-in-the-loop controls
  • Risk-adjusted scope: An agent doing low-stakes research tasks can ship faster with less guardrail investment than one touching financial data or external communications
  • Metrics differ by type: Completion rate and accuracy matter for task agents; recall and confidence calibration matter for research/synthesis agents

Why it matters for PMs: Most teams I've talked to are prioritizing agent work by "coolness" or stakeholder enthusiasm, not by actual risk/value calculus. This framework gives you a structured reason to say "we should build the summarization agent before the auto-send agent" — and that's a conversation most teams need to have. It also maps directly to the open question of how much autonomy users are comfortable giving agents: the answer isn't one number, it's a different answer for each agent type.

Critical questions:

  • Does this framework hold at the enterprise level, where regulatory risk may override UX risk as the primary categorization variable?
  • How do you handle agents that start as advisory and gradually become more autonomous as trust is established — does the category change, and does your governance model update with it?
  • What's the right cadence to revisit agent categorizations as capability improves and user trust evolves?
  • Is there a fourth category (collaborative agents that work alongside users in real-time) that doesn't fit cleanly into autonomous vs. advisory?

Action you could take today: List every agent initiative on your current roadmap. For each one, write down: (a) read-only or write-capable, (b) reversible or irreversible on error, (c) what the user recovers to if it fails. If you can't answer all three, you're not ready to prioritize it.

Maggie Appleton — One Developer, Two Dozen Agents, Zero Alignment#

Source: https://maggieappleton.com/zero-alignment/ Credibility: High (Maggie Appleton is a design engineer and writer whose work consistently bridges technical and design thinking; first-party original essay)

What happened: Maggie Appleton published an essay arguing that as developers now routinely run dozens of AI agents simultaneously, we've created a new class of coordination problem that current tooling completely ignores. The framing: we've solved for one human + one agent, but "one developer + twenty-four agents" creates alignment, context-sharing, and conflict-resolution challenges that no existing interface or framework addresses. She calls for "collaborative AI engineering" as a distinct discipline.

Key patterns:

  • The zero-alignment problem: Agents running in parallel have no shared context, no awareness of each other's work, and no mechanism to flag conflicts — so they'll cheerfully contradict each other or duplicate work
  • Current UX is serial, not parallel: Every agent interface (Cursor, Claude, etc.) is designed for a conversation, not a coordination dashboard — there's no "what are all my agents doing right now and do they know about each other"
  • Humans as the integration layer: Right now, the developer is manually stitching together outputs from multiple agents — this doesn't scale and produces errors that are hard to attribute
  • Interface gap: We need tooling that treats agent work as a team activity, not a solo conversation — shared context stores, conflict detection, handoff protocols

Why it matters for PMs: This is the product design challenge nobody's solved yet. Cursor 3.1 just shipped tiled layout and parallel agents — but Maggie's point is that the interface change doesn't address the underlying coordination failure. If you're building products that orchestrate multiple agents, you're implicitly promising users that the agents will produce coherent, non-contradictory outputs. That promise is currently unsupported by the tooling. This also maps to the open question about user trust and error recovery: when a multi-agent system fails, users can't even tell which agent caused the problem.

Critical questions:

  • Is this a framework/tooling problem or a model problem — will better context-sharing at the model level (like shared memory or MCP) close the gap without new interface design?
  • What's the right level of abstraction for "agent awareness"? Agents knowing about each other's tasks is different from agents being able to coordinate in real time.
  • How do you test for alignment failures in multi-agent systems — what does QA look like when the failure mode is "agents contradicted each other silently"?
  • Does this problem get worse or better as models get smarter about anticipating conflicts?

Action you could take today: If your team runs multiple agents in parallel (even informally — different Claude/Cursor sessions for different parts of a sprint), document one instance where two agents produced conflicting outputs or duplicated work. That's your concrete example for why this infrastructure investment is worth making.

Cursor — 3.1: Tiled Layout and Upgraded Voice Input in the Agents Window#

Source: https://cursor.com/changelog/3-1 Credibility: High (official changelog, first-party)

What happened: Cursor shipped 3.1 on April 13, the first point release of their new Cursor 3 interface. Two main additions: a tiled layout that lets you split the Agents Window into panes to run and manage multiple agents in parallel, and upgraded voice input so you can direct agents without switching to a keyboard. This builds directly on the Cursor 3.0 release (April 2) which introduced the Agents Window itself.

Key technical details:

  • Tiled layout: Split the Agents Window into panes — each pane runs a separate agent, letting you monitor and manage multiple parallel tasks in a single view without switching contexts
  • Upgraded voice input: Voice commands can now be directed at specific agents; you can narrate what you want without breaking flow to type
  • Agents Window continuity: 3.1 is iterating on the core architectural bet from 3.0 — that developer work is fundamentally multi-agent, not single-agent, and the editor should reflect that

Why it matters for PMs: Cursor is making a concrete product bet that the next phase of developer productivity isn't faster single-agent completions — it's managing parallelism. The tiled layout is a direct UX answer to the coordination problem Maggie Appleton identified above, though (as she'd note) it addresses visibility without addressing alignment. For PMs thinking about AI coding tool adoption: this is the interface your engineers are starting to work in. The mental model is shifting from "AI assistant I talk to" to "fleet of agents I direct."

Critical questions:

  • Does tiled layout actually reduce coordination failures, or does it just make the failures more visible?
  • How does voice input interact with the tiled layout — can you address a specific pane by voice, or does it broadcast to all agents?
  • What's the cognitive load of monitoring 4+ agents simultaneously vs. sequential agent work?

Action you could take today: If your engineering team uses Cursor, ask one engineer to demo the 3.1 tiled layout on a real task. Watch specifically for: how they decide what runs in parallel, and how they handle it when two panes produce outputs that need to be reconciled.

Teresa Torres — Product Work Is Relationship Work#

Source: https://www.producttalk.org/product-work-is-relationship-work-all-things-product-podcast-with-teresa-torres-petra-wille/ Credibility: High (Teresa Torres's Product Talk blog, first-party; in conversation with Petra Wille)

What happened: Teresa Torres joined the All Things Product podcast with Petra Wille to discuss how product work is fundamentally relational — and why most of the "hard problems" in product management are actually relationship problems in disguise. The framing cuts against the current trend of treating PM as an increasingly technical discipline: the more AI handles the analytical and execution work, the more the distinctly human work of building trust, navigating disagreement, and aligning stakeholders becomes the core PM value-add.

Key PM patterns:

  • Relationship as leverage: The PMs who get the most out of AI tools are the ones who can bring stakeholders along — the tool advantage compounds when you can actually ship what you discover
  • Discovery is relational: Continuous discovery isn't just a research method — it's a practice that builds trust with customers over time, and that trust is what gets you honest feedback
  • Disagreement is data: When engineers push back on a direction, that's not a people problem to manage — it's a signal about what the team doesn't yet understand together
  • AI amplifies existing relationship quality: Teams with strong alignment will use AI tools to go faster; teams with weak alignment will use AI tools to ship the wrong things faster

Why it matters for PMs: This is a useful counterweight to the "AI is collapsing PM" narrative (Keith Rabois made waves with that framing last week). Teresa's implicit argument: what AI can't replace is the relational infrastructure that makes product decisions legitimate and sticky. If your team is over-investing in AI tooling and under-investing in stakeholder relationships, the tooling won't save you. This connects to the open question about how PM roles are changing — her answer is that the role becomes more relational, not less, as AI absorbs the analytical burden.

Critical questions:

  • If relationship work becomes the core PM differentiator, how do you evaluate PM candidates who are technically strong but relationally weak — and vice versa?
  • Does this framing hold in early-stage startups where the PM is often the only product person and stakeholder management is simpler?
  • How do you measure relationship quality in ways that inform PM development, not just performance reviews?

Action you could take today: Pick one current disagreement on your team (with engineering, design, or a stakeholder) and reframe it as "what do we not yet understand together?" rather than "how do I convince them." Write down what information would change their mind — then ask whether you have it.

Quick Hits#

The Thread#

The multi-agent coordination problem is becoming the central product design challenge of 2026. Cursor 3.1 shipped tiled parallel agents. Lenny published a framework for categorizing agent risk. Maggie Appleton named the structural gap none of these tools have solved yet. Three different angles on the same thing: we've moved from "will AI agents work?" to "how do you manage a fleet of them?" — and the interface, governance, and PM frameworks are all still catching up.

Sit With This#

Maggie Appleton's essay argues that when a developer runs two dozen agents in parallel, those agents have zero shared context — they'll contradict each other, duplicate work, and the developer ends up as the manual integration layer. Cursor 3.1 addressed this with a tiled layout (better visibility), but not with shared context or conflict detection.

For your product: If you shipped a multi-agent or multi-step AI workflow today, how would a user know when two agents produced contradictory outputs? Do you have a detection mechanism, a recovery path, or are users currently the integration layer — and do they know that's the deal?