Constraints Enabled Autonomous Agent Marketplace: Discovery and
Matchmaking
Debmalya Biswas
Wipro AI, Switzerland
Keywords:
Multi-Agent Systems, Autonomous Agents, Discovery, Constraints, Composition, Marketplace.
Abstract:
The recent advances in Generative AI have renewed the discussion around Auto-GPT, a form of autonomous
agent that can execute complex tasks, e.g., make a sale, plan a trip, etc. We focus on the discovery aspect
of agents, i.e., identifying the agent(s) capable of executing a given task. This implies that there exists a
marketplace with a registry of agents - with a well-defined description of the agent capabilities and constraints.
In this paper, we outline a constraints based model to specify agent services. We show how the constraints
of a composite agent can be derived and described in a manner consistent with respect to the constraints of
its component agents. Finally, we discuss approximate matchmaking, and show how the notion of bounded
inconsistency can be exploited to discover agents more efficiently.
1 INTRODUCTION
In the Generative AI context, Auto-GPT (aut, 2023)
is representative of an Autonomous AI Agent that can
execute complex tasks, e.g., make a sale, plan a trip,
make a flight booking, book a contractor to do a house
job, order a pizza. Given a user task, Auto-GPT aims
to identify (compose) an agent (group of agents) capa-
ble to executing the given task. A high-level approach
to solving such complex tasks involves: (a) decom-
position of the given complex task into (a hierarchy
or workflow of) simple tasks, followed by (b) com-
position of agents able to execute the simpler tasks.
This can be achieved in a dynamic or static manner.
In the dynamic approach, given a complex user task,
the system comes up with a plan to fulfill the request
depending on the capabilities of available agents at
run-time. In the static approach, given a set of agents,
composite agents are defined manually at design-time
combining their capabilities.
Generative agents (Park et al., 2023) follow a
long history of research around Multiagent Sys-
tems (MAS) (Weiss, 2016), especially, Goal Oriented
Agents (Bordes et al., 2017; Yan et al., 2015). The
main focus of this paper is on the discovery aspect of
agents, i.e., identifying the agent(s) capable of execut-
ing a given task. This implies that there exists a mar-
ketplace (aim, 2023) with a registry of agents, with a
well-defined description of the agent capabilities and
constraints.
For example, let us consider a House Painting
Agent C whose services can be reserved online (via
credit card). Given this, the fact that the user requires
a valid credit card is a constraint and the fact that
the user’s house will be painted within a certain time
frame are its capabilities. In addition, we also need to
consider any constraints of C during the actual execu-
tion phase, e.g., the fact that C can only provide the
service on weekdays. The above restriction might be a
problem if the user specified task requires getting the
work done during weekends. In general, constraints
refer to the conditions that need to be satisfied to ini-
tiate an execution and capabilities reflect the expected
outcome after the execution terminates.
We have seen similar efforts in the past with API
marketplaces (API, 2023) and Universal Description,
Discovery and Integration (UDDI) (UDD, 2000) reg-
istries in the context of Web Services (Services Ori-
ented Computing). However, the service descriptions
captured in XML or JSON are too static, and lack the
necessary semantic information for a capabilities “ne-
gotiation” during their discovery.
In the context of MAS, specifically, previous
works (Capezzuto et al., 2021; Trabelsi et al., 2022;
Veit et al., 2001) have considered agent limitations
during the discovery process. (Capezzuto et al., 2021)
specifies a compact formulation for multi-agent task
allocation with spatial and temporal constraints. (Tra-
belsi et al., 2022) considers agent constraints in the
form of incompatibility with some resources. The
396
Biswas, D.
Constraints Enabled Autonomous Agent Marketplace: Discovery and Matchmaking.
DOI: 10.5220/0012461700003636
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 16th International Conference on Agents and Artificial Intelligence (ICAART 2024) - Volume 1, pages 396-403
ISBN: 978-989-758-680-4; ISSN: 2184-433X
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.

authors then propose an optimal matchmaking algo-
rithm that allows the agents to relax their restric-
tions, within a budget. While similar to the notion of
’bounded inconsistency’ in our specification, we bake
this relaxation in the matchmaking process; rather
than requiring the agents to individually relax their
constraints. (Veit et al., 2001) proposes a configurable
XML based framework called GRAPPA (Generic Re-
quest Architecture for Passive Provider Agents) for
agent matchmaking. However, none of the above ap-
proaches consider composability of the component
agent services’ constraints.
In this paper, we take a holistic look at agent con-
straints, and their role in the discovery and matchmak-
ing process - enabling an Autonomous AI Agent Mar-
ketplace. We outline a Predicate Logic based Con-
straints Model to capture/specify the constraints of
services provided by an AI Agent in Section 2.
A significant contribution of this paper is the
aspect of constraints composition and its impact
on agent discovery. Determining the description
of a complex composite service, by itself, is non-
trivial (Casati et al., 2000). Given their inherent
non-determinism (allowed by the “choice” operators
within a composition schema), it is impossible to stat-
ically determine the actual subset of component ser-
vices that would be invoked at run-time. The above
implies the difficulty in selecting the component ser-
vices whose constraints should be considered while
defining the constraints of the composite service. Ba-
sically, the constraints of a composite service should
be consistent with the constraints of its component
services. In this paper, we take a bottom-up approach
and discuss how the constraints of a composite ser-
vice can be consistently derived from the constraints
of its component services - Section 3.
We discuss how matchmaking can be performed
based on the constraints model in Section 4. Current
matchmaking algorithms focus on “exact” matches.
They do not consider the scenario where a match does
not exist. We propose to overcome the above by al-
lowing inconsistencies during the matchmaking pro-
cess (does not have to be an exact match) up to a
bounded limit. Section 5 concludes the paper and pro-
vides some directions for future work.
2 CONSTRAINTS MODEL
Constraints refer to the characteristics of an agent ser-
vice that need to be considered for successful execu-
tion of that service. Before proceeding, we would like
to discuss some heuristics to decide if a characteristic
should (or should not) be considered as a constraint.
If we consider constraints as limitations, then the fact
that an Airline ABC cannot provide booking for a
particular date is also a limitation, and hence a con-
straint. However, we do not expect such characteris-
tics to be expressed as constraints as they keep chang-
ing frequently. Given this, what should (or should
not) be expressed as constraints is very much context-
specific, and we consider constraints as a level of fil-
tering during the discovery and matchmaking process.
An agent P provides a set of services
{S
1
, S
2
, ··· , S
n
}. Each service S in turn has a
set of associated constraints {C
1
,C
2
, ··· ,C
m
}. The
constraints are specified as logic predicates in the
service description of the corresponding service
published by its agent. For each constraint C of a
service S, the constraint values maybe
• a single value (e.g., price of a service),
• list of values (e.g., list of destinations served by
an airline), or
• range of values (e.g., minimum, maximum).
The constraint values are specified as facts con-
taining the applicable values. More precisely,
a service S provided by P having constraints
{C
1
,C
2
, ··· ,C
m
} is specified as follows:
S(Y, X
1
, X
2
, ··· , X
m
) : −
C
1
(Y, X
1
),
C
2
(Y, list
2
), member(X
2
, list
2
),
··· ,
C
m
(Y, minVal
m
, maxVal
m
), X
m
≥ minVal
m
,
X
m
≤ maxVal
m
.
C
1
(P,value(C
1
)).
C
2
(P,list(C
2
)).
··· ,
C
m
(P,min(C
m
), max(C
m
)).
For example, the fact that an airline ABC provides
vegetarian meals and has facilities for handicapped
people on only some of its flights (to selected desti-
nations) can be represented as follows:
f light(Airlines, X, Y ) : −
veg meals(Airlines, Destination List),
member(X , Destination List),
hnd f acilities(Airlines, Destination List),
member(Y, Destination List).
veg meals(ABC, [Paris, Rennes]).
hnd f acilities(ABC, [Paris, Grenoble]).
We present the specification in a logic program
syntax so that it can be given as input directly to a
logic execution engine responsible for performing the
matchmaking. Note that the logic program represen-
tation above is not the most efficient as C
2
(Y, list
2
),
Constraints Enabled Autonomous Agent Marketplace: Discovery and Matchmaking
397

member(X
2
, list
2
), for instance, can be easily replaced
by the direct check member(X
2
, list(C
2
)). However,
we intentionally keep the data (constraint values) sep-
arate (as facts) as it is important not only from a de-
sign perspective, but also required for the composition
process later (Section 3).
Now, let us consider “related” constraints or sce-
narios where there exists a relationship among the
constraints. By default, the above specification as-
sumed an AND relation among the constraints (all the
constraints C
1
,C
2
, ··· ,C
m
have to be satisfied). Some
relationships studied in literature for the composition
of logic programs are: AND, OR, ONE-OR-MORE,
ZERO-OR-MORE and any nesting of the above. We
only consider the relationships AND, OR and any
level of nesting of both to keep the framework sim-
ple (ONE-OR-MORE and ZERO-OR-MORE can be
expressed in terms of OR). We denote AND and OR
relationships between a pair of constraints C
1
and C
2
using the logical operators C
1
∧ C
2
and C
1
∨ C
2
, re-
spectively. The OR relationship between constraints
C
1
∨ C
2
··· ∨ C
m
of a service S provided by agent P
can be specified as a logic program as follows:
S(Y, X
1
) : −
C
1
(Y, list
1
), member(X
1
, list
1
).
S(Y, X
2
) : −
C
2
(Y, list
2
), member(X
2
, list
2
).
···
S(Y, X
m
) : −
C
m
(Y, list
m
), member(X
m
, list
m
).
For example: Airline ABC allows airport lounge
access at intermediate stopovers only if the passenger
holds a business class ticket or is a member of their
frequent flier programme. The above scenario can be
represented as follows:
lounge access(Airlines, X) : −
ticket type(ABC, X , Business).
lounge access(Airlines, Y ) : −
f requent f lier(Airlines, FF List),
member(Y, FF List).
Nested AND and OR relationships among the
constraints can be represented by first converting
the nested relationship into a Disjunctive Normal
Form (DNF), and then representing them as logic
programs (based on the proposed representation
mechanisms for AND and OR). More precisely,
a nested AND/OR relationship among the con-
straints of a service S provided by agent P in DNF:
(C
1
∧···∧C
k
)∨· · ·∨(C
1
∧···∧C
l
) can be represented
as a logic program as follows:
S(Y, X
1
, ··· , X
k
) : −
C
1
(Y, list
1
), member(X
1
, list
1
),
··· ,
C
k
(Y, list
k
), member(X
k
, list
k
).
···
S(Y, X
1
, ··· , X
l
) : −
C
1
(Y, list
1
), member(X
1
, list
1
),
··· ,
C
l
(Y, list
l
), member(X
l
, list
l
).
In the next section, we discuss mechanisms to
compose the constraints of a group of services, i.e.,
determine the constraints of a composite service, in
an automated fashion.
3 CONSTRAINTS COMPOSITION
We broadly outline two composition mechanisms:
Broker (Section 3.1) and Mediator (Section 3.2).
3.1 Broker
In the broker approach, the composite agent aggre-
gates similar services offered by different providers,
and provides a unique interface to them (mostly, with-
out any modification to their functionality). In other
words, the composite agent acts as a broker for the
aggregated set of services.
Given this approach, let a broker B aggregate a
common service S provided by agents P
1
, P
2
, ··· , P
r
.
Then, the constraints specification of S offered by B
can be obtained by a simple concatenation of the con-
straint logic program representations of S provided by
P
1
, P
2
, ··· , P
r
. For example, let us consider the follow-
ing scenario: A broker XY Z composing flight services
offered by Airlines ABC and DEF.
Airlines ABC
f light(Airlines, X) : −
hFacilities(Airlines, hdList),
member(X , hdList).
hFacilities(ABC, [Marseilles, Grenoble]).
Airlines DEF
f light(Airlines, X) : −
hFacilities(Airlines, hdList),
member(X , hdList).
hFacilities(DEF, [Rennes, Paris]).
With the above concatenation, we still have the
problem that the binding returned by the matchmak-
ing process would be ABC/DEF, and not the broker
agent XY Z. A simple rewriting of ABC and DEF by
XY Z does not solve the problem either, as XY Z itself
would internally like to keep track of who would be
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
398

the actual agent in the event of an invocation of S. We
overcome this problem by explicit assignment state-
ments in the predicates as follows:
Composite Agent (Broker) XY Z
f light(Airlines, X) : −
hFacilities(Airlines, hdList),
member(X , hdList),
Airlines = XY Z.
hFacilities(ABC, [Marseilles, Grenoble]).
f light(Airlines, X) : −
hFacilities(Airlines, hdList),
member(X , hdList),
Airlines = XY Z.
hFacilities(DEF, [Rennes, Paris]).
More precisely, the constraints of services offered
by broker B, aggregating service S provided by agents
P
1
, P
2
, ··· , P
r
, can be derived from their respective
constraints’ specifications as follows:
1. Concatenate the logic program representations of
the constraints of S provided by P
1
, P
2
, ··· , P
r
.
2. For each service predicate S (Y, X
1
, ···) in the con-
catenated logic program, add the assignment Y =
B in its body.
Note that this composition approach usually leads
to a relaxation of constraints. In the example sce-
nario, the composite agent XY Z would be able to of-
fer flights with facilities for handicapped people to
more destinations (Marseilles, Grenoble, Rennes and
Paris), than can be offered by either the component
airlines ABC (Marseilles, Grenoble) / DEF (Rennes,
Paris).
An analogous example scenario if the constraint
values were ranges (not lists): Let airlines ABC and
DEF offer flight services (to the same destinations) at
different price ranges: (A
min
, A
max
) and (D
min
, D
max
)
respectively. Then, the broker XY Z can offer flights
to the same destinations in the price range:
(min(A
min
, D
min
), max(A
max
, D
max
)).
Here also, the relaxation aspect of composition is
observed.
3.2 Mediator
In this approach, two or more services offered by (the
same or) different agents are composed to form a new
composite service with some additional logic (if re-
quired). We first consider only deterministic com-
position (component services invoked in sequence
or parallel), and then extend the mechanism to ac-
commodate non-determinism (possibility of choice
among the component services).
Given this approach, let an agent M com-
pose composite service SC from component services
S
1
, S
2
, ··· , S
n
(provided by providers P
1
, P
2
, ··· , P
n
,
respectively). For simplicity, we assume that each
service is provided by a different agent. As before,
we start with a concatenation of the constraint logic
program representations of S
1
, S
2
, ··· , S
n
. Here, in ad-
dition, we need to provide a unified interface group-
ing the component services S
1
, S
2
, ··· , S
n
. For exam-
ple, let us consider the following scenario: An Airline
ABC with facilities for handicapped people to selected
destinations,
Airline ABC
f light(Airlines, X) : −
hFacilities(Airlines, hdList),
member(X , hdList).
hFacilities(ABC, [Marseilles, Grenoble]).
and a transportation company DEF with facilities
for handicapped people on its local bus networks in
selected cities.
Transport DEF
bus(Tr ansport, X ) : −
hFacilities(Transport, ctList),
member(X , ctList).
hFacilities(DEF, [Marseilles, Rennes]).
Given this, the constraints of composite service
provided by Travel Agent XY Z can be specified as
follows:
Travel Agent XY Z
f light bus(Agent, X) : −
f light(Agent1, X), bus(Agent2, X),
Agent = XY Z.
f light(Airlines, X) : −
hFacilities(Airlines, hdList),
member(X , hdList).
hFacilities(ABC, [Marseilles, Grenoble]).
bus(Tr ansport, X ) : −
hFacilities(Transport, ctList),
member(X , ctList).
hFacilities(DEF, [Marseilles, Rennes]).
Note the f light bus predicate representing the
constraints of the newly formed composite service.
Also, the primitive service predicates are prefixed
with to indicate that those services are no longer avail-
able (exposed) for direct invocation, and as such their
constraints are not relevant independently anymore.
More precisely, the constraints of service SC com-
posed by M can be derived from the constraints’ spec-
ifications of its component services S
1
, S
2
, ··· , S
n
as
follows:
Constraints Enabled Autonomous Agent Marketplace: Discovery and Matchmaking
399

1. Concatenate the logic program representations of
the constraints of S
1
, S
2
, ··· , S
n
.
2. Append the prefix to all service predicates
S
i=1···n
(Y, X
1
, ···) in the concatenated logic pro-
gram.
3. Add the predicate:
S
C
(Y, X
1
, ··· , X
m
) : −
S
1
(Y, X
1
, ··· , X
k
), ··· , S
l
(Y, X
1
, ··· , X
l
),
Y = M.
where {X
1
, ··· , X
k
} ∪ · · · ∪ {X
1
, ··· , X
l
} =
{X
1
, ··· , X
m
}. We refer to this predicate as the
mediator predicate.
In contrast to the broker approach, this approach
highlights the restrictive nature of constraints com-
position, especially, if the component services share
a common constraint. For example, the newly com-
posed service f light bus can provide both flight and
bus booking with facilities for handicapped people to
fewer destinations (Marseilles), as compared to the
destinations covered by the component services in-
dependently: f light (Marseilles, Grenoble) and bus
(Marseilles, Rennes).
An analogous example scenario if the constraint
values were single values (and not lists): Let Airlines
ABC and transport company DEF offer services at $X
and $Y respectively, then the composite provider XY Z
would charge $(X +Y ) which is in sync with the re-
strictive nature of composition (the composite service
costs more than any of the component services).
3.3 Non-Determinism
The above mechanism for constraints composition
is sufficient if we know the set of component ser-
vices that will be invoked (deterministic composi-
tion). However, the composition approach also allows
a non-deterministic composition of services, where it
is possible to specify a choice among the component
services in the composition schema (the choice is re-
solved at run-time based on the current state of exe-
cution, input values, etc.).
With non-determinism, the constraints composi-
tion mechanism is much more complicated. Some
of the component services, composed via choice op-
erators, may never be invoked during an execution
instance of the composite service. As such, we
need some logic to determine if the constraints of
a component service should (or should not) be con-
sidered while specifying the constraints of the com-
posite service. For example, let us consider the e-
shopping scenario illustrated in Fig. 1. There are
two non-deterministic operators in the composition
schema: Check Credit and Delivery Mode. The
choice “Delivery Mode” indicates that the user can ei-
ther pick-up the order directly from the store or have
it shipped to his address. Given this, shipping is a
non-deterministic choice and may not be invoked dur-
ing the actual execution. As such, the question arises
“if the constraints of the shipping agent, i.e., the fact
that it can only ship to certain countries, be projected
as constraints of the composite e-shopping service (or
not)?”. Note that even component services composed
via deterministic operators (Payment and Shipping)
are not guaranteed to be invoked if they are preceded
by a choice. We consider approaches to accommodate
this inherent non-determinism in the sequel.
Paths Based Approach: Determine all the possi-
ble execution paths based on the composition schema,
and specify the constraints of the composite service
in terms of the paths. The underlying intuition is that
the component services in a path represent a group
of component services, all or none (deterministic) of
which would be invoked in an execution of the com-
posite service. The execution paths of a composition
schema given as a Directed Acyclic Graph (DAG) can
be determined based on a Depth First Search (DFS)
traversal of the DAG. Given this, the non-determinism
is reduced to the existence of more than one possible
execution path, all of which need to be represented in
the constraints specification of the composite service.
More precisely, let S
1
, S
2
, ··· , S
n
be the compo-
nent services composed by agent M to provide com-
posite service SC. By abuse of notation, we denote a
path by the set of services in the path. Then, if
{S
1
, ··· , S
i
}, ··· , {S
1
, ··· , S
j
}
are the possible execution paths,
{S
1
, ··· , S
i
} ∪ · · · ∪ {S
1
, ··· , S
j
} = {S
1
, ··· , S
n
}.
Given this, the constraints specification of SC can
be derived as follows:
1. The first two steps are similar to the determin-
istic scenario, i.e., concatenation of the compo-
nent services’ constraint specifications, followed
by appending of to all the service predicates
S
i=1···n
(Y, X
1
, ···) in the concatenated logic pro-
gram.
2. For each possible execution path {S
1
, ··· , S
j
}, add
the predicate:
S
C
(Y, X
1
, ··· , X
m
) : −
S
1
(Y, X
1
, ··· , X
k
), ··· , S
j
(Y, X
1
, ··· , X
l
),
Y = M.
where {X
1
, ··· , X
k
} ∪ · · · ∪ {X
1
, ··· , X
l
} =
{X
1
, ··· , X
m
}. Note that in contrast to the deter-
ministic scenario, here we need to add a mediator
predicate for each possible path.
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
400

Figure 1: An e-shopping scenario.
Heuristical and Incremental Approaches. We can
also decide on the set of component services whose
constraints to consider in the composite service’s con-
straints, based on some heuristics, or decide it in an
incremental fashion (at run-time) as follows:
• Optimistic: Consider the constraints of only those
component services that are guaranteed to be in-
voked in any execution of the composite service.
The set of such services (hereafter, referred to as
the strong set) can be determined by computing
all the possible execution paths and selecting ser-
vices that occur in all the paths. For example, with
reference to the e-shopping scenario in Fig. 1, the
strong set = {Browse, Order}. We call this ap-
proach optimistic as it assumes that the constraints
of the component services in the strong set are suf-
ficient to represent the constraints of the compos-
ite service.
The concept of a strong set is analogous to the
notion of strong unstable predicates (Garg and
Waldecker, 1996) or predicates that will “defi-
nitely” hold (Cooper and Marzullo, 1991) in lit-
erature. For example, strong unstable predicates
can be used to check if there was a point in the
execution of a commit protocol when all the pro-
cesses were ready to commit. Intuitively, strong
unstable predicates allow us to verify that a desir-
able state will always occur.
• Pessimistic: In this approach, we take the pes-
simistic view and consider the constraints of all
those component services that are in at least one
of the possible execution paths. We refer to such
a set of component services as the weak set. Note
that the weak set would consist of all the com-
ponent services if there are no “unreachable” ser-
vices in the composition schema. Again, with
reference to the e-shopping scenario in Fig. 1,
the weak set = {Browse, Order, Cancel Order &
Notify Customer, Arrange for Pick-up, Payment,
Shipping}. We refer to this approach as pes-
simistic as it considers the constraints of those
component services as well, that may not even be
invoked during the actual execution of the com-
posite service.
The corresponding notion in literature is weak un-
stable predicates (Garg and Waldecker, 1994) or
predicates that will “possibly” occur (Cooper and
Marzullo, 1991). For example, weak unstable
predicates can be used to verify if a distributed
mutual exclusion algorithm allows more than one
process to be in the critical region simultaneously.
Intuitively, weak unstable predicates can be used
to check if an undesirable state will ever occur.
• Probabilistic: Another option would be to con-
sider the constraints of the most frequently in-
voked component services (or the component ser-
vices in the most frequently used execution path)
as the representative set of the composite service.
Such a set can be determined statically from the
execution logs or dynamically with the help of
some mathematical model (such as, Markov Deci-
sion Processes to assign probabilities to the com-
ponent services based on previous executions.
Again, with reference to the e-shopping scenario
in Fig. 1, a probable set of most frequently used
component services might be {Browse, Order, Ar-
range for Pick-up}. While this option appears the
most attractive at first sight, developing and solv-
ing a Markovian model (Doshi et al., 2004) is non-
trivial for a complex composition schema (espe-
cially, if it involves a lot of choices).
• Incremental: Here, we propose an incremental ap-
proach to determining the set of component ser-
vices, whose constraints to consider, while con-
structing the constraints of the composite ser-
vice. Basically, rather than statically deter-
mining the constraints of the composite service,
Constraints Enabled Autonomous Agent Marketplace: Discovery and Matchmaking
401

Figure 2: Related services (based on non-invocation).
this approach advocates starting with (performing
matchmaking based on) the strong set, and keep
on adding the constraints of “related” component
services as execution progresses. We define re-
lated services as follows: For a pair of compo-
nent services S
1
̸= S
2
of composite service S
C
, S
1
and S
2
are related if and only if an invocation of
S
1
implies that S
2
will be invoked as well in the
same execution instance of S
C
. Intuitively, if a
component service S is invoked, then all the com-
ponent services till the next choice in the compo-
sition schema will be definitely invoked. For ex-
ample, with reference to the e-shopping scenario
in Fig. 1, services Payment and Shipping are re-
lated. As mentioned earlier, the execution of both
Payment and Shipping are not guaranteed. How-
ever, if Payment is invoked, then Shipping is also
guaranteed to be invoked. The above definition
of related services can also be extended to non-
invocation of component services as follows:
Related services (extended): For a pair of com-
ponent services S
1
̸= S
2
of composite service S
C
,
S
1
and S
2
are related if and only if an invocation
(non-invocation) of S
1
implies that S
2
will (not)
be invoked as well in the same execution instance
of S
C
.
Intuitively, if a component service S is not in-
voked, then all the component services till the
next merge in the composition schema will not be
invoked as well (Fig. 2). This extension is use-
ful if we consider matchmaking for more than one
composite service simultaneously (not considered
here). Given this, prior knowledge that a compo-
nent service will not be invoked during a particu-
lar execution instance allows better scheduling of
the providers among instances.
4 AGENT MATCHMAKING
4.1 Exact Match
For a user task G, matchmaking consists of finding
agents capable of executing G’s (sub-)tasks. The sub-
tasks of G might have their own constraints. Given
this, the required matchmaking for G can be achieved
with the help of a logic program execution engine
by posing (tasks of) G’s constraints as a goal against
the logic program corresponding to the service con-
straints of the respective agents. A logic program
execution engine specifies, not only if a goal can be
satisfied, but also all the possible bindings for any un-
bounded variables of the goal. In case of multiple pos-
sible bindings (multiple agents capable of executing
the same task), the agents can be ranked using some
user defined preference criteria to select the most op-
timum among them.
4.2 Approximate Match
In this section, we consider the scenario where match-
making was unsuccessful, i.e., there does not exist a
set of agents capable of executing the given task G.
Given this, it makes sense to allow some inconsis-
tency while selecting an agent. Note that inconsis-
tency is often allowed by real-life systems, e.g., flight
reservation systems allow flights to be overbooked,
but only up to a limited number of seats. Thus, the
key here is bounded inconsistency. Basically, for a
goal G = {T
1
, T
2
··· , T
n
}, the selected agent for one of
the tasks T
i
does not have to be a perfect match as long
as their accumulated inconsistency is within a speci-
fied limit. Note that the inconsistency induced by an
agent may also have a counter effect on (reduce) the
inconsistency induced by another task T
j
. For a given
goal G = {T
1
, T
2
··· , T
n
}, approximate matchmaking
can be achieved as follows:
1. Determine the common constraints: A constraint
C is common with respect to G, if more than one
task of G has constraints based on C. For example,
if tasks T
1
and T
2
need to be completed within 3
and 4 days respectively, then they have a common
time based constraint. Studies have shown that
most constraints in real-life scenarios are based on
the constraints: location, price, quantity or time.
2. For each common constraint C, define a tempo-
rary variable q
C
(to keep track of the inconsistency
with respect to C).
Initially, q
C
= 0.
3. For each task T
i
and a common constraint C: Let
vC
i
denote the constraint value of T
i
with respect
to C. For example, vTime
1
= 3 denotes the com-
pletion time constraint value of T
1
.
Delete the C constraint of T
i
from the constraints
specification of G.
4. Perform matchmaking based on the reduced goal
(with the common constraint predicates deleted in
the above step).
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
402

5. If the matchmaking was successful: [Note that if
matchmaking was unsuccessful for the reduced
goal, then it would definitely have been unsuc-
cessful for the original goal.] Let P(T
i
) denote the
agent selected to execute T
i
.
For each deleted common constraint C of T
i
(Step
3), get the best possible constraint value vBestC
i
of P(T
i
), and compute q
C
= q
C
+(vC
i
−vBestC
1
).
For example, let us assume that P(T
1
) and P(T
2
)
need at least 5 and 1 days, respectively to com-
plete their work. Given this, q
t
= 0 + (vC
1
−
vBestC
1
)+(vC
2
−vBestC
2
) = (3 −5)+ (4 −1) =
1.
6. The matchmaking results are valid if and only if
for each common constraint C, q
C
> 0. For ex-
ample, P(T
1
) and P(T
2
) are valid matches for the
tasks T
1
and T
2
respectively, as q
t
> 0.
Note that this matchmaking would not have been
possible without the (approximate) extension as P(T
1
)
violates (takes 5 days) the completion time constraint
(3 days) of T
1
. For simplicity, we have only consid-
ered numeric value based constraints in the above al-
gorithm.
5 CONCLUSION
In this paper, we focused on the discovery aspect
of Autonomous AI Agents. To execute a complex
task, a pre-requisite is a marketplace with a registry
of agents, specifying their service(s) capabilities and
constraints. We outlined a constraints based model to
specify agent services. To enable hierarchical com-
position, we showed how the constraints of a com-
posite agent service can be derived and described in a
manner consistent with respect to the constraints of its
component services. We proposed a paths based ap-
proach, as well as heuristical (optimistic, pessimistic,
probabilistic) and incremental (relative) approaches,
to accommodate the inherent non-determinism. Fi-
nally, we discussed approximate matchmaking, and
showed how the notion of bounded inconsistency can
be leveraged to discover agents more efficiently.
In future, it would be interesting to extend the
matchmaking algorithm to simultaneous discovery of
more than one user request. Doing so, leads to some
interesting issues like efficient scheduling of the avail-
able agents (touched upon briefly in Section 3.2). We
would also like to consider the top-down aspect of
constraints composition, i.e., to define the constraints
of a composite service independently and verifying
their consistency against the constraints of its corre-
sponding component services.
REFERENCES
(2000). Universal Description, Discovery, and
Integration (UDDI) Technical White Pa-
per. UDDI.org. http://www.uddi.org/pubs/
Iru UDDI Technical White Paper.pdf.
(2023). AutoGPT: the heart of the open-source
agent ecosystem. AutoGPT. https://github.com/
Significant-Gravitas/Auto-GPT.
(2023). Five Best Practices for Building an
Effective API Marketplace. MuleSoft.
https://www.mulesoft.com/api-university/
five-best-practices-building-effective-api-marketplace.
(2023). NexusGPT: World’s 1st AI-freelancer platform.
NexusGPT. https://nexus.snikpic.io/.
Bordes, A., Boureau, Y.-L., and Weston, J. (2017). Learning
end-to-end goal-oriented dialog.
Capezzuto, L., Tarapore, D., and Ramchurn, S. D. (2021).
Large-scale, dynamic and distributed coalition forma-
tion with spatial and temporal constraints. In Multi-
Agent Systems, pages 108–125. Springer International
Publishing.
Casati, F., Ilnicki, S., Jin, L., Krishnamoorthy, V., and Shan,
M.-C. (2000). Adaptive and dynamic service compo-
sition in eflow. In Advanced Information Systems En-
gineering, pages 13–31, Berlin, Heidelberg. Springer
Berlin Heidelberg.
Cooper, R. and Marzullo, K. (1991). Consistent detection
of global predicates. SIGPLAN Not., 26(12):167–174.
Doshi, P., Goodwin, R., Akkiraju, R., and Verma, K. (2004).
Dynamic workflow composition using markov deci-
sion processes. In Proceedings. IEEE International
Conference on Web Services, 2004., pages 576–582.
Garg, V. and Waldecker, B. (1994). Detection of weak
unstable predicates in distributed programs. IEEE
Transactions on Parallel and Distributed Systems,
5(3):299–307.
Garg, V. and Waldecker, B. (1996). Detection of strong
unstable predicates in distributed programs. IEEE
Transactions on Parallel and Distributed Systems,
7(12):1323–1333.
Park, J. S., O’Brien, J. C., Cai, C. J., Morris, M. R., Liang,
P., and Bernstein, M. S. (2023). Generative agents:
Interactive simulacra of human behavior.
Trabelsi, Y., Adiga, A., Kraus, S., and Ravi, S. S. (2022).
Resource allocation to agents with restrictions: Max-
imizing likelihood with minimum compromise. In
Multi-Agent Systems, pages 403–420. Springer Inter-
national Publishing.
Veit, D., M
¨
uller, J. P., Schneider, M., and Fiehn, B.
(2001). Matchmaking for autonomous agents in elec-
tronic marketplaces. In Proceedings of the Fifth In-
ternational Conference on Autonomous Agents, page
65–66. Association for Computing Machinery.
Weiss, G. (2016). Multiagent Systems, Second Edition.
Intelligent Robotics and Autonomous Agents. MIT
Press, 2nd edition.
Yan, J., Hu, D., Liao, S. S., and Wang, H. (2015). Min-
ing agents’ goals in agent-oriented business processes.
ACM Trans. Manage. Inf. Syst., 5(4).
Constraints Enabled Autonomous Agent Marketplace: Discovery and Matchmaking
403