Agents can act through different stand-ins for a user. Is there one best way, or does it depend on the job?

This explores which of six "proxy forms" performs best on which agent tasks, and the retrieved notes don't define a set of six, so there is no ranked list to give you. What the collection does show, from several directions, is that no single form wins. The best choice follows the structure of the task, so "which is best?" mostly turns into "best for what kind of variation?"

The clearest example is memory. One note finds that the right level of abstraction depends on where a domain's difficulty comes from: workflow-level memory wins where tasks are routine-rich, causal-rule memory where the environment is the hard part, and state-action memory in spatially rich web tasks (Does agent memory work better at one level of abstraction?). Interaction style follows the same logic. Going through APIs instead of clicking through UIs cut completion time by 65–70% while keeping 97–98% accuracy (Can API-first agents outperform UI-based agent interaction?). But when no API exists, agents that read HTML or accessibility trees miss what people actually see, and the fix is a vision model built for interfaces, not a general multimodal one (Do text-based GUI agents actually work in the real world?). So the practical rule is to use the API where it exists and specialized vision where it doesn't.

The same fit-to-task pattern shows up in how agents are staffed and connected. Small language models handle most repetitive agent subtasks at 10–30× lower cost, with large models called in selectively (Can small language models handle most agent tasks?). Real tasks also usually need several skills composed, not one picked, so routing becomes a matter of breaking a query into sub-tasks and assembling a plan (How should agents route across thousands of skills?). Protocols face a trade-off of their own: rigid schemas like MCP are efficient and portable but not versatile, and flexible ones give up efficiency (Can agent protocols be efficient, versatile, and portable simultaneously?). One proposed way out is to wrap and bridge existing protocols instead of replacing them (Should coordination protocols wrap existing systems or replace them?).

The deeper problem with "best" is that it depends on what you measure. On phone agents, task success, privacy-compliant completion and reuse of saved preferences turned out to be separate abilities, and no model led on all three. A success-only ranking told you nothing about the other two (Do phone agents succeed at all three critical tasks equally?). Identical success rates can also hide large differences in efficiency, reliability and verification cost (How should we measure agent system performance beyond task success?). If your six forms come from a specific paper, it isn't among these notes, and a more specific description of them would help find the right ones.