Same agent, different plug: the interface changes what the agent does and what it costs

The same capabilities, different agent

In a preprint, researchers built a framework called MICA that renders Model Context Protocol and command-line interfaces from a shared semantic action contract and routes decoded actions through the same runtime, so that any difference in behavior can be attributed to the interface rather than the capabilities. The result was stark: matched interfaces produced substantial differences in task performance and interaction cost, and the differences extended to semantic action selection, failure pathways, and recovery. Paired natural trajectories revealed structured divergence in 94.3% of 2,004 episodes, and matched-state probes localized the sensitivity to capability presentation, realization, and feedback. Early interface differences propagated through subsequent interaction, meaning a small presentation choice early in a task compounds into a different outcome. m:…5931

The authors also introduced DART, a method that repairs interface-specific realization while preserving validated semantic commitments. It improved benchmark scores in all six evaluated settings, by up to 9.0 points, and reduced MCP token cost in all three environments, by up to 27.1k tokens per task. The practical implication is that interface design is not cosmetic for agents: it is a direct intervention boundary for performance and cost, and a team that benchmarks a model without fixing the interface has measured the interface as much as the model. m:…5931

Vendors answer with controlled runtimes

NVIDIA's NemoClaw, described in a company developer post, is built around the same insight from the deployment side: building an autonomous agent requires a model, a harness, and domain-specific tools, and the primary challenge for production agents is safely operating with access to real enterprise systems and data. The framework provides a runtime that enforces policies, plus optimization and observability tools for reliable execution. The company frames the runtime, not the model, as the thing that makes an agent deployable, because the runtime is where policy is enforced when the agent decides what to touch. m:…0778

A post from Daytona makes the same point for the browser, the tool agents use most messily. Daytona sandboxes provide a default environment where Chromium is pre-installed and driven by Playwright, with verified files restorable in a median of 1.27 seconds, and Anything API uses Daytona sandboxes to maintain persistent files between conversation turns. But agents working in a sandbox sooner or later need a browser that can survive the open web, and Notte browser sessions provide persistent cookies, a consistent desktop Chrome fingerprint matched to the exit IP, residential proxy routing, and captcha solving, plus live viewers and replays for debugging and a command to capture XHR and fetch traffic. The choice, the post argues, depends on where the browser is going and what it has to carry: local apps suit Daytona, external sites with bot protection suit Notte. m:…4879

The decision this creates

For a developer, the three items together describe a new layer of decisions that sit between model selection and deployment: which interface presents each capability, which runtime enforces policy on it, and which browser carries it to the outside world. Each choice changes behavior, cost, or both, and none of them shows up in a model benchmark. The open questions are practical: the MICA study is a preprint whose results need replication across more agents and tasks. But the direction is consistent: the agent stack is moving from choosing a model to governing the surfaces around it. m:…4879 m:…5931