Positioning Sheets — Authority and Delegation Boundaries at OpenAI and Stripe

Both companies shipped production agent infrastructure during Labor Day week. OpenAI's Agents API went live September 10. Stripe's Link wallet integration with Meta's Muse launched September 8. Both exposed the same gap: the agent can act, but the design layer governing when it must stop and ask is either absent or locked at a single setting.

That gap is your positioning surface this week.

OpenAI — Product Designer, Identity

Their problem

The Identity role posting asks for mental models and interaction patterns governing what an agent may access, who it represents, and when confirmation or stronger authentication should appear. The Agents API shipped September 10 with persistent sessions, subagent delegation, tool use, and cancellation. The API's documented gaps land inside the Identity designer's mandate:

• Cancellation stops the turn but doesn't address external effects. If a tool call already triggered an action outside OpenAI's system, cancellation preserves the session without describing reversal.
• Traces arrive after the answer. Observability data assembles after a turn ends. The user may have already acted on the output before the trace is available.
• Missed stream events are not replayed. A client that disconnects must reconstruct state from the durable session. The API does not re-deliver what happened during the gap.

These are identity and authority problems. The posting's stated tension — "protect sensitive actions while minimizing unnecessary friction" — is the design translation.

Lead with this

CarrierIQ's graduated review states. The Issue #10 sheet positioned these as attention thresholds. That framing holds, but the Agents API makes it more specific. CarrierIQ doesn't give the user a single approve/deny gate. It returns results tagged Bindable, Normalize, Referral, or Call review — each state telling the user what kind of commitment this result requires before reaching the Approve Bind gate. That maps directly to the Identity role's mandate: what type of authorization does this action require.

The Trust essay's progression. Watch → Verify → Delegate gives the Identity team a design vocabulary for the spectrum between full human oversight and standing agent authority. The Agents API has the infrastructure for delegation. It does not have the identity-layer design that governs how a user grants, constrains, or revokes it.

Production proof

CarrierIQ's Approve Bind gate separates "the system found a result" from "you authorized action on that result." Five autonomous carrier workflows run in parallel, each producing evidence the user can inspect before committing. The bind creates a real obligation — an insurance policy with future premiums — so the gate is consequential.

Muse's Sentinel architecture — a host-side component controlling connector actions and sending structured approval requests outside the agent conversation — validates that the authority-separation pattern CarrierIQ demonstrates is the direction the industry is moving. The OpenAI Identity team will know about Sentinel. Reference it as context, not as your work.

Differentiator

Most candidates applying here will show authentication flows, permission dialogs, access-control systems. You can show a working interaction model where the type of commitment determines the type of approval surface — graduated, not binary. That maps to the posting's core tension and to the specific API gaps that just shipped.

Skip

The Alibaba or BCG Digital Ventures enterprise scale narrative. This role is about interaction-pattern invention for a new category of identity problem. Organizational leadership experience is background context if asked, not your opening.

Confidence: High that the Agents API gaps are real design problems the Identity role will address. Moderate on whether the hiring manager frames the role primarily around agent authority vs. traditional account identity — the posting covers both. Lead with agent authority. It's the harder problem and where your evidence is strongest.

Stripe — Staff Product Designer, Link

Their problem

The Staff PD, Link posting says the team is "building infrastructure for a world where agents transact on users' behalf and identity determines how money moves." The designer will shape Link's consumer presence across checkout, AI partners, and Link's own app, with emphasis on early-stage explorations and zero-to-one visual systems.

Stripe's current design constraint, stated on their own product page: Link's agent wallet requires per-purchase human approval for every transaction. The consumer sees the merchant, item, amount, and payment method, then taps Approve or Decline. Granular controls — rules governing when an agent can spend without asking — are listed as "coming soon."

That transition is the design frontier. Moving from "approve everything" to "approve selectively" without losing the user's sense of control over their money. The spend-request lifecycle already has the states (pending_approval, approved, denied, expired, canceled) and the constraints (10-minute approval window, $500 per request, incremental re-authorization if the total increases). What it doesn't have is the consumer-facing design for graduated delegation — the interface that lets a user say "this agent can spend up to $30 at this merchant without asking me, but must ask for anything else."

One more signal: the closed Senior Staff PD, Agentic Commerce role from earlier this year tells you Stripe scoped this as a senior design problem. Whether it was filled, absorbed, or restructured isn't public. The two active Link roles now carry the same agentic-transaction language, which suggests the work lives here.

Lead with this

The Trust essay's delegation model applied to spending. Watch → Verify → Delegate maps to Stripe's stated roadmap: today's Link wallet is pure Watch (approve every purchase). The "coming soon" granular controls are the Verify-to-Delegate transition. Frame your outreach around that progression.

CarrierIQ — with honest domain framing. CarrierIQ is insurance quoting and policy binding, not payments. Say so upfront. The transferable evidence is the interaction architecture:

• Structured intake capturing user intent and constraints before autonomous work begins
• Five parallel agent workflows producing independent results
• Staged verification with evidence attachment
• Differentiated review states signaling what kind of human attention each result requires
• Operator rationale recorded at the approval gate
• The Approve Bind moment where a user commits to a consequential financial obligation

That last bullet is the one Stripe will hear. Binding an insurance policy creates a real monetary commitment — future premiums the user will owe. The approval gate governs a decision with financial consequences even though the app doesn't process a payment. The structural analogy to Link's spend-request approval is direct: user reviews agent-produced evidence, then authorizes a commitment that triggers real-world financial effects.

Production proof

CarrierIQ demonstrates the graduated-authority pattern Stripe hasn't shipped yet. Link's current binary (approve/deny per purchase) is where CarrierIQ would be if it returned every quote with a single "Accept" button. Instead, it returns results in differentiated states — ready to bind, needs normalization, requires referral, demands a phone call. That graduated response is the design pattern Stripe will need when they move from per-purchase approval to configurable delegation rules.

The Muse/Link integration is your bridge reference. Stripe announced that every Muse purchase asks the consumer to approve the transaction total in chat. The underlying payment details stay hidden from Muse. Stripe's Link team built this integration, so they know Muse's Sentinel architecture — the host-side component sending structured approval requests outside the agent conversation. The granular controls Link is designing next will need to generalize that pattern: scoped authority with explicit boundaries on what the agent can do before the system pauses for human commitment.

The Link team knows this is a starting point. The "coming soon" language on their own product page confirms they're already designing what comes next.

Differentiator

Candidates applying for a Staff PD role on Link will bring checkout optimization, conversion design, consumer fintech portfolios. You bring a working model for the problem Stripe is about to solve: how authority shifts across a sequence of agent actions, and how the approval surface adapts based on what's at stake. The delegation-envelope parameters from Issue #9 — task scope, permitted actions, cost boundaries, duration, pause conditions, revocation — map to the parameters Link's granular controls will need to expose. This is analytical scaffolding for your conversation, not something to cite by name. Internalize the logic and articulate it as your own design thinking about what configurable delegation requires.

Skip

Don't position CarrierIQ as fintech or payment design. The domain gap is obvious and claiming otherwise damages credibility. Lead with the authority-design problem and let the domain transfer be an inference the hiring manager draws.

Don't lead with TinyFish. Past-tense technical AI context if asked, not public portfolio proof.

Confidence: High that the Staff PD, Link role is the right entry point and that graduated delegation controls are the active design problem. Moderate on whether the hiring manager frames this as an authority-design challenge vs. a consumer-product-growth challenge — the posting supports both readings. If the conversation tilts toward growth and conversion, your evidence is weaker. If it tilts toward the "agents transact on users' behalf" language the posting leads with, you're positioned precisely.