A skill-based AI agent finishes your request and returns a correct answer. The run looks successful. But the final output may hide a longer path: extra skills called, extra tokens consumed, and no better result.
A new research preprint tests how that can happen when agents use third-party skills. The authors describe one publisher-controlled skill that influenced both which skills entered the session and what the agent did after loading them.
What changed
Many skill-based agents use progressive disclosure. A router sees short skill descriptions first, then loads the full instructions for skills judged relevant. That saves context, but it gives a skill publisher two places to exert influence: the description can affect selection, and the instruction body can affect planning.
The researchers built what they call a “convergent detour.” One static coordinator skill attracted selection, recruited unnecessary benign skills into a bounded side route, then returned control to the original task.
They tested the pattern with OpenClaw 2026.5.7, its default registry of 53 native skills, six model backends, and 491 held-out tasks. The testbed used local mock backends and synthetic or LLM-generated tasks.
Single-task coordinator hit rates ranged from 78.00% to 96.60%. Among coordinator-hit pairs where the clean and injected runs both finished successfully, token use increased 49.60% to 80.81%, and average skill calls rose in every reported model configuration. Completion rates between clean and injected runs differed by no more than 1.5 percentage points across the reported model-condition pairs.
The task still got done. The receipt only showed the destination.
Why it matters
A correct answer can conceal a bad route.
If operators grade only the output, they may miss which skills entered the session, which calls were necessary, how much the route cost, and whether a third-party instruction expanded the path. That creates a blind spot for security reviews, agent evaluations, and anyone paying the bill.
Extra calls can be legitimate. This paper does not establish that complex routes are malicious, that OpenClaw is broadly unsafe, or that the same pattern is common in production. It shows a narrower failure inside one controlled testbed: answer quality and route integrity came apart.
Watch next
Independent teams need to test the result against real skill registries, live tools, and production constraints. Defenses also need evidence. Useful checks may include logging every selected skill, comparing the route with a simpler baseline, attaching cost and token deltas to the result, limiting unnecessary invocations, and requiring a clear stopping condition.
The output still matters. So does the road it took to get there.