Decompose complex AI tasks to improve performance across models
Decompose, Don't Expand: Capability-Independent AI Systems by Construction
Artificial IntelligenceHuman-Computer Interaction
Summary
When AI has trouble with hard tasks, you can either make the AI bigger and more complex or break the task into simpler parts. The authors found that many tasks can be split into a clear, rule-based part and a fuzzy part that only needs AI. This way, even small AI models work just as well on the fuzzy parts because the hard parts are handled by rules. They tested this idea across many models and different types of problems and showed it works without extra training.
What this means in practice
- •For software engineers: Build AI features by separating tasks into rule-based and fuzzy parts to enable consistent performance across model sizes without retraining.
- •For automation developers: Create automation pipelines that delegate deterministic steps to traditional logic and reserve AI for ambiguous subtasks, reducing need for large models.
Authors
Tejaswi Gowda
Abstract
A recurring design choice in building AI systems is whether, when a task is too hard for a model, to expand the model (make it larger, better-prompted, fine-tuned), or to decompose the task (extract the parts that admit a deterministic solution to a host, leaving the model only the irreducibly fuzzy residue). We make three claims. First, that many tasks commonly delegated whole to a model are in fact deterministic tasks with a small generative core. Second, and our central empirical result, that decomposing such a task yields a measurable and desirable property we call parity by construction: on the extracted sub-tasks the model-size performance curve becomes flat, because no model performs them at all. We measure this across nine models spanning a 494M-parameter local checkpoint to a frontier Opus-class model, a thirty-fold parameter range on the local family alone: once the host resolves the context, operation selection scores identically for all nine models and selector resolution for eight of nine, while the one task that does not decompose, labelling, remains sloped across the same range. Because the task leaves the model, a stock checkpoint suffices: no task-specific training and no fine-tuning. Third, that this is a general design discipline, not a domain trick: we show the same move recurring across physics setup, motion retargeting, and object-model editing, and in a Web-CLI tool family (same author, so not an independent replication). We give a method for locating the cut, the construction that makes a cut exist (a deterministic surface and a closed grammar over it), and a way to make the residue safe (resolve the deterministic context; verify the generative output), position the work against neuro-symbolic AI, tool-augmented language models, and generate-and-verify approaches, and are explicit about what is measured (one domain) versus illustrative (the rest).