General-purpose agents are good at planning, reasoning, and grinding through long tasks, but when it comes to actually producing deliverables, their output is still lopsided toward text and code. Omni-IO Skills, from researchers at the National University of Singapore and the University of Oxford, proposes a way to close that gap without retraining the model. The host agent's reasoning core is left untouched; on top of it sits a single detachable harness (an operational layer that helps the agent pick tools, run them, and manage their results) that lets the agent move across seven modalities — text, image, video, audio, document, 3D, and code.
Right now there are broadly two paths to growing an agent's omni (handling many senses and media at once) capabilities. One is to keep cramming modalities into the foundation model itself. Processing images, sound, and video inside a single model drags along new data, new codecs, new decoders, and alignment stages — and the more capable it gets, the more you're pinned down by the cost of updating the model. The other path is to attach specialist models and tools on the fly. That's flexible, but the part that actually matters is missing. How do you fix the procedure, express the dependencies between tasks, carry intermediate artifacts between tools, and revive something you produced in an earlier turn so a later turn can use it? All of that is left hanging.
Here's an analogy. A workshop has gathered superb artisans (the specialist models and tools), but there's no work order, no conveyor to pass half-finished pieces along, and no shelf to store what's been made. However skilled each person is, the pieces never add up to a single finished product. The missing piece the paper points to is exactly this omni-agent harness — the work order, the conveyor, and the shelf.
Omni-IO Skills ships capabilities as loadable units called "Skills," split into three tiers. There are 19 Atomic skills (reusable units of capability), 2 Expert skills (production procedures that create a concrete deliverable), and 6 Scenario skills (applied tasks that produce several related outputs together). Together, 27 skills cover 38 representative tasks, spanning four capability groups — understanding, generation, reasoning, and retrieval — and seven modalities. Say you're building a single online lecture: analyzing the transcript is an Atomic skill's job, producing the slides as a deliverable is an Expert skill's, and tying slides, illustrations, narration, and an explainer video into one bundle is a Scenario skill's.
Below that, things fork into four layers: a skill-entry layer (task knowledge), an MCP tool-service layer (tool access), a provider-and-config layer (which service you actually bind to), and an asset-registry layer (persistent storage for what gets produced). This split separates task knowledge from execution backend. That's exactly why the paper is emphatic that it treats foundation models, specialist models, and media engines all as "swappable execution backends." The point is to never lock a workflow to one particular model stack.
The cleverest part of the approach is how it expresses multi-asset workflows as a graph. The paper calls this a Declare Execution Graph (DEG). Tasks that don't depend on each other run at the same time (wave scheduling), successful outputs are registered in the registry so later tasks — and later turns — can reuse them, and if some task fails partway, only that spot is isolated. The gist is twofold: run in parallel whatever can run in parallel to cut time, and reuse anything you've made once without being tied to a file path or a service.
Evaluation was done on UniM-90, a controlled 90-item subset of the UniM dataset, with two agents serving as hosts: GPT-5.6 Sol and Claude Sonnet 5. The numbers have to be read with an eye to which host they belong to.
| Metric | GPT-5.6 Sol | Claude Sonnet 5 |
|---|---|---|
| Input support rate (before → after harness) | 40.00% → 100% | 38.89% → 100% |
| Relative SQCS (before → after) | 26.99 → 74.94 | 27.82 → 77.78 |
| Strict Structure Score | 100.00 | 99.78 |
| Lenient Structure Score | 100.00 | 100.00 |
Input support rate means whether the request could even be accepted and handled in the first place. Before the harness, neither host could take in even half the requests; after it, both processed all 90 instances. The relative value of SQCS (Semantic–Quality Coupled Score, which looks at meaning and quality together) rose by 47.95 points on GPT-5.6 Sol and 49.96 points on Claude Sonnet 5.
There's one contrast worth noticing. With the harness in place, the absolute SQCS is 74.94 and 77.78 across all instances — higher than the 67.49 and 71.53 the base agents scored on the narrower subset they could handle on their own. Put simply, the harness widened coverage to everything without shaving off quality. Normally, broadening the range you handle drags average quality down; here the opposite happened.
To be honest, there are things worth flagging. First, the evaluation is confined to UniM-90, a controlled 90-item subset. The authors themselves describe it as a "controlled" setting, so this paper alone can't settle whether the same numbers hold up against the messy requests of real production. Second, the metrics center on structure scores and SQCS. A structure score near 100 means the output's form and completeness are well in place — not a guarantee that the content is at the level of a human expert. Third, the harness's strength ultimately leans on the quality of the specialist models and media engines bolted on behind it. The "swappable backend" design is a strength, but it also means that if the backend is weak, the harness is only as good as that. Fourth, the 27 skills and 38 tasks are a catalog humans designed and loaded in. When a new domain comes along, who expands the skills and at what cost isn't revealed by the abstract and excerpts alone.
Picture a scene. A customer uploads a recording of a team meeting along with some reference documents and asks for "a summary." The AI PM produces the summary and hands it over. A few days later the same customer comes back with "take that content and pull together one explainer video for onboarding new hires."
The common way of handling this today treats the two requests as essentially strangers. On the second turn, it pulls the recording and documents back up and analyzes them from scratch, drafting a fresh video script without reviving the key points, terminology, and figures already extracted in the first summary. So the tone and emphasis of the summary and the video drift subtly apart, and the customer asks, "why did that point we nailed down last time get dropped?"
The asset registry and cross-turn reuse that Omni-IO Skills describes change precisely this. On the first turn, the transcription, the document summary, and the extracted key points are each registered in the registry. The video task on the second turn, instead of re-analyzing the raw material, takes those registered intermediate artifacts as input and strings script → narration → video together as a DEG. Independent branches like the narration audio and the illustrations run at the same time. All the PM has to care about is an instruction like "use the three conclusions we laid out in the meeting summary as the video's opening"; the plumbing of carrying assets between tools is the harness's job.
For ONTLE's model of a dispatched AI PM, the implication of this picture is clear. A single customer's project piles up across many turns, moving between documents, images, video, and data. If context evaporates each turn, the PM asks from scratch every time, like a new intern. Conversely, when intermediate artifacts persist as assets at the project level and the next request builds on top of them, a dispatched PM's consistency moves closer to that of a human in charge. That said, the limits above apply just the same. Even if ONTLE adopts this kind of asset layer, what divides the results you actually feel is the quality of the back-end engines that produce the real video, images, and documents — and how you expand and maintain the skill catalog. The harness only lays the plumbing; it doesn't guarantee the taste of the water.
No. The paper's core claim is that it "doesn't change the host agent's reasoning core." Because it works by bolting on a detachable harness, the experiments confirmed the effect by attaching the same harness to two different hosts.
Instead of procedurally spelling out, step by step, the order in which to run tasks, you declare as a graph which tasks exist and what each depends on — and the system then schedules tasks with no dependencies between them to run concurrently on its own. Execution-order optimization and failure isolation are handled by graph validation and a scheduler, not by a person.
The current implementation is stated to total 27 — 19 Atomic, 2 Expert, 6 Scenario. The paper describes the skill, runtime, and asset layers as an "evolvable" structure that can adapt to the model, the tools, and application needs, but the concrete cost or procedure for adding a new skill isn't revealed within the scope of the abstract and excerpts.
No. Input support rate measures whether the request itself could be accepted and handled. Quality is measured separately, via SQCS and structure scores, and those values are not 100 — they sit at levels like 74.94 and 77.78 (relative SQCS). Mixing the two metrics together and reading it as "everything's perfect" is a misunderstanding.