Omni-IO Skills: Harnessing Your Agent Omni-Native

Omni-IO Skills. Harnessing Your Agent Omni-Native. By Yanlin Li and five others, from the National University of Singapore and the University of Oxford. Published on the twenty-fifth of September. Its code repository is public and real: nineteen source files.

General-purpose agents can plan, reason, and act over long horizons. What they can actually produce, though, is split across text, images, audio, video, documents, three D assets, and code. There are two obvious ways to close that gap, and each has a cost. Extending a foundation model to more modalities ties every gain in capability to an expensive model update. Assembling specialist models and tools avoids that, but leaves open how procedures, dependencies, intermediate assets, and revisions across turns should be coordinated.

Omni-IO Skills takes the second route and supplies the missing coordination. It is a plug-and-play Agent Harness that makes an existing agent omni-native. Four parts carry it: hierarchical Skills, a standardized multimodal execution interface, orchestration that is aware of dependencies, and a persistent Asset Registry.

Work involving several assets is written down as Declare Execution Graphs. Operations that do not depend on one another are scheduled to run concurrently, and successful outputs are registered, so that they can be reused downstream and in later turns. The execution backends underneath are replaceable. In all, twenty-seven Skills cover thirty-eight representative tasks, spread across seven artifact modalities and four capability families: understanding, generation, reasoning, and retrieval.

The test bed is UniM ninety, with two host agents, GPT five point six Sol and Claude Sonnet five. Their input-support rates start at forty percent and at thirty-eight point eight nine percent. With the harness, both rise to one hundred percent.

Relative Semantic Quality Coupled Score climbs from twenty-six point nine nine to seventy-four point nine four for the first agent, and from twenty-seven point eight two to seventy-seven point seven eight for the second. Strict Structure Score reaches a full one hundred for one of them, and ninety-nine point seven eight for the other.

The claim being made is architectural. Breadth comes from the harness, while the host agent's reasoning core is left exactly as it was. The authors present that kind of capability composition, done at the level of the harness, as a practical route to broad Omni systems that can keep evolving without retraining the model at their centre.

Omni-IO Skills. Harnessing Your Agent Omni-Native. By Yanlin Li and five others, from the National University of Singapore and the University of Oxford. Published on the twenty-fifth of September. This is the long version: the whole paper rather than the abstract.

General-purpose agents such as Codex and Claude Code can plan, execute code and refine their work over long sessions. Their production surface, though, stays centred on software and knowledge work. Ask one to turn lecture recordings and reference documents into slides, narration and an explainer video, and it needs capabilities it does not have. Widening the foundation model ties every new modality to new data, codecs and decoders. Attaching specialist models as tools leaves open how procedures, dependencies, intermediate assets and revisions get coordinated. The authors ask: can a plug-and-play harness make an existing agent omni-native while leaving its reasoning and planning core untouched?

Two ideas from earlier work carry the design. An agent harness is the operational layer around a model: the action loop, tool access, state, verification and recovery. A Skill is packaged procedural knowledge: when a task applies, which inputs it needs, how tools should be invoked, and what it should produce. Neither alone gives an omni workflow. A production task must also pick the right capabilities, say which step consumes which output, move intermediate artifacts between tools, isolate local failures, and recover earlier outputs in a later turn. Omni-IO Skills is that layer, sitting between the host agent and backends from providers such as OpenAI, Google Gemini and ElevenLabs. It has four layers: Skill Entry, an MCP Tool Service, a Provider and Configuration layer, and an Asset Registry.

A request first selects a Skill, and higher-level Skills are expanded recursively until every step is executable. Invocation runs strictly downward. A Scenario Skill may call Expert or Atomic Skills, an Expert Skill may call Atomic ones, and an Atomic Skill calls nothing. The stated reason is that forbidding upward and sideways calls keeps the expansion finite and the resulting graph acyclic. The terminal tasks become nodes in what the authors call a Declare Execution Graph. Each node carries an identifier, a task type, a self-contained prompt, optional parameters and its dependencies. Before anything runs, the graph is checked for unique identifiers, resolvable references and no cycles, and a graph that fails is rebuilt, never submitted.

Execution proceeds in Waves. Every pending node whose predecessors have all completed joins the next Wave, and the nodes in one Wave are dispatched concurrently. Image and audio generation can run side by side, while an image-conditioned video waits for its image. Paths never appear in prompts: the scheduler injects predecessor outputs at call time, as the first frame of a video or the reference image for a 3D model. When a node fails, only its pending descendants are cancelled, and independent branches finish. Each success is appended to a registry under a stable identifier, with a description, its effective parameters, its turn, and a pointer to any source asset. In a later turn, the agent finds a past asset by semantic match over those descriptions and places it in the new graph as a node that is already complete, so reusing yesterday's image issues no generation call. Expert Skills add one more loop. The assembled artifact is read back with the understanding capability of its own modality, a defect is traced to the smallest responsible part, and only that part is redone, for at most two autonomous rounds by default.

The test bed is UniM ninety: ninety instances, one easy, one medium and one hard case from each of the thirty domains of UniM, a benchmark from several of the same authors. Two hosts, GPT five point six Sol and Claude Sonnet five, run with and without the harness, with prompts, execution budgets and provider bindings held fixed. The headline is input support, the share of instances whose inputs an agent can fully receive. It goes from forty percent and thirty-eight point eight nine percent to one hundred percent for both. The relative semantic quality score climbs from about twenty-seven to seventy-four point nine four for one host and seventy-seven point seven eight for the other.

That makes the absolute score the comparison closest to the thesis about quality. It rises from sixty-seven point four nine to seventy-four point nine four for GPT five point six Sol, and from seventy-one point five three to seventy-seven point seven eight for Claude Sonnet five: gains of roughly seven and six points. Structure is where the harness shows most plainly. On the strict structure score the bare agents sit near half, and with the harness they are essentially perfect. Interleaved coherence is mixed. For GPT five point six Sol it rises to ninety-three point nine eight. For Claude Sonnet five it barely moves, from eighty-two point two nine to eighty-three point two eight.

There is no limitations section, so the limits here come from what the paper reports. It gives one score per configuration, with no mention of repeated runs and no error bars. The benchmark is a ninety-instance subset of the authors' own earlier benchmark. The harness is tested only as a whole: there is no ablation, so the evidence cannot separate what the Skill hierarchy, the Wave scheduler or the registry each contribute. Cross-turn reuse, failure isolation and localized rework, the features that most distinguish this design, are shown through worked examples and two case studies, and none of them is measured. The authors themselves decline to rank the two hosts, reading only the gains within each agent.

The idea to carry away is that omni capability can live in the layer around a model rather than inside it. The host keeps its planning. The harness supplies the procedures, a graph that says what waits for what, providers swappable by editing one configuration field, and a registry that makes every output addressable by identifier rather than by path. The evidence shown is strongest on coverage and structure, and thinner on quality.