What AI Agents Really Need from Apps to Get Useful Work Done

Over the past year, AI agents have moved from demo videos into real workflows. Developers quickly discovered an awkward truth: letting an agent click around in a browser is far less reliable than having the app proactively expose a clean set of capabilities. But what exactly to expose, at what granularity, and how to constrain permissions—there's still no industry consensus.

A recent public call for input from an RSS source laid the problem bare: What does an agent actually need from your app to accomplish something genuinely useful on your behalf? The organizers didn't offer answers—they invited developers to describe specific workflows and point out the sticking points. This "ask first, build later" stance itself signals that there's no standard answer yet.

From Assumption to Question: Agent Integration Isn't Just Wrapping API Docs

Many teams start with a simple idea: wrap the existing REST API and let the agent call it. In practice, you discover that an API designed for human developers and a capability interface designed for agents are two different things.

Human developers can read documentation, understand context, handle exceptions, and retry with a different approach after failure. Agents can't. What they get is a list of endpoints with no semantics and a vague natural-language goal. If the "translation" layer in between isn't done well, the agent gets stuck in repeated calls, randomly filled parameters, or outright hallucinating an interface that doesn't exist.

The organizers mentioned that "the answers kept surprising us." That's worth pondering. Surprise usually comes from two kinds of gaps: first, developers thought they were ready, but the feedback showed they weren't; second, some overlooked small design decisions turn out to be exactly what determines whether an agent can complete the task.

What Agents Ask of You May Differ from What You Expect

Synthesizing the feedback from various sources, an agent's demands on an app roughly fall into several layers.

Intent Discoverable, Not Endpoints Callable

An agent needs to know "what can this app help me do," not "what functions does this app expose." In a shopping app, humans see buttons and navigation; an agent needs semantic action descriptions like "check order status," "initiate a return," or "compare prices of similar products."

This means the capability list must be written in plain language, with clear preconditions, input meanings, and possible output forms for each action. Treating these as documentation afterthoughts often becomes the first point of failure for an agent.

State Readable, and Structurally Readable

When an agent executes a multi-step task, it must know the current state. Text, icons, and loading animations on a page are signals for humans but noise for agents. Structurally exposing states like "order shipped," "insufficient balance," or "requires user confirmation" allows the agent to decide whether to continue, pause, or give up.

Failures Must Be Understandable, Not Just an Error Code

A human sees a 500 and goes to check the logs; an agent sees a 500 and can only guess. Including the failure reason, optional remediation paths, and whether a retry is worthwhile significantly reduces an agent's wasted loops. This is especially critical during cross-app orchestration—after App A fails, the agent needs to decide whether to switch to App B or go back and ask the user.

The difference between semantic errors and machine-readable errors in agent scenarios deserves separate clarification. In traditional API design, error codes (like 404, 500) and short messages are for human developers, who can infer causes by combining logs, documentation, and context. But for an agent, which lacks this external knowledge, a bare error code may be interpreted as "this path is blocked" or "retry needed," triggering meaningless loops. Semantic errors require returning structured, machine-readable fields such as error_type (permanent failure / temporary failure / authorization needed / user confirmation needed), a retryable boolean, suggested_action (switch tool, degrade, ask user), and user_message. RFC 7807 (Problem Details for HTTP APIs) in web standards offers a reference format, expressing problems with four fields: type, title, detail, and instance. A more mature approach is to define a domain-specific error classification enum, letting the agent orchestrate subsequent steps without guessing—especially in cross-app tasks, where unified error semantics is the key to whether an agent can gracefully degrade.

Permission Boundaries Must Be Explicit, Not Left to the Agent's Discretion

When an agent acts with the user's authorization, what it can and cannot do is best hard-limited at the interface layer. Relying solely on prompts to constrain "don't touch the wallet" isn't reliable in real scenarios. Designing high-risk actions to require explicit confirmation protects both the user and the app itself.

The core concept here is an extension of capability authorization and the principle of least privilege into agent scenarios. Traditional OAuth grants third-party apps coarse-grained scopes (like "read email"), but when an agent performs actions on behalf of a user, it needs finer "action-level" permissions—for example, "can initiate a return for this specific order" rather than "can modify all orders." The industry commonly implements this in two ways: first, intent-bound tokens, where the token encodes the specific action, target resource, validity period, and amount limit, and rejects anything out of bounds; second, human-in-the-loop confirmation, requiring explicit user taps to confirm high-risk actions like payments, deletions, or sending, rather than relying on prompt-based "please don't..." constraints. Verifiable Credentials and Decentralized Identity (DID) are also being discussed for agent identity and authorization, enabling apps to verify "who authorized this agent, and what was authorized." Together, these mechanisms turn permissions from a "gentleman's agreement" into a hard boundary at the interface layer.

Where Workflows Get Stuck: Three Repeatedly Mentioned Breakpoints

The organizers asked developers for "workflows" and "breakpoints," indicating that what matters to them isn't abstract principles but concrete points of failure.

The first type of breakpoint is login and identity. When an agent operates on behalf of a user, whose account, what identity, and how the session persists—many apps haven't prepared for this scenario. The shared login state for humans and agents, and the dedicated authorization channel for agents, need to be designed separately.

The second type of breakpoint is cross-app handoff. A useful task often spans multiple apps—for example, extracting information from email and filling it into a spreadsheet. No matter how clean a single app's capabilities are, without a unified convention at the handoff point, the agent still has to scrape by with screenshots and coordinates.

The third type of breakpoint is the "last mile" confirmation. The agent has done 99% of the work—should it click that final button on the user's behalf? Different apps give different answers, and users' expectations vary too. Designing the confirmation timing to be configurable may be more practical than a one-size-fits-all approach.

What This Means for Developers

If agents truly become an important entry point for apps, then "agent-facing interface design" will become a first-class citizen alongside "human-facing UI design." The current call for input is itself a signal: the standard isn't set yet, and whoever articulates their workflows and breakpoints clearly first has a better chance of influencing the conventions that follow.

For app teams, what you can do right now isn't wait for standards but start with the single task you're most frequently asked to perform, and organize its capability descriptions, state feedback, and failure information into a form an agent can read. Getting one thing working is more valuable than exposing a hundred endpoints.

As a supplementary note, the above synthesis of capabilities and breakpoints comes from the discussion directions of the public call for input and common agent integration experience, not final conclusions from the organizers; the call is still ongoing, and developers are welcome to submit their specific workflows.

Background Supplement

A dedicated identity channel for agents can be understood as a "delegated access" model. Human login typically relies on account credentials or an existing session, while an agent, as the user's proxy, needs credentials that are revocable, auditable, and scope-limited. Common implementation directions include: issuing a short-lived delegated token for each agent session, clearly labeling the delegator, the delegated agent, authorized actions, and the time window; maintaining a "user - agent - session" triplet on the server side so the app can distinguish "this is the user operating personally" from "this is the agent operating on the user's behalf." This differs from traditional machine-to-machine (M2M) client credentials because the agent's authorization always originates from a human—only the executor has become software. If an app doesn't design a separate channel for this scenario, it can only reuse the human's login state, making agent behavior indistinguishable from user behavior, and rendering auditing and revocation ineffective.

One-line Summary

For AI agents to truly get things done for users, apps must provide semantic capabilities, structured state, understandable failures, and explicit permission boundaries.

Paragraph Summary

The article revolves around a public call for input: what does an AI agent actually need from an app to accomplish something genuinely useful? The author points out that simply wrapping existing REST APIs for agents often fails, because human developers can compensate with documentation, context, and retries—agents can't. An agent's demands can be grouped into four points: intent discoverable rather than endpoints callable; state structurally readable; failures returning understandable reasons and remediation paths; permission boundaries explicitly limited at the interface layer. Workflow breakpoints cluster around login and agent identity, cross-app task handoff, and last-mile confirmation. The article advises developers not to wait for standards but to start with the single most-requested task, organizing it into agent-readable capabilities, state, and error forms—getting one thing working is more valuable than exposing a hundred endpoints.