Unlike the traditional model of information pull, Matchmaking is based on a co-operative partnership between information providers and consumers, assisted by an intelligent facilitator (the matchmaker). Information providers and consumers update the matchmaker (or network of matchmakers) with their needs and capabilities. The matchmaker, in turn, notifies consumers or producers of promising "partners". Matchmaking is an automated process depending on machine-readable communication among the consumers, providers, and the matchmakers. Thus, communication must occur via rich, formal knowledge sharing languages [1].
The main advantage of this approach is that the providers and consumers can continuously issue and retract information needs and capabilities, so information does not tend to become stale and the flow of information is flexible and dynamic. This is particularly critical in situations where sources and information change rapidly.

There are two distinct levels of communication with a matchmaker: the message type (sometimes called the speech act) and the content. The former denotes the intent of the message (e.g., query or assertion) while the latter denotes the information being exchanged (e.g., what information is being queried or asserted).
There is a variety of message types. For example, information providers can take an active role in finding specific consumers by advertising their information capabilities to a matchmaker. Conversely, consumers send requests for desired information to the matchmaker. As variations on this general theme, the consumer might simply ask the matchmaker to recommend a provider that can likely satisfy the request. The actual queries then take place directly between the provider and consumer. The consumer might ask the matchmaker to forward the request to a capable provider with the stipulation that subsequent replies are to be sent directly to the consumer. Or, the consumer might ask the matchmaker to act as an intermediary, forwarding the request to the producer and forwarding the reply to the consumer. [2]

Since the content of requests and advertisements may not align perfectly, satisfying a request might involve aggregating or abstracting the information to produce an appropriate result. For example, if a source advertises information about automobiles while a consumer requests information about Fords, some knowledge and inference is required to deduce that a Ford is an automobile. Such transformation of data is an important capability, but its addition to a matchmaker must be carefully weighed. If knowledge about automobiles were added to a matchmaker, similar knowledge could be added about every other possible topic. Obviously, this would quickly lead to an impractically large matchmaker. Therefore, a matchmaker as such does not strictly contain any domain knowledge. However, a matchmaker is free to use other mediators and data sources in determining partners. Thus, it could farm out the automobile/Ford example to an automobile knowledge base to determine if a match exists.

To evaluate and test the matchmaking approach, two prototype matchmakers have been built. The first matchmaker was designed and prototyped as part of the SHADE system, a testbed for integrating heterogeneous tools in large-scale engineering projects. It operates over formal, logic-based representations, and is designed to support many different types of requests and advertisements.
A second matchmaker was created as an element of the COINS system (Common Interest Seeker). The emphasis of this matchmaker is on matching free text rather than formal representations.

Both matchmakers run as processes accepting and responding to advertisements and requests from other processes. Communication occurs via KQML, which defines specific message types (historically known as performatives) and semantics for advertising and requesting information. KQML message types include simple queries and assertions (e.g., ask, stream, and tell), routing and flow instructions (e.g., forward and broadcast), persistent queries (e.g., subscribe and monitor), and information brokering requests (e.g., advertise, recommend, recruit, and broker), which allow information consumers to ask a facilitator (Matchmaker) to find relevant information producers.

These two types of matchmakers were developed separately due to the differences between their content languages (logic vs. free text), and the resulting radical impact on the matching algorithms. They could, in principle, be integrated, but just as a matchmaker uses other agents for domain-specific inference, it is preferable to keep them separated, rather than creating one huge matchmaker. If desired, a single multi-language matchmaker may be implemented via a simple dispatching agent that farms out requests to the appropriate matchmaker. This approach allows many matchmakers, each created by researchers with specific technical expertise, to be specialised for specific classes of languages.

Experiments with matchmakers have shown matchmaking to be most useful in two different ways:

	1.	Locating information sources or services that appear dynamically; and
	2.	Notification of information changes.

A third benefit, that of allowing producers of information to actively seek potential consumers, has only been partially demonstrated. Nevertheless, provided that user (but also producer) privacy can be guaranteed, this capability can attract the attention of many information providers. [3]
Yet, even though matchmaking has proven very useful in the above applications, several important shortcomings have been uncovered. Whereas queries can be expressed succinctly, expressing the content of a knowledge base (as in an advertisement) is a much harder problem. Current formal content languages are adequate for the simple examples shown above, but to go beyond advertising simple attributes quickly strains what can be represented. Additional research is required on ever more powerful content languages. The COINS matchmaker is, of course, not limited by representation. Here, the efficiency and efficacy of free-text matching becomes a limiting factor.

It should be noted that Matchmaking is a special type of middle layer application as it does not use any domain-specific knowledge. It also is not an agent application really: it farms out tasks/queries to specialised, or otherwise most suitable agents for that specific problem (i.e. query). Matchmakers could, however, play an important role as a sort of universal interface to the middle layer for both user as well as supplier agents or agent applications as they do not have to figure out which middle layer agents are best to be contacted.