Daily Edition Sources +3

An Agent's Sign-In Link Is Not a Timeout

OpenWork's newest MCP work carries a provider's structured authorization link through a failed tool call, so the person who owns the account can act instead of watching an agent retry the wrong problem.

A rough marker diagram shows an MCP tool error passing a connection link to a human sign-in card before an agent retries, with a caveat that the path is tested rather than universal.
Diagram Punka sign-in link is a human handoff, not a timeout.
repo different-ai/openwork evidence
3 source signals 1 repo 3 linked commits
Evidence: 3 linked commits / July 21, 2026 / Daily Edition
Open Edition Evidence below

An agent asks a connected tool for something it cannot authorize itself. The honest next move is not another request; it is a handoff to the person who can sign in. In a July 20 different-ai/openwork commit, an end-to-end test gives a mock MCP tool a structured connection URL and checks that the agent can return a linked instruction: connect the account, then retry.

That sounds small until the different-ai/openwork tool is sitting between an agent and a service somebody else controls. A generic failure turns the moment into a bad loop: the agent keeps trying, the account holder has no clear action, and the provider sees another request instead of an authorization. A link does not grant the agent more power. It makes the missing human decision visible.

The important bit is what is allowed to travel

OpenWork's follow-up diagnostics change says a downstream provider authorization link should be relayed rather than masked as a timeout. The distinction matters: a timeout invites a retry; an authorization requirement names an action owner. The later provider-error patch tests that structured JSON-RPC authorization data can become a member-facing action, while a free-text URL, an unsafe scheme, or an oversized body does not automatically become a trusted instruction.

That restraint is the story's real mechanism. The product is not merely displaying more error text. It is deciding which machine-provided detail can cross into a human action, which detail stays untrusted evidence, and when the only honest message is that the provider needs attention.

A useful failure should stop the wrong retry

The public tests use a mock server and model, so they do not prove live compatibility with every MCP provider or the safety of any link outside this validation path. They do show a design worth copying: preserve a bounded, structured authorization handoff, label the human who can act, and do not turn arbitrary provider prose into a button. The next signal is whether this survives real provider variations without making a sign-in URL another route for unsafe content.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateJuly 21, 2026
LaneDaily Edition
Confidence78%
Sources3
Reposdifferent-ai/openwork

Primary Evidence

Evidence Limits

  • These commits and tests prove an intended implementation path in OpenWork. They do not prove successful authorization against an arbitrary provider, production adoption, or that a provider-supplied link is safe outside the code's structured validation rules.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.