---
title: 'Murakkab: AI & Inheritance Complexity'
url: https://www.emergentmind.com/topics/murakkab
type: topic
---

# Murakkab: AI & Inheritance Complexity

Murakkab appears in recent arXiv literature in two different research contexts. In AI systems, it is the name of a resource-efficient framework and serving system for compound or agentic workflows, emphasizing a declarative workflow abstraction, profile-guided optimization, and an adaptive runtime that coordinates orchestration with cluster-level resource management [2501.16634]. In Islamic inheritance reasoning, *murakkab* denotes complex, compounded cases in ʿIlm al-Mawārith, where heir identification, blocking rules, fixed shares, residuary allocation, and global adjustments such as ʿawl and radd must be resolved across multiple dependent stages [2603.24012]. The shared lexical form therefore covers both a cloud-systems design for multi-component AI execution and a jurisprudential category of multi-stage inheritance problems.

## 1. Dual usage and definitional core

In the AI-systems literature, Murakkab is introduced first as “a prototype system the authors are building” to make **compound AI systems** more resource-efficient and later as “a resource-efficient serving system for multi-tenant agentic workflows in cloud platforms” [2501.16634]. The underlying problem class is explicitly defined as workflows that involve “multiple interacting components, including multiple calls to different AI models, retrievers, or external tools,” rather than a single-model invocation [2501.16634].

The later system paper places this within the vocabulary of **agentic workflows**. An agent is defined there as a composable unit powered by a model, instructions, and tools; when multiple specialized agents interact across modalities and stages, the result is an agentic workflow with conditional control flow and coordinated model/tool execution [2508.18298]. Murakkab is proposed as the serving substrate for such workflows under explicit service-level objectives (SLOs) on accuracy, latency, cost, and energy.

In the inheritance-reasoning literature, *murakkab* has a different meaning. It refers to inheritance cases that are “complex, compounded” because they require several interacting stages of legal reasoning: identification of heirs, **hajb** (blocking), assignment of **furūḍ** fixed shares, determination of **ʿaṣaba** residuaries, and then possible application of **ʿawl** or **radd** [2603.24012]. In that usage, murakkab is not a platform or runtime; it is a case class defined by rule interaction and arithmetic complexity.

## 2. Declarative workflow specification in the AI system

A central design principle of Murakkab as an AI system is the **decoupling of application logic from execution details**. The earlier paper contrasts an imperative style—where developers hard-code OpenCV, Whisper, CLIP, Llama, API keys, CPUs, GPUs, PTUs, and GPU type H100—with a declarative style in which the developer supplies a job description, optional task hints, inputs, and a high-level constraint such as `MIN_COST` [2501.16634]. The system then decides how the workflow should actually be realized.

This declarative interface is preserved and generalized in the later work. Developers specify workflows as logical compositions of tasks without binding them to specific models or hardware. The resulting abstraction omits explicit model names, resource allocation, hardware tier, and parallelism choices unless the developer intentionally constrains them [2508.18298]. This suggests that Murakkab treats workflow code less as a fixed execution script and more as a logical specification subject to later optimization.

The internal representation is a **directed acyclic graph (DAG)**. In the January 2025 formulation, the orchestrator LLM decomposes a job into tasks, infers dependencies, and constructs a DAG whose nodes are tasks or agents and whose edges are dataflow relations [2501.16634]. In the August 2025 system, the logical workflow is formalized as \(G=(V,E)\), where \(V\) contains executors and \(E\) captures dependencies and data movement [2508.18298]. The later paper also emphasizes type-checking of interfaces and regeneration or developer feedback when no suitable executor exists.

Murakkab’s libraries are similarly declarative. The prototype paper describes an **agent library** storing each agent’s name, functionality, interface or schema, and candidate models or tools [2501.16634]. The later paper reframes this as an **executor library**, where an executor may be an LLM, a structured multi-LLM composition such as debate or self-reflection, or a tool such as OpenCV, OmDet, Whisper, web search, or file search [2508.18298]. In both descriptions, the orchestrator maps textual task descriptions onto an available library of executable components.

## 3. Optimization, runtime adaptation, and cross-layer resource management

Murakkab’s main systems contribution is the claim that workflow orchestration and cluster management should not remain separate layers. The earlier paper identifies three problems in current compound AI systems: tight coupling of application logic and execution details, disconnect between workflow orchestration and cluster management, and the perceived exclusiveness between efficiency and quality [2501.16634]. The later paper restates the same systems concern for multi-tenant cloud settings, emphasizing opaque workflows, disjoint framework-versus-platform control, and combinatorial cross-layer configuration spaces [2508.18298].

To address this, Murakkab exposes several runtime levers. The prototype paper explicitly lists **GPU generation**, **CPU vs GPU**, **task parallelism**, **execution paths**, and **model/tool** choice, with each lever affecting cost, power, latency, and quality differently [2501.16634]. It also notes that the configuration space can “easily explode,” so the system uses profiling plus “greedy search with hierarchical optimization” to prune choices. The later paper turns this into a more explicit optimization framework based on profile-guided optimization and a Mixed Integer Linear Program over workflows, SLO types, model profiles, workflow configurations, and resource types [2508.18298].

Profiling is fundamental in both versions. In the prototype, Murakkab maintains **execution profiles** for each \((\text{model/tool}, \text{hardware})\) pair, including efficiency metrics such as cost, power, and latency, and quality metrics such as accuracy or fidelity [2501.16634]. In the later serving system, profiling is split into **workflow profiles** and **model profiles**. Workflow profiles capture quality and per-stage token loads over configuration knobs such as STT on/off, frames per scene, debate rounds, or self-reflection rounds. Model profiles capture TTFT, TPOT, throughput per Wh, and cost across A100 versus H100, tensor parallelism settings, and software configurations [2508.18298].

The runtime itself is adaptive rather than static. In the earlier paper, the orchestrator receives cluster-manager information such as idle GPUs, available CPUs, and spot or harvestable resources, while the cluster manager receives workflow DAG structure, active tasks, and anticipated demand [2501.16634]. In the later paper, this becomes a two-layer control structure: epoch-scale MILP reoptimization based on workload traces and EWMA estimates, and fine-grain auto-scaling driven by observed request and token load [2508.18298]. The later paper further states that Murakkab supports four SLO tiers—**best**, **good**, **fair**, and **basic**—for both accuracy and latency, and dispatches requests to executable workflow variants that satisfy those tiers.

A recurring systems idea is **cross-layer optimization**. Murakkab does not optimize only model inference, only workflow logic, or only VM placement. It jointly reasons over workflow DAG structure, model selection, hardware choice, tensor parallelism, stage parallelism, and global metrics such as utilization, energy, cost, and latency [2508.18298]. This is the basis of the claim that existing workflow frameworks and cloud schedulers cannot achieve the same trade-offs when workflows remain opaque.

## 4. Empirical evaluation of the AI system

The earlier Murakkab paper evaluates a **Video Understanding workflow** derived from OmAgent, with the pipeline frame extraction \(\rightarrow\) speech-to-text \(\rightarrow\) object detection \(\rightarrow\) summarization [2501.16634]. The implementation uses OpenCV on CPUs for frame extraction, CLIP on CPUs for object detection, Whisper for speech-to-text, and NVLM both as orchestrator and for summarization. The evaluation runs on **Azure ND96amsr A100 v4 VMs**, each with 96 AMD EPYC vCPUs and 8 NVIDIA A100 80GB GPUs [2501.16634].

For that prototype, the imperative baseline completes in **283 seconds** (described as approximately **285 s** in the table) and exhibits heavy GPU underutilization [2501.16634]. Murakkab identifies STT as a key dependency, introduces **parallel STT**, **parallel frame summarization**, and **resource configuration adjustments**, and completes the workflow in **77–83 seconds** with **identical** result quality [2501.16634]. Reported GPU-energy figures are **155 kWh** for the baseline, **34 kWh** for the CPU STT configuration, **43 kWh** for the GPU configuration, and **42 kWh** for the GPU+CPU configuration. Under the `MIN_COST` constraint, Murakkab selects the CPU STT configuration, yielding the reported **\(\sim 3.4\times\)** speedup and **\(\sim 4.5\times\)** higher energy efficiency [2501.16634].

The later system paper broadens the evaluation to **Video Q/A**, **code generation**, and **math Q/A** workflows, deployed on Azure A100 and H100 VMs and driven by **24-hour LLM serving traces** from Azure’s production service [2508.18298]. It compares a static baseline with **Murakkab Optimized (Mrkb Opt)** and **Murakkab Optimized + Multiplexing (Mrkb Opt+Mult)**. The headline result is that Murakkab “reduces GPU usage by up to **2.8\(\times\)**, energy consumption by **3.7\(\times\)**, and cost by **4.3\(\times\)** while maintaining SLOs” [2508.18298].

The multi-workflow results are especially important because they instantiate Murakkab’s cross-layer argument. For a joint Video Q/A plus code-generation workload, the static baseline uses about **2,560 A100 GPUs**, **80.4 MWh**, and **\$201.5k**, whereas **Mrkb Opt+Mult** uses **908 GPUs**, **21.6 MWh**, and **\$46.5k** [2508.18298]. The later paper also includes a DAG-aware case study where keeping OmDet on GPU while offloading Whisper to CPUs meets a **30s latency SLO** and reduces GPU usage from **6 GPUs to 5**, illustrating that the optimizer can reason at the stage level rather than at the workflow-as-black-box level [2508.18298].

## 5. Murakkab in ʿIlm al-Mawārith

In the inheritance paper, *murakkab* denotes a difficult class of Al-Mawārith problems. Such cases involve many heirs across generations, non-trivial **hajb** chains, interactions between **furūḍ** and **ʿaṣaba**, and the need for careful fraction arithmetic under **ʿawl** or **radd** [2603.24012]. The paper organizes the reasoning process into a sequence: identification of heirs, blocking, fixed-share assignment, residuary allocation, and global adjustment.

The arithmetic core is represented by the sum of fixed shares,
\[
S=\sum_i f_i.
\]
The paper states the governing conditions directly: **ʿAwl** applies when \(S>1\), and **Radd** applies when \(S<1\) and there is no **ʿaṣaba** to absorb the residue [2603.24012]. It also describes taṣīl and a mass-coherence check on post-taṣīl percentages,
\[
\left|\sum_{h\in\mathcal{H}} p_h \cdot c_h - 100\right| \le \varepsilon,\quad \varepsilon=5,
\]
which is enforced by a validator after generation [2603.24012].

The proposed architecture is a **RAG-guided LLM pipeline** with three major components. First, a **deterministic inheritance calculator** encodes the fiqh rules for a particular rule profile and generates a synthetic corpus of about **100,000 cases** with full intermediate reasoning traces [2603.24012]. Second, inference uses **hybrid retrieval**—dense retrieval plus BM25, fused by Reciprocal Rank Fusion and reranked with a cross-encoder—to assemble jurisprudentially relevant evidence [2603.24012]. Third, a **Qwen 3.5-9B** model generates a `<think>` reasoning trace and a structured `<answer>`, after which a post-processing validator enforces constraints on keys, types, labels, and numerical coherence [2603.24012].

This stage-wise design is tailored to murakkab inheritance because the hardest cases are precisely those in which local errors cascade. The paper’s error analysis reports that **blocking logic accounts for 42% of residual errors**, **fraction arithmetic** for **31%**, **ʿAwl handling** for **18%**, and **formatting failures** for **9%** [2603.24012]. Nevertheless, the full pipeline achieves a **MIR-E score of 0.935** and ranks **first on the official QIAS 2026 blind-test leaderboard**, indicating that retrieval-grounded, schema-aware generation substantially improves reliability on these complex cases [2603.24012].

## 6. Limitations, misconceptions, and broader significance

A common misconception in the AI-systems discussion is that efficiency and quality are necessarily in strict opposition. Both Murakkab system papers argue against that assumption. The prototype paper explicitly targets the “perceived tradeoff: efficiency vs quality” and frames workflows as **fungible**, meaning that multiple implementations can provide similar quality at different cost and latency points [2501.16634]. The later paper operationalizes the same idea through SLO-aware optimization, filtering out configurations that fail accuracy or latency thresholds while still minimizing energy or cost [2508.18298]. A plausible implication is that Murakkab’s main novelty is not simply better scheduling, but the conversion of workflow design choices into an optimization surface visible to the runtime.

The AI-system papers also state clear limitations. The January 2025 paper notes profiling overhead, dependence on LLM quality for DAG creation and tool-call generation, the need for correctness checkpoints, and the engineering burden of deep cluster-manager collaboration [2501.16634]. The August 2025 paper adds workflow-structure assumptions centered on DAGs, hardware support focused on CPUs and GPUs rather than broader accelerator classes, and the simplicity of EWMA forecasting for epoch planning [2508.18298]. Proposed extensions include **AI Workflows-as-a-Service (AIWaaS)**, support for proprietary APIs, multi-cloud execution, more advanced heterogeneous scheduling, and integration of workflow auto-generation systems such as Autoflow, Flow, Aflow, and Optimas [2501.16634].

In the inheritance setting, an opposite misconception would be to treat *murakkab* as a software framework. In that literature it is a descriptor for case complexity, not a platform. The paper’s limitations are jurisprudential and reasoning-centric: current rule profiles do not cover all major Sunni madhāhib or civil-law variants, web-only retrieval lowers semantic precision, and multi-generation hajb chains plus rare denominator interactions remain the hardest patterns [2603.24012]. MIR-E, while multi-stage, also does not fully capture explanation faithfulness or practical juristic usability [2603.24012].

Taken together, these usages of *Murakkab* share a structural theme even though they belong to different domains: both concern problems that cannot be solved reliably by flattening them into a single step. In AI systems, Murakkab names an attempt to turn multi-component workflows into declarative, profile-guided, resource-aware executions on cloud platforms [2508.18298]. In Islamic inheritance reasoning, murakkab names the cases in which correct resolution requires explicit staged reasoning, retrieval grounding, and symbolic validation [2603.24012].

Source: https://www.emergentmind.com/topics/murakkab