Murakkab: AI & Inheritance Complexity

• Murakkab is a dual-usage term defining both a resource-efficient AI workflow system and a classification of complex Islamic inheritance cases.
• In AI systems, it employs a declarative workflow specification with profile-guided optimization and adaptive runtime for multi-agent orchestration.
• In inheritance reasoning, murakkab denotes compounded cases that require multi-stage legal analysis with precise arithmetic and rule-based validation.

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 (Chaudhry et al., 28 Jan 2025). 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 (Swaileh et al., 25 Mar 2026). 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” (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 28 Jan 2025).

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 (Chaudhry et al., 22 Aug 2025). 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 (Swaileh et al., 25 Mar 2026). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025).

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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025).

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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025).

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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 28 Jan 2025).

For that prototype, the imperative baseline completes in 283 seconds (described as approximately 285 s in the table) and exhibits heavy GPU underutilization (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 28 Jan 2025).

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 (Chaudhry et al., 22 Aug 2025). 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$V$0, and cost by 4.3$V$1 while maintaining SLOs” (Chaudhry et al., 22 Aug 2025).

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 $V$246.5k (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 22 Aug 2025).

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 (Swaileh et al., 25 Mar 2026). 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,

$V$3

The paper states the governing conditions directly: ʿAwl applies when $V$4, and Radd applies when $V$5 and there is no ʿaṣaba to absorb the residue (Swaileh et al., 25 Mar 2026). It also describes taṣīl and a mass-coherence check on post-taṣīl percentages,

$V$6

which is enforced by a validator after generation (Swaileh et al., 25 Mar 2026).

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 (Swaileh et al., 25 Mar 2026). 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 (Swaileh et al., 25 Mar 2026). Third, a Qwen 3.5-9B model generates a > reasoning trace and a structured <answer>, after which a post-processing validator enforces constraints on keys, types, labels, and numerical coherence (Swaileh et al., 25 Mar 2026).

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% (Swaileh et al., 25 Mar 2026). 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 (Swaileh et al., 25 Mar 2026).

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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 28 Jan 2025). 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 (Chaudhry et al., 22 Aug 2025). 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 (Chaudhry et al., 28 Jan 2025).

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 (Swaileh et al., 25 Mar 2026). MIR-E, while multi-stage, also does not fully capture explanation faithfulness or practical juristic usability (Swaileh et al., 25 Mar 2026).

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 (Chaudhry et al., 22 Aug 2025). In Islamic inheritance reasoning, murakkab names the cases in which correct resolution requires explicit staged reasoning, retrieval grounding, and symbolic validation (Swaileh et al., 25 Mar 2026).