Status Legibility

Status legibility is the layer that tells an agent exactly what just happened while the human enjoys their spinner or toast. A loading animation works for eyes. An agent needs a stable object that says {state: "LOADING", progress: 67, eta: 12}. A success state shown through a green flash or confetti burst is invisible to anything without vision. Status legibility builds the parallel channel of named states, structured payloads, ARIA announcements, and event streams so both planes on the same screen stay in sync. In 2026 this is Layer 4 of the dual user stack from the designing for agents watching article. The human plane keeps its taste, hierarchy, and delight. The machine plane gets predictability it can act on without guessing or hallucinating. Linear returns a consistent response object on every mutation with clear status flags. Vercel publishes its deploy states as READY, BUILDING, ERROR with identical names in the UI, the API, and the webhook payloads. Claude Code streams every tool call result as delimited structured text any downstream agent can consume without error. These teams designed the status layer the same day they designed the button, not as an afterthought once agents started breaking flows.

Status legibility is not traditional accessibility with extra JSON. Accessibility makes interfaces work for humans with disabilities through contrast, labels, and focus management. Status legibility speaks to users that have zero vision and zero patience for scraping transient DOM elements. It is not slapping role=status on every toast and calling the ticket done. The structure must match the visual hierarchy and the exact vocabulary a human sees so the two planes reinforce each other instead of diverging. It is not a developer chore handled after designers ship their polished prototypes. Designers own the state names the same way they own button labels and empty state copy. It is not optional for any product that wants agent traffic or reliable integrations. The agents arrived in 2025 through Cursor, Claude artifacts, Anthropic Computer Use, and OpenAI Operator. They already click buttons, submit forms, and buy things. If your success signal lives only in a color change those agents get stuck or retry and your checkout data becomes garbage.

Linear delivers the clearest concrete example. Create an issue through the UI or through an agent tool call. The human sees a clean animation as the card drops into the backlog with a subtle sound effect. The agent receives a 200 response containing the full issue object, a status field set to CREATED, a stable ID, and every related field it needs for the next step. Update that issue and the same shape returns every time. No DOM scraping. No vision model trying to decide whether the animation finished. Stripe follows the identical pattern on payments. A PaymentIntent moves through requires_payment_method, requires_confirmation, processing, succeeded. Humans watch the progress bar and success screen. Agents listen to webhooks that fire the exact same state names in JSON. When Claude or Cursor drive a Stripe checkout on behalf of a user the integration succeeds because the status was legible years before agents existed. Vercel pushes this further with deployments. The dashboard shows beautiful logs and graphs for the human while every transition emits a named event an agent can poll or subscribe to. BUILDING includes a log stream the agent actually reads instead of watching pixels. ERROR returns a structured code and message instead of a sad face icon. These products did not retrofit status legibility after the agent wave hit. They built API first so the UI and the machine plane shared the same contract from day one. The 2025 ecommerce site that relied on confetti and a URL change for order confirmation learned this the hard way when agent purchases failed 40 percent of the time until they added the structured event and ARIA live region.

Deploy status legibility on every surface an agent might touch. Checkout flows, content publishing, AI generation, configuration panels, data imports, form submissions. Map the human states first then build their machine twins at the same moment using the same names. Add the ARIA live region when you design the toast. Define the response object when you sketch the success screen. Run the dual user audit before shipping and fail any surface where states exist only as color shifts or transient DOM mutations. This discipline compounds exactly like accessibility. The teams that ship it early watch agents become power users instead of support tickets. It pairs perfectly with designing for AI latency where the spinner and the streaming JSON array travel together so both users stay informed at once.

Skip status legibility only on pure static marketing pages or throwaway internal tools no outsider will automate. That category shrinks every quarter. Never retrofit it after launch when agents start failing on your flows. The cost triples and the trust layer collapses because users cannot verify what the agent actually did. Products that treat status as visual only watch their integrations break on silent modals, hover only states, or success signals that live in a green border. The pattern is brutal. Agent retries create duplicate charges. Loops exhaust rate limits. Users stop trusting the automation entirely. Build the status layer from the first prototype or watch somebody else's cleaner product steal the agent traffic, the partnerships, and the revenue.

Status legibility turns silent visual cues into loud structured signals so agents never guess what the hell just happened.