Transparent Task Delegation in Multi-Agent Systems Using the QuAD-V Framework

Abstract

Task delegation in multi-agent systems (MASs) is crucial for ensuring efficient collaboration among agents with different capabilities and skills. Traditional delegation models rely on social mechanisms such as trust and reputation to evaluate potential partners. While these approaches are effective in selecting competent agents, they often lack transparency, making it difficult for users to understand and trust the decision-making process. To address this limitation, we propose a novel task delegation model that integrates explainability through argumentation-based reasoning. Our approach employs the quantitative argumentation with votes framework (QuAD-V), a voting-based argumentation system that enables agents to justify their partner selection. We evaluate our model in a scenario involving the distribution of petroleum products via pipelines, where agents represent bases capable of temporarily storing a quantity of product. The connections between agents represent transportation routes, allowing the product to be sent from an origin to a destination base. The results demonstrate the effectiveness of our model in optimizing delegation decisions while maintaining clear, understandable explanations for agents’ decisions.

1. Introduction

Multi-agent systems (MASs) play a fundamental role in various domains, enabling distributed problem-solving and autonomous collaboration among agents [1,2,3]. In many applications, agents must delegate tasks to others, taking advantage of different capabilities and expertise to achieve common goals [4,5,6]. Task delegation mechanisms typically rely on social evaluation metrics, such as trust and reputation, to assess potential partners [7,8,9,10,11,12]. In such cases, agents learn about their partners’ behaviors through direct and indirect experiences, as well as observations of environmental conditions [13,14]. For example, in [9], a Fuzzy Cognitive Map (FCM)-based structure [15] is used to integrate different trust components into a performance measure that agents use to infer the probability of delegation associated with a partner. Similarly, a reputation-based delegation model is proposed in [10], where the partners are selected based on a performance metric computed from direct social evaluations or third-party assessments. Finally, in [12], partners are chosen based on a performance measure represented as a reward factor that is updated as tasks are delegated among agents, considering direct experiences between delegators and their partners. However, in general, such models produce only a quantitative measure that influences partner selection, without providing an explicit explanation of why a particular partner is preferred. This lack of explainability can undermine trust in autonomous decision-making systems, particularly in critical domains where understanding the rationale behind decisions is essential, such as medicine or finance [16,17,18].

Explainability in computational systems has gained significant attention in recent years, as users increasingly demand transparency in automated processes [19,20]. The need for transparency arises from the growing integration of artificial intelligence (AI) and autonomous systems, particularly in domains where automated decision-making affects human lives [21,22]. As these systems become more complex, users not only expect effective solutions but also a clear understanding of the reasoning behind them. Explainability is particularly valuable in high-stakes domains, such as autonomous vehicles, military operations, and critical infrastructure management, where the consequences of poor decisions can be severe [23,24,25].

A solution that has been explored to generate explanations for computational systems is formal argumentation (FA). FA enables the generation of explanations by analyzing a set of arguments and the relationships established between them [26]. In the literature, different types of FA are presented, such as the abstract argumentation framework (AAF) introduced in [27], where arguments are treated as atomic entities without internal structure. This framework is formally defined as a set of arguments, and a conflict relation between them can be represented as a directed graph. An AAF does not require complex rules or advanced logical processing to resolve conflicts but has limited expressiveness, as it does not account for support relations between arguments. On the other hand, more sophisticated approaches, such as structured argumentation frameworks (i.e., ABA [28], ASPIC+ [29], and DeLP [30]), build argumentation based on logical rules and deductions, allowing for the formal modeling of arguments within a robust formalism. However, these approaches require specific grammars and generally present greater complexity for integration into applications without specialized libraries.

In this work, we propose a novel task delegation model that incorporates explainability through argumentation-based reasoning. Unlike traditional delegation models that rely solely on trust or reputation scores to select partners, our approach not only computes an evaluation metric but also justifies the decision by explaining the underlying reasons for a partner’s acceptance or rejection. In particular, the explanations about the agents’ decisions are generated based on the quantitative argumentation with votes framework (QuAD-V) [31]. Such a framework is based on bipolar argumentation frameworks (BAFs) [32], which are more expressive than AAF as they better capture dialectical relationships by considering both attacks and supports between arguments. QuAD-V offers a good balance between simplicity and expressiveness, as it can be modeled as a directed graph with two types of relations, without requiring defeasible logic or complex grammars. Additionally, QuAD-V is particularly suitable for scenarios that require explainability and human participation in decision-making. In our case, the QuAD-V framework is used to address the problem of task delegation, where multiple delegators vote for the best partners based on their behavior. These features make our model transparent, as it provides clear justifications for agent decisions. Its straightforward design ensures high reproducibility and easy replication. Furthermore, the model is adaptable to different contexts by adjusting argument structures, maintaining its explanatory power across various delegation scenarios. These features (transparency, reproducibility, and adaptability) distinguish our model apart from existing delegation approaches.

To validate the effectiveness of the model, we simulate a scenario involving the distribution of petroleum products via pipelines. In this scenario, the pipeline network is modeled as a series of delegation chains, where intermediate agents represent temporary storage bases that facilitate the transportation of products from one point to another within the network. In this context, the QuAD-V framework is adopted to generate explanations at two levels: locally, by explaining the reasoning behind an individual agent’s decision, and globally, by justifying why a particular delegation route is optimal given the selected partners. Our results demonstrate that the proposed model not only enhances partner selection by allowing delegators to identify partners with high success rates, low rejection rates, and the ability to make accurate performance estimations, but also provides comprehensible explanations for the agents’ decisions, making the decision-making process more interpretable and trustworthy.

The remainder of this paper is structured as follows: Section 2 presents the basic concepts adopted in this work. Section 3 presents our proposed model, detailing the integration of the QuAD-V framework. Section 4 describes the experimental setup. Section 5 analyzes the results, highlighting the advantages of our approach. Finally, Section 6 concludes the paper and outlines future research directions.

2. Background

This section discusses the basic concepts that underpin our delegation model, including a description of the task delegation process and its phases, the social evaluation mechanisms adopted by agents to share their impressions about a partner, and a brief formalization of QuAD-V, where we describe how the acceptance score (i.e., the measure used by the agents to select their partners) is computed based on a set of arguments.

2.1. Task Delegation

A task delegation scenario involves an agent (delegator) who aims to achieve a goal g but cannot perform a task $\tau$ necessary to accomplish g by itself. Thus, to achieve its goal, the delegator needs to delegate $\tau$ to a partner (delegatee) capable of completing $\tau$ from the delegator’s perspective [2,9]. In this scenario, the delegator will achieve g only if the delegatee successfully completes $\tau$ [14]. In particular, we divide the task delegation process into three phases (i.e., offer request, partner selection, and execution):

• Offer request: A delegator notifies its partners of the intention to delegate a task $\tau$ (i.e., a task request). After receiving such a notification, partners send their offers to the delegator, providing their performance estimations for $\tau$. Performance estimates are made based on the task criteria (e.g., the cost and time required to perform $\tau$).
• Partner selection: After receiving offers from its partners, the delegator selects its delegatees. This selection involves evaluating each partner, considering their availability, effectiveness in performing $\tau$, and accuracy in meeting estimates (competence).
• Task execution: Delegatees execute tasks, while delegators evaluate their performance. A delegator $\alpha$ assesses a delegatee, $\beta$, based on the outcome produced for task $\tau$. This outcome, a tuple similar to an offer, reflects $\beta$’s actual performance. If $\beta$ successfully delivers an outcome, $\tau$ is complete or partially complete, depending on how accurately $\beta$ met its performance estimates. Otherwise, $\beta$ fails to perform $\tau$.

Definition 1.

An offer is a four-tuple $\langle \alpha$, β, τ, $V\rangle$, where

• α is the agent who requests the offer (delegator);
• β is the agent who produced the offer (partner);
• τ is the task that α intends to delegate to β if β is selected as its delegatee;
• $V=[(c_1,v_1), \dots , (c_k,v_k)]$ is a vector that represents the performance estimations made by β, where each value $v_i\in [0,+\infty ]$ is a β’s estimation for a τ’s criterion $c_i$.

2.2. Impressions

Impressions are evaluative beliefs that a delegator $\alpha$ produces or receives from third parties about $\beta$’s competencies as a delegatee for $\tau$. These beliefs attest to $\beta$’s capability to perform the task $\tau$ according to its performance estimates [33]. For example, an impression, produced by $\alpha$, can include scores assigned to $\beta$ for performing $\tau$ within the agreed budget and delivery time, based on criteria such as cost and time. These scores reflect how well $\beta$ met the expectations of $\alpha$ for $\tau$.

Definition 2.

An impression is a five-tuple $\langle \alpha$, β, τ, t, $S\rangle$, where

• α is the delegator who formed the impression.
• β is the assessed delegatee.
• τ is the task performed by β.
• t is the time in which the impression was created by α.
• $S=[(c_1,s_1), \dots , (c_k,s_k)]$ is a vector of ratings, where a pair $(c_i,s_i)$ represents a score $s_i\in [0,1]$ assigned to β by α concerning its performance regarding a τ’s criterion $c_i$ of τ.

During task execution, a delegator $\alpha$ evaluates a delegatee $\beta$ by comparing $\beta$’s estimated performance for a task $\tau$ with the actual outcome, for each criterion associated with $\tau$. The estimation error for a criterion c is the difference between the estimated and actual performance. If this error is zero, $\beta$ accurately predicted its performance for c. Otherwise, in the impression produced by $\alpha$, $\beta$ is penalized based on its estimation error. Assuming an offer $Off=\langle \alpha ,\beta ,\tau ,V\rangle$ and an outcome $Out=\langle \alpha ,\beta ,\tau ,V^{\prime }\rangle$, the delegator $\alpha$ assigns a score to $\beta$ based on the criterion c of task $\tau$. This score is stored in an impression, represented as a five-tuple, $Imp=\langle \alpha ,\beta ,\tau ,t,S\rangle$, where S is a vector of ratings. The score assigned to c is denoted as $S\left[c\right]\in [0,1]$ and is formally defined as follows:

$$Imp\left(S\left[c\right]\right)=\left\{\begin{array}{cc}{\displaystyle \frac{Off\left(V\right[c\left]\right)}{Out\left(V^{\prime }\left[c\right]\right)}}\hfill & \mathit{if}isMin\left(c\right)\wedge Out\left(V^{\prime }\left[c\right]\right)\ge Off\left(V\left[c\right]\right)\hfill \\ {\displaystyle \frac{Out\left(V^{\prime }\left[c\right]\right)}{Off\left(V\right[c\left]\right)}}\hfill & \mathit{if}isMax\left(c\right)\wedge Out\left(V^{\prime }\left[c\right]\right)\le Off\left(V\left[c\right]\right)\hfill \\ 1\hfill & \mathit{otherwise}\hfill \end{array}\right.$$

(1)

where $isMin\left(c\right)$ and $isMax\left(c\right)$ indicate whether c is a minimization (e.g., time, cost) or maximization criterion (e.g., quality). If $\beta$’s estimation is accurate or exceeds $\alpha$’s expectations, the score for c is one [2,34].

Additionally, impressions can be grouped to build more comprehensive social measures of a partner’s competencies, including its social image, reputation, and know-how [13,35]. Even though these are distinct concepts, they are complementary in agent interactions. Social image represents a delegator’s personal assessment of a delegatee’s competencies based on direct interactions. It captures the delegator’s immediate impression of how well the delegatee performed in specific tasks. Reputation, on the other hand, is a collective measure formed by aggregating impressions from multiple delegators. It reflects a general consensus on a partner’s competencies as a delegatee, even when individual delegators lack direct experience with that partner. Know-how is a specialized form of reputation where a delegatee accumulates impressions from delegators about tasks performed in the past, similar to job references. These impressions can be shared with potential new delegators, offering additional information about the partners competencies concerning the execution of a given task.

To illustrate these differences, consider a scenario where an agent $\alpha$ (buyer) is evaluating an agent $\beta$ (seller) for book and magazine purchases. If $\alpha$ has previously interacted with $\beta$, it can form distinct social images based on its direct experiences—for instance, perceiving $\beta$ as a good bookseller due to high-quality books and fair prices while, at the same time, viewing $\beta$ as a poor magazine seller due to its limited diversity of magazines for sale. If no prior interactions exist, $\alpha$ can rely on $\beta$’s reputation, aggregating feedback from other buyers to assess $\beta$’s reliability. Additionally, $\alpha$ may request references from $\beta$ to infer its know-how, verifying its expertise as a book or magazine seller based on impressions provided by past clients who interacted directly with $\beta$ but are not directly related to $\alpha$.

2.3. QuAD-V Framework

The QuAD-V framework, proposed by [31], extends the quantitative argumentation debate framework (QuAD) [36]. Its main advantage is the ability to resolve debates using a voting system, where users vote for or against arguments. As defined in [31], QuAD-V is a six-tuple $(A,C,P,R,U,V)$, where

• A is a finite set of answer arguments (possible responses to a question).
• C is a finite set of con arguments (arguments opposing another argument).
• P is a finite set of pro arguments (arguments supporting another argument).
• R is an acyclic binary relation over $(C\cup P)\times (A\cup C\cup P)$.
• U is a finite set of users.
• V is a total function assigning votes $V(u,a)\in -, ?, +$, where $u\in U$ votes on argument $a\in (A\cup C\cup P)$.

In the QuAD-V framework, arguments can attack or support each other. Attackers and supporters of an argument are defined based on con and pro arguments, respectively. For any argument $a\in (A\cup C\cup P)$, the set of attackers is $R^{-}\left(a\right)=b\in C\left|\right(b,a)\in R$, and the set of supporters is $R^{+}\left(a\right)=b\in P\left|\right(b,a)\in R$. Moreover, each argument a has a vote-based score $bS\left(a\right)$ : $A\cup C\cup P\to \mathbb{I}$, with $\mathbb{I}=[0,1]$, computed from user votes:

$$bS\left(a\right)=\left\{\begin{array}{cc}0.5\hfill & \mathit{if}\left|U\right|=0\hfill \\ 0.5+(0.5\ast {\displaystyle \frac{N^{+}\left(a\right)-N^{-}\left(a\right)}{\left|U\right|}})\hfill & \mathit{if}\left|U\right|\ne 0\hfill \end{array}\right.$$

(2)

where $N^{+}\left(a\right)=\left|V^{+}\left(a\right)\right|$ is the count of positive votes, with $V^{+}\left(a\right)=u\in U:V(u,a)=+$, and $N^{-}\left(a\right)=\left|V^{-}\left(a\right)\right|$ is the count of negative votes, with $V^{-}\left(a\right)=u\in U:V(u,a)=-$. Note that in this modeling, an argument with no votes (i.e., $\left|U\right|=0$) is assigned a base score of 0.5, representing an initial state where it has not yet been evaluated positively or negatively by users [37]. Conversely, if all users vote in favor of an argument a (i.e., $|V^{+}\left(a\right)|=|U|$), its base score is 1 (fully positive), whereas if all users vote against it (i.e., $|V^{-}\left(a\right)|=|U|$), its base score is 0 (fully negative).

On the other hand, the acceptance score of an argument a ($aS\in [0,1]$) determines its strength. For example, 1 for accepted, 0.5 for neutral, and 0 for rejected [37]. This measure is computed by considering the influence of the attackers and supporters of the argument a. In particular, for each argument (parent), the attackers and supporters are extracted, forming two sequences of child arguments. These sequences can be normalized by the number of arguments, considering the strength of each argument within the sequence. The aggregated strength of a sequence of arguments is computed as follows:

$$\mathbf{s}\left(a\right)=\left\{\begin{array}{cc}0,\hfill & \mathrm{if}\mathbf{s}=\varnothing \hfill \\ {\displaystyle \frac{1}{\left|\mathbf{s}\right|}}{\displaystyle \sum _{i=1}^{\left|\mathbf{s}\right|}}{s}_i,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(3)

where s represents the strength of a sequence of arguments, either from the attackers or the supporters. Taking into account the aggregate strength of the attackers ($s_{att}$) and supporters ($s_{supp}$), the acceptance score of the argument is computed as follows:

$$aS\left(a\right)=\left\{\begin{array}{cc}bS\left(a\right)+(s_{supp}-s_{att})\times (1-bS\left(a\right)),\hfill & \mathrm{if}{s}_{supp}\ge s_{att}\hfill \\ bS\left(a\right)+(s_{supp}-s_{att})\times bS\left(a\right),\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(4)

Note that the process used to compute the acceptance score of an argument a ensures that stronger supporters amplify a’s acceptability without exceeding 1, while stronger attackers reduce it but never below 0.

3. Delegation Model

The proposed delegation model is built based on the QuAD-V framework (Figure 1). This model is employed by the delegators (users) during the partner selection phase of the task delegation process to assess their partners and select delegatees. Each partner maintains an instance of the framework, which accumulates the delegates’ votes as they interact with its partners. This ensures that the decision-making process continuously adapts based on new interactions, improving the selection process over time.

3.1. Evaluation Metrics

As illustrated in Figure 1, the framework contains only one answer argument ($A_1$). The acceptance score ($aS\in [0,1]$) quantifies the partner’s suitability based on past evaluations, reinforcing trust in consistently reliable partners while penalizing those with lower performance. If the answer argument is accepted ($aS\left(A_1\right)\ge 0.5$), the partner can be selected as a delegatee; otherwise, if rejected ($aS\left(A_1\right)<0.5$), the partner should not be accepted. As presented in Figure 1, a partner is evaluated based on three dimensions:

• Availability (associated with arguments from class $A_{2*}$) (The asterisk (*) indicates that all arguments in a class have identifiers starting with a specific number. For example, arguments 21 and 22 belong to the Availability class, while arguments 31, 32, 321, and 322 belong to the Effectiveness class.): This dimension reflects a partner’s capability to accept task requests from delegators. As presented in Figure 1, a delegator votes for or against this class of arguments based on the partner’s rejection rate ($RR(\beta ,\tau )\in [0,1]$), which represents the frequency with which a partner $\beta$ has rejected a task $\tau$ requested by its delegators over time:

  $$RR(\beta ,\tau )={\displaystyle \frac{{|(\beta ,\tau )}^{\circ }|}{{|(\beta ,\tau )}^{•}|}}$$

  (5)

  where ${|(\beta ,\tau )}^{\circ }|$ is the number of times $\beta$ rejected a task request for $\tau$ from a delegator due to being occupied with another task or being unable to perform $\tau$, and ${|(\beta ,\tau )}^{•}|$ is the number of times $\beta$ received a task request for $\tau$ from its delegators.
• Effectiveness (associated with arguments of class $A_{3*}$): This dimension estimates how often a partner successfully completes its tasks. A delegator votes for or against the arguments of this class based on the following measures:
  • Success rate ($SR(\beta ,\tau )\in [0,1]$): This measure indicates the frequency with which a partner successfully completes a task, allowing its delegator to achieve its goal. The success rate is calculated as follows:

    $$SR(\beta ,\tau )={\displaystyle \frac{{|(\beta ,\tau )}^{+}|}{{|(\beta ,\tau )}^{*}|}}$$

    (6)

    where ${|(\beta ,\tau )}^{+}|$ is the number of times that $\beta$ successfully completed $\tau$, and ${|(\beta ,\tau )}^{*}|$ is the number of times that $\beta$ attempted to execute $\tau$, regardless of the success or failure in performing $\tau$.
  • Success confidence ($SC(\beta ,\tau )\in [0,1]$): This measure indicates the reliability of a partner’s success rate ($\beta$) from the perspective of a delegator $\alpha$, taking into account the number of iterations between them. The success confidence tends to increase as the number of iterations between $\alpha$ and $\beta$ grows [38]:

    $$SC(\beta ,\tau )=I_U+(I_L-I_U)\ast {\left({\displaystyle \frac{I_n-\left|{(\beta ,\tau )}^{*}\right|}{I_n}}\right)}^2$$

    (7)

    where $I_L$ is the reliability lower bound, $I_U$ is the reliability upper bound, and $I_n$ is the number of interactions needed for $\alpha$ to accurately infer $\beta$’s success rate. (The parameters $I_U$, $I_L$, and $I_n$ are user-defined and configurable according to system needs. In our experiments, we assigned $I_U=1$ and $I_L=0$, meaning the confidence score starts at 0 and increases to 1 as interactions grow. We defined $I_n$ as the number of task requests received by $\beta$ from $\alpha$. Thus, a partner $\beta$ who frequently rejects task requests from a delegator $\alpha$ tends to have lower reliability scores from $\alpha$’s perspective, since the number of interactions between $\alpha$ and $\beta$ remains low relative to the total task requests received by $\beta$.)
• Competence (associated with arguments from class $A_{4*}$): This dimension evaluates whether a partner is capable of meeting the delegator’s expectations regarding task execution, considering the partner’s performance estimations. A delegator votes for or against arguments related to competence based on the following measures:
  • Competence score ($COMP(\beta ,\tau )\in [0,1]$): This measure provides an up-to-date value of the partner’s ability to fulfill its performance estimations. The competence score is computed as the simple average of the scores associated with the most recent impression produced by a delegator $\alpha$ regarding a delegatee $\beta$ during the task execution phase of the delegation process.
  • Social image ($SI(\alpha ,\beta ,\tau )\in [0,1]$): A social measure calculated by the aggregation of the set of impressions produced by a delegator $\alpha$ regarding the competencies of a partner $\beta$ as a delegatee of a task $\tau$. (To aggregate a set of impressions, a delegator $\alpha$ first averages such impressions for each task criterion, forming a single aggregated impression. Then, the final value is obtained by averaging the scores across all criteria [13,35].) The social image can be seen as $\alpha$’s personal opinion about $\beta$’s competencies, taking into account a task $\tau$ [10].
  • Reputation ($REP(\beta ,\tau )\in [0,1]$): A delegator $\alpha$ calculates $\beta$’s reputation regarding $\tau$ by aggregating impressions obtained from third parties (other delegators). Reputation, therefore, represents a collective evaluation shared within a group, where most members agree without necessarily verifying the truth or sources of the impressions [10,35]. In our case, the group consists of delegators who assess a common delegatee based on the execution of a specific task.
  • Know-how ($KW(\beta ,\tau )\in [0,1]$): It is a specialized form of reputation where delegators share impressions with their delegatees [8]. As $\beta$ interacts with delegators while executing $\tau$, it accumulates impressions on its competencies. These impressions, similar to job references, can be sent to a delegator $\alpha$ during partner selection [39,40]. By aggregating them, $\alpha$ computes a social measure of $\beta$’s know-how.

It is important to note that the QuAD-V structure adopted in our delegation is robust enough to handle inconsistent information during the processing of argument strengths. An inconsistency occurs when an argument is simultaneously supported and attacked by different sources. This issue is naturally resolved by the argumentation-based voting mechanism, which balances supporting and opposing arguments during the recursive computation of argument strength. By considering both supporting and opposing contributions, this process ensures that conflicting viewpoints influence the final acceptance score in a structured manner.

3.2. Explanation Generation Process

The explanations produced by our delegation model are built based on Algorithm 1. This algorithm takes as input an answer argument and its supporting QuAD-V framework. It recursively evaluates the strength of arguments related to the answer argument to construct an explanation. The generated explanation consists of a decision (acceptance or rejection) and a set of arguments that justify such a decision. If the acceptance score of the answer argument is greater than or equal to 0.5, the argument is accepted along with supporting arguments; otherwise, it is rejected and opposing arguments are provided as justification [37]. Additionally, Algorithm 1 follows four main steps to generate explanations:

• Initialization (lines 1–4): The algorithm initializes the necessary variables, including the sets of supporting arguments ($pros$) and opposing arguments ($cons$), as well as setting the acceptance threshold value ($TH$). Then, the children of the answer argument ($arg$) are retrieved from the QuAD-V framework.
• Processing supporting and opposing arguments (lines 5–7): For each child argument, the algorithm calls the GenerateExplanation function, which determines whether the child argument supports or opposes the answer argument. If the child is a supporting argument and has an acceptance score above the threshold, it is added to the set of supporting arguments ($pros$). If it is an opposing argument and has an acceptance score above the threshold, it is added to the set of opposing arguments ($cons$).
• Constructing the explanation (lines 8–14): After evaluating all supporting and opposing arguments, the algorithm constructs the explanation. The explanation consists of the decision (accepted or rejected) followed by a structured justification. If the answer argument meets or exceeds the threshold ($TH$), the explanation includes its acceptance and the supporting arguments that reinforce this decision. Otherwise, the argument is rejected, and the opposing arguments are included to justify the rejection.
• Recursive propagation (lines 17–25): The algorithm recursively processes the children of each argument, ensuring that all relevant arguments are considered when forming the explanation.

Algorithm 1 Generating Explanations based on QuAD-V Framework

1: Input: Argument $arg$, QuAD-V framework $fw$ 2: Output: Explanation for acceptance or rejection 3: Initialize $pros\leftarrow \varnothing$, $cons\leftarrow \varnothing$, $TH\leftarrow 0.5$ 4: $children\leftarrow fw.childrenOf\left(arg\right)$ 5: for each$child\in children$do 6:       Call GenerateExplanation($arg,child,TH,fw$) 7: end for 8: if$arg.baseScore\ge TH$then 9:        Append $(arg.content,ACCEPTED)$ to explanation 10:      Append supporting arguments $pros$ to explanation 11: else 12:       Append $(arg.content,REJECTED)$ to explanation 13:       Append attacking arguments $cons$ to explanation 14: end if 15: Return explanation 16: —————————————————▹                 Line separator 17: Function GenerateExplanation($father,child,TH,fw$) 18: if$fw.isProArgumentOf(father,child)$then 19:        Append $child$ to $pros$ if $child.baseScore\ge TH$ 20: else if$fw.isConArgumentOf(father,child)$then 21:        Append $child$ to $cons$ if $child.baseScore\ge TH$ 22: end if 23: if$fw.children\left(child\right)$ is not empty then 24:         for each $arg\in fw.children\left(child\right)$ do 25:               Call GenerateExplanation($child,arg,TH,fw$) 26:         end for 27: end if

In particular, the explanations follow a structured format. Each explanation contains the following: (i) the final decision (ACCEPTED or REJECTED), (ii) supporting arguments that justify acceptance, and (iii) opposing arguments that justify rejection. Regarding the completeness of the explanation generation process, the algorithm always produces an explanation, as the acceptance decision is determined based on the predefined threshold ($TH$). Even in cases where there are no supporting or opposing arguments, the explanation will still contain a decision based on the acceptance score of the answer argument.

Regarding the computational cost of Algorithm 1, it depends on the size of the argumentation graph processed within the QuAD-V framework. The algorithm follows a depth-first search (DFS) approach, recursively traversing the argumentation structure. Since a QuAD-V framework is represented by an acyclic graph, arguments relate to each other in a directed and non-cyclic manner, preventing infinite loops and redundant computations. In particular, during argument strength computation, each argument (vertex) and its corresponding relations (edges) are visited once, leading to a time complexity of $O(n+m)$, where n is the number of arguments and m is the number of argument relations. This ensures that explanation generation remains efficient even for large argumentation graphs, as it scales linearly with the structure size. Unlike general argumentation frameworks that may require iterative convergence or cycle detection, QuAD-V maintains predictable performance due to its tree-like organization.

We highlight that in scenarios where multiple tasks are executed concurrently, performance degradation is mitigated by the independent processing of argumentation graphs per delegation instance. Consequently, different delegators can evaluate distinct delegatees in parallel, as the voting processes applied to QuAD-V framework instances for different partners are independent of each other.

4. Case Study

The issue addressed in this paper focuses on a multi-modal logistics network for petroleum-based products [41,42]. The scenario is represented as a graph $G(B,E)$, where B denotes a finite set of bases b, and E represents a finite set of connections e. Each connection $e\in E$ links a pair of bases $(b_i,b_j)$, where $b_i, b_j\in B$ correspond to the origin and destination bases, respectively. Moreover, a route is defined as a finite sequence of bases connected by edges, used to transfer a quantity of product from a source base $b_i$ to a destination base $b_j$.

4.1. Network Structure

Our experiments were conducted using a graph structure consisting of 10 bases (agents). As presented in Figure 2, a base can assume the role of root, inner, or terminator. A root base can only send products to others, an inner base can receive and send products, and a terminator base can only receive products. In particular, the simulation involves transporting a quantity of product from a root agent (origin base) to a terminator agent (destination base). Additionally, each base stores a finite amount of product (current stock). Moving a quantity of product between bases incurs storage and transportation costs, as well as time consumption. The cost of transporting a product from a base $b_i$ (delegator) to a base $b_j$ (delegatee) depends on the storage capacity and the storage cost of $b_j$’, which is added to the transport cost (throughput cost). Both storage and throughput costs are defined per unit of product. In contrast, the transport time depends on the throughput of the edge $e_{i-j}$, considering the total quantity of product to be transported between the bases.

The delegation process starts at the root base and spreads through the network until it reaches the terminator base, signaling the end of an iteration. During an iteration, a delegator can perform several delegation actions, as its goal is to reduce the quantity of product in its stock to zero. An iteration is represented by a series of delegations required to transport a quantity of product from the root base to the terminator base.

4.2. Task Delegation Dynamics

The delegation process begins when a delegator notifies its partners (neighboring bases) of its intention to send a specific quantity of product (task request). Upon receiving this notification, each partner responds with an offer, including their performance estimations for the task (offer request phase). These estimations detail the expected storage capacity, transportation cost, and time required to execute the task. If a partner lacks available storage or is already engaged in another task, it rejects the request and does not send an offer.

After receiving the offers, the delegator selects its delegatees based on the acceptance score in each partner’s QuAD-V framework (partner selection phase). Once a delegatee completes the task, the delegator provides a vote and an impression based on the delegatee’s performance (task execution phase). This impression is shared with the delegatee (reference) and other delegators who may interact with the delegatee in the future, contributing to the delegatee’s reputation.

4.3. Failure Likelihood

We assume that a delegatee may fail at the beginning of the execution phase of the task delegation process. The likelihood of failure is determined by its failure probability (Figure 2). A higher failure probability increases the risk of failure. When a failure occurs, one of the following events may take place:

• Complete failure (80% chance): The delegatee entirely fails to execute the task, preventing the delegator from sending the product and achieving its goal. Consequently, the delegator must initiate a new task request (offer request phase). Each complete failure decreases the delegatee’s success rate and results in an impression where all task criteria receive a score of zero.
• Partial performance deviation (20% chance): The delegatee completes the task but underperforms. The actual stored quantity ranges from 50% to 100% of the expected amount, while the completion time may be up to four times longer. The cost is adjusted proportionally based on the actual time, using a uniform random variable in the range $\left(\right[0,1\left]\right)$.

Therefore, a delegatee may not fully meet the performance estimates associated with its offer. However, this is not classified as a complete failure, as the delegator can still achieve its goal, either fully or partially, even if a lower quantity of the product is sent, costs are higher, or delivery is delayed. In such cases, instead of a complete failure impression, the delegator generates a negative impression reflecting the delegatee’s competencies.

5. Experimental Results

Our simulation consisted of 100 iterations. Each iteration represents a series of delegations required to transport a quantity of product from the root base to the terminator base. The network shown in Figure 2 is used as input for the simulation, configuring the initial states of each base at the beginning of each iteration. However, the votes cast by delegators, along with their impressions, are retained across iterations, serving as a memory of their partners’ behaviors.

5.1. Partner Selection Policy

In our evaluation, the partner selection is performed using a variation of $ϵ$-greedy algorithm [43], in which the parameter $ϵ$ depends on the number of times a delegator $\alpha$ delegated a task $\tau$ ($\left|\right(\alpha ,\tau \left)\right|$) to another agent. This policy meets our needs for an exploitation/exploration mechanism without additional complexity required by more sophisticated policies, such as UCB1 [44] and Thompson sampling [45]. The value assigned to $ϵ$ is calculated as follows:

$$ϵ={\displaystyle \frac{1}{\left|\right(\alpha ,\tau \left)\right|+1}}$$

(8)

where the probability of exploration becomes higher as $ϵ$ approaches 1. In this case, a delegator tends to select a partner randomly. Otherwise, $\alpha$ exploits its known options by selecting partners based on their acceptance scores. The higher a partner’s acceptance score, the greater the likelihood of it being chosen as $\alpha$’s delegatee.

5.2. Results

In Figure 3, the results obtained from the simulation are presented. Note that the success rate, rejection rate, competence score, and the acceptance score over iterations are shown for each inner base (i.e., bases able to act as partners). Bases with a higher probability of failure are more likely to be unable to complete a task or fail to meet performance estimations, which negatively affects their success rate and competence score, making them less reliable as delegatees. Moreover, as can be seen in Figure 3, in the first iterations (generally up to around iteration 25), the delegators tend to explore their partner options in order to find the most suitable delegatee. These initial iterations represent a learning period during which delegators collect information about their partners as they interact with others (i.e., producing their own impressions through direct experiences or receiving opinions from third parties). After the learning phase, delegators tend to exploit the best partner choices, resulting in more stable partner behavior, as the best choices have already been discovered, and the probability of random selections decreases with each new iteration.

As expected, the best route identified in our simulation prioritized bases with lower failure likelihoods (Figure 2), minimizing the risks associated with failed delegations. In particular, a base $b_i$ is part of a transportation route if, at some point during the iteration, it was used to temporarily store a quantity of the product. The results confirm this behavior through the analysis of the acceptance score curve (red line). The agents included in the best route demonstrate a balanced combination of success rate, competence score and rejection rate, making them the most suitable choices for delegation. In particular, when considering the rejection rate to select a partner, a delegator considers not only the partner’s ability to complete a task or meet its expected performance but also its availability, which reflects how often a base has refused a task due to being occupied or lacking the capacity to store the received product.

Another crucial aspect shown in Figure 3 is the threshold values ($T{H}_A$ and $T{H}_B$), which determine how delegators vote on partners’ arguments in the QuAD-V framework, affecting their acceptance scores. $T{H}_A$ evaluates a partner’s effectiveness and competence: to be positively rated, a partner must have values for success rate and competence score greater than or equal to 0.7. This threshold ensures that only partners demonstrating at least 70% of the maximum performance are positively rated, favoring those with a strong history of successful task execution and high competence. $T{H}_B$ evaluates availability: a partner is considered available if its rejection rate is below 0.3. Since the rejection rate ranges from 0 to 1, this threshold allows for occasional rejections due to workload constraints while ensuring that partners remain sufficiently accessible to be considered reliable. These thresholds directly influence the acceptance score by setting criteria for positive evaluations. Bases that meet these conditions receive higher scores and are more likely to be selected as delegatees. The success rate, rejection rate, competence score and acceptance score reflect a partner’s overall performance at the end of each iteration. The acceptance score of an answer argument, however, is computed by the delegator during partner selection.

At last, we present in

Table 1. Average values of the performance metrics for each inner base from iterations 25 to 100.

Base	Success Rate	Rejection Rate	Competence Score	Acceptance Score
$b_1$	0.32	0.03	0.69	0.49
$b_2$	0.75	0.07	0.89	0.82
$b_3$	1.00	0.29	0.99	0.82
$b_4$	0.75	0.27	0.88	0.63
$b_5$	0.27	0.20	0.71	0.61
$b_6$	1.00	0.30	0.99	0.65
$b_7$	0.43	0.08	0.74	0.65
$b_8$	1.00	0.17	0.99	1.00

the average values of the performance metrics for each inner base, considering a window of iterations from 25 to 100. This window was selected because, around iteration 25, delegators tend to exploit known partners with acceptable and well-established behaviors rather than explore unknown or less familiar ones, leading to system stabilization. Note that Table 1 confirms the performance of the bases that form the best route ($b_2$, $b_3$, $b_4$, $b_6$, $b_8$). These bases exhibit a good balance across evaluation metrics, demonstrating a favorable trade-off between success rate, competence score, rejection rate, and acceptance score. This suggests that such bases are consistently chosen as delegatees due to their reliability and overall effectiveness in task execution.

5.3. Explanations

Figure 4 and Figure 5 show the explanations produced to justify the behavior of one of the bases on the best route, base 3 ($b_3$) during iteration 25 (i.e., local explanation), and the choice of the best transportation route at the end of the simulation (i.e., global explanation), respectively. We highlight that the process used to produce these explanations (described in Algorithm 1) can be adopted to justify the choice of a partner for any delegator. Moreover, note that by adapting the input arguments (answer argument), the same process can be applied to different decision-making contexts, such as selecting a delegatee or evaluating transportation routes.

For instance, a similar QuAD-V framework, as presented in Figure 1, can be used to evaluate transportation routes. By averaging the base scores of each argument across all frameworks of the bases involved in the route, it is possible to compute the mean base score for each argument. Using these computed scores as input, Algorithm 1 determines the acceptance score of the route. The flexibility of this approach allows for argument substitution while maintaining the same reasoning process. For example, the argument ‘The partner has a high success rate, meaning it successfully completes most of its assigned tasks’ can be reformulated as ‘On average, the bases in the route have a high success rate, meaning they successfully complete most of their assigned tasks’. Consequently, the same explanation process that justifies the selection of a delegatee can also be applied to explain why certain routes are preferable over others.

6. Conclusions

In this work, we presented a task delegation model built upon a voting-based argumentation framework (QuAD-V framework). Using this model, agents (delegators) can select their partners (delegatees) for a given task by considering three evaluation dimensions: effectiveness, availability, and competencies. These dimensions are translated into an acceptability measure (acceptance score), which, in turn, summarizes the partner’s behavior as a delegatee. However, it is important to note that our model is flexible and can accommodate additional characteristics by incorporating new argumentation criteria into its structure, allowing it to be adapted to different delegation scenarios.

The main contribution of the proposed delegation model is its capability to generate explanations for the delegators’ choices. Due to the adoption of the QuAD-V framework, our model can justify the delegators’ deliberative actions by providing the reasons behind the selection of a certain partner. Furthermore, the modeling approach introduced in this work can be easily adapted to different contexts. As discussed in our case study, the framework was also employed to generate explanations justifying why one transportation route is better than others.

As future work, we intend to apply the proposed model to explain partner selection in dynamic environments where agents can enter and leave the system, as well as exhibit behavioral changes over time. Thus, our model could be used not only to justify the choice of a potential partner but also to explain the reasons behind behavioral changes. For instance, it would be possible to identify the reasons that lead a partner who previously demonstrated good behavior—such as meeting performance estimates and completing assigned tasks—to start failing in its estimations and in the execution of delegated tasks.

Additionally, we aim to explore our model to generate counterfactual explanations. Counterfactuals are particularly useful for understanding how different decisions or conditions could have led to alternative outcomes. In the context of task delegation, counterfactual explanations can help answer questions such as: “What if a different partner had been chosen?” or “What if a delegatee had a higher acceptance score?” Such elements contribute to transparency and trust in decision-making processes and are particularly valuable in scenarios where human agents collaborate with artificial agents.

To conclude, in this work, we assume that agents vote based on threshold values, which ensures interpretability and structured evaluation. However, in practical applications, voting motivations can be complex and context-dependent. To better capture this complexity, we propose three possible extensions to the current threshold-based approach: thresholds could be dynamically adjusted over time using machine learning techniques based on delegators’ experiences in evaluating their partners; different delegators may have distinct evaluation criteria, so thresholds could be personalized based on user profiles; and replacing strict thresholds with an interval-valued membership function would allow for smoother transitions between positive and negative votes. These extensions would enable the model to better accommodate diverse voting behaviors while preserving interpretability and structured evaluation.