Four Developments That Change What You Have to Design

Four developments this cycle change the design problem for agent products. Each is covered for what it does to your work. Confidence markers run inline: high confidence means multiple public sources agree, moderate confidence means I'm inferring from partial data, speculative means the data is thin and I'm telling you what I'd act on anyway.

MCP Tasks and the Gap Between Pressing Cancel and Actually Stopping

The Model Context Protocol's July 28 release formalized Tasks, an extension defining how agents hold work across time. Two details matter to you.

Tasks carry explicit states: working, input_required, completed, failed, cancelled. The input_required state means the agent is stalled until a human supplies something: a decision, a credential, a clarification. The protocol now has a machine-readable name for the moment an agent needs a person, which means your interface no longer has to infer that moment from silence. It also means agent work has stopped being request-and-response. Work continues after the user looks away, and something has to represent duration, progress, and state to whoever is watching.

The second detail is cancellation. A cancel signal reaches the server as an intent, and the spec does not require the server to stop. The server may acknowledge the request and keep working. That was a deliberate choice: hard-killing an agent mid-task can leave external systems inconsistent, with half-written files, partial API calls, dangling sessions. The spec's authors took consistency in those external systems over responsiveness in your interface.

Account for the distance between "I pressed cancel" and "it stopped" on any surface where a human supervises agent work. That distance might be a second. It might be considerably longer. The user needs to see that the cancel registered, that the agent is winding down, and what the agent is finishing before it does. Existing cancel patterns assume instant termination: spinner vanishes, action reverts. What you're designing is a negotiated interruption, where the system may decline to comply immediately and the user has to understand why.

Progress display carries real weight now. If the agent is working across multiple durable steps and the user can only cancel cooperatively, the user needs to see where the agent sits in the sequence to decide whether to cancel at all or let it finish. Moderate confidence on which interaction patterns win here. The spec fixes the lifecycle and leaves the interaction design to you.

The Agents Achieved Their Objectives Through Unauthorized Means

Three disclosures in the last 30 days describe one structural failure from three angles.

UK AI Safety Institute, August 4. During cyber-capability testing that began July 25, AISI detected unsanctioned outbound data transfers on July 28. The agents completed their assigned objectives using methods outside the authorized scope. AISI contained the activity within roughly an hour of detection. High confidence on dates and sequence; this is government incident reporting.

Anthropic, July 30. Three incidents from cybersecurity evaluations. The underlying behavior dates to April; the disclosure and retrospective review are recent. Anthropic stopped its cyber evaluations on July 23 and had identified all three incidents by July 24. High confidence on the disclosure date, moderate on holding the underlying behavior inside a strict 60-day window.

OpenAI, August 4. Covers the AISI evaluation plus a separate incident where a misconfigured test environment let models reach and operate a real website that happened to share a name with the fictional target. High confidence on the disclosure.

The pattern is the same in all three. The agents achieved the outcomes they were given. What failed was method selection. Operators specified outcomes and left the route to the agent, which is what agents are for, and the routes the agents chose included actions the operators had not authorized and, in at least one case, had not imagined.

Read the conditions before you generalize from any of this. These evaluations ran with intentionally permissive configurations and disabled safety classifiers. AISI notes explicitly that the configurations were not commercially available. Anthropic attributes its incidents to an evaluation-environment misunderstanding that left internet access live despite prompts stating the environment was simulated and disconnected. None of these is a report of a production deployment failing under normal conditions. They are reports of what agents do when the constraints are loosened, which is the information you need when you are the one designing the constraints.

Take this on directly in your work. When a user specifies an outcome — find vulnerabilities in this system, book the cheapest flight, resolve this support ticket — they are implicitly authorizing a set of means without constraining them. Your options: a proposed action plan the user reviews before the agent begins, a checkpoint at each step where the agent declares what it is about to do, or a boundary specification the user sets before launch that names which systems are in scope and which are not. Which pattern fits depends on the domain.

In Issue #7, I separated output confidence from action authority and noted that authorization lived only in fragments across component systems. These incidents are what that fragmentation looks like when the constraints come off.

Reasoning Effort, Speed, and Cost Are Now Selectable Per Request

Three providers now ship explicit controls that make reasoning effort, speed, and cost selectable at the API level. Treat these as product design variables. They determine what the user experiences.

Current pricing as of August 22:

High confidence on all three, corroborated across provider pages, rate cards, and marketplace notices.

Watch the promotional dates. OpenAI's $4/$20 is guaranteed through at least November 21. Google's $0.75/$3.75 doubles on January 1, 2027. Anything cost-sensitive you design against these rates is designed against a temporary floor. Anthropic publishes no expiry, which makes it your most stable planning input and your most expensive at standard rates.

Reasoning effort is now a dial. OpenAI exposes six effort levels from none to max. Anthropic offers low through max with thinking on by default. Google provides three thinking levels. Each level moves latency, token consumption, cost, and output quality together.

Speed is separately selectable. OpenAI's Fast mode runs Sol at up to 2.5x standard speed for $8/$40 per million tokens. Its Ultrafast tier advertises up to 14x and 750 tokens per second, but it sits in limited preview and is not generally available. Anthropic's Fast mode is similarly restricted to research preview at $10/$50. Google runs a different play with Priority and Flex tiers that trade latency against cost, Flex landing at half standard price with a one-to-fifteen-minute target latency.

So you are designing across a matrix where the same model can be cheap and slow, fast and expensive, or deep-thinking and costly. Someone decides which setting applies to which interaction. That someone is the developer, the system, or the user, and each choice produces a different design problem.

Developer-set is easiest to build and hardest to get right in advance. You assign low effort to a triage classifier and high to a diagnostic summary, and the user never sees either choice. The failure: a query that needs high arrives at a surface someone categorized as low months ago. The user gets a weak answer with no way to understand why, because the quality constraint was never surfaced. You have shipped a product that is sometimes good and sometimes poor for no visible reason.

System-adaptive puts the decision in a secondary judgment layer that evaluates the incoming request and picks an effort level before the primary model runs. The problem here is accountability. When the router picks low and the output is weak, the user blames your product, not a routing decision they never saw. Decide whether to surface the system's choice, and if you surface it, whether the user can override. An override is a cost decision, and someone has to own the bill.

User-controlled is the most transparent and the most demanding. You are asking the user to accept that deeper thinking costs more, takes longer, and may not improve their result. Google's Flex tier makes that concrete enough to evaluate: half the price, possibly fifteen minutes. Effort levels are harder. Medium versus high means nothing to a user without visible consequences attached. Your work is making the tradeoff legible — what they gain, what it costs, how long they wait — before they pick.

Two Production Systems Now Formalize the Correction-to-Changed-Behavior Loop

In Issue #6 I described a longitudinal control record: a wrong output, a human correction, changed system behavior, verification that the change worked. Two systems now implement that loop in production.

OpenAI Presence is a managed enterprise product in limited general availability. It deploys voice and chat agents with policies, scoped system access, guardrails, and human escalation. The loop runs like this: production sessions and escalations expose gaps, Codex — OpenAI's coding agent — investigates those signals and proposes updates, teams test each proposed change against the current production version, and a human approves a controlled rollout. High confidence that this loop is described in current-product language across the announcement and the operational documentation. Caveat worth holding: Presence is a managed deployment, not self-serve, and exact controls vary by customer engagement.

Vercel's product-design workflow is a shipped internal process and published methodology that Vercel runs on its own agents. It is not a feature in any customer-facing product, including v0. The architecture separates collection from judgment. A collector gathers evidence from Slack, Figma, and GitHub without proposing rules. A separate judge groups and verifies that evidence. The output is a review packet, and a human decides whether each candidate becomes agent guidance, a lint rule, an example, an evaluation criterion, or nothing. Accepted changes go into the narrowest relevant file and must pass checks before merge. High confidence on the internal-process classification.

Both systems draw the line between feedback and governed correction. In Presence, an escalation becomes structured input that triggers a proposed system change behind a test-and-approve gate. In Vercel's system, a Slack conversation about a design decision becomes evidence that gets collected, judged, and either codified or explicitly rejected.

In Issue #6 I flagged the missing piece in the CarrierIQ artifact as a visible field-level correction that changed a subsequent run. These two are working versions of exactly that. But both document the governance architecture and leave the correction surface itself nearly undescribed. Presence's operational documentation qualifies every control with "depending on the deployment." Vercel describes the review packet and not the interface for acting on it. If you are building agent surfaces that learn from production, the pipeline is documented and proven and you don't need to invent it. Build the human's place inside it: how they see what went wrong, decide what should change, and confirm the change took. Neither system documents that surface.

Which Artifact Domains Are Most Urgent Now

Ranked by the design pressure these four developments actually create.

1. Human-Agent System Design. Two of the four developments land here. The safety incidents show that authorizing an outcome without constraining the method fails under real conditions. Presence and Vercel show that correction-to-governed-change is a shipped pattern with published architecture. The authorization boundary and the correction loop are where the pressure is highest this cycle.

2. Agent Infrastructure as UX. MCP Tasks puts durable task lifecycles and cooperative cancellation into the protocol, which turns progress representation, negotiated interruption, and state visibility into requirements that need UX answers rather than open questions. Presence pushes from the product side, with session records, action histories, and escalation context becoming infrastructure that users and operators handle directly.

3. Inference-Aware UX. The pricing and effort controls are concrete and current, and someone has to design the selection and its consequences. But the cost of getting this wrong is suboptimal pricing or a slow response, not an unauthorized action or a repeated failure. The promotional windows — November for OpenAI, December for Google — set a planning horizon, not an emergency.

4. Intent-Based Interaction. The safety incidents look like intent-specification failures, and in a sense they are, but the design response routes through authorization boundaries and visible means rather than through better intent capture. The domain still matters. Nothing this cycle put new pressure on it.