### 1. Incentive Compatibility and Participation

Suppose now that the marginal cost θ is the agent’s private information and let us consider the case where the principal offers the menu of contracts {(t*, q*); (t¯*, q¯*)} hoping that an agent with type θ will select (t*, q*) and an agent with type 6 will select instead (t¯*, q¯*).

From Figure 2.3, we see that *B*^{∗} is preferred to *A*^{∗} by both types of agents. Indeed, the __θ__-agent’s isoutility curve that passes through *B*^{∗} corresponds to a posi- tive utility level instead of a zero utility level at *A*^{∗}. The θ¯-agent’s isoutility curve that passes through *A*^{∗} corresponds to a negative utility level, which is less than the zero utility level this type gets by choosing *B*^{∗}. Offering the menu (*A*^{∗},*B*^{∗}) fails to have the agents self-selecting properly within this menu. The efficient type mimics the inefficient one and selects also contract *B*^{∗}. The complete information optimal contracts can no longer be implemented under asymmetric information. We will thus say that the menu of contracts {(t*, q*); (t¯*, q¯*)} is *not incentive compatible*. This leads us to definition 2.1:

**Definition 2.1: ***A menu of contracts {*(__t ,__*q );* (

*t*¯,

*q*¯)}

*is incentive compatible when*(

__t ,__

__q)__*is weakly*

*preferred to*(

*t*¯,

*q*¯)

*by agent*

__θ__

*and*(

*t*¯,

*q*¯)

*is weakly preferred to (*

__t ,____q)__*by agent θ*¯

*.*

Mathematically, these requirements amount to the fact that the allocations must satisfy the following *incentive compatibility constraints*

* ** *

and

**Remark: **Importantly, we do not presume the existence of any com- munication between the principal and the agent. We will address the issue of communication more fully in section 2.9. Incentive compati- bility constraints should be mainly understood as constraints on final allocations, i.e., on the agent’s choices. At a general level, those con- straints are thus similar to the simple *revealed preference *arguments used in standard consumption theory.10

Furthermore, for a menu to be accepted, it must yield to each type at least his outside opportunity level. The following two *participation constraints *must be satisfied:

Together, incentive and participation constraints define a set of *incentive feasible allocations *achievable through a menu of contracts. This leads us to definition 2.2:

**Definition 2.2: ***A menu of contracts is incentive feasible if it satisfies both incentive and participation constraints (2.9) through (2.12).*

The inequalities (2.9) through (2.12) fully *characterize *the set of incentive feasible menus of contracts. The restrictions embodied in this set express additional constraints imposed on the allocation of resources by asymmetric information between the principal and the agent.

### 2. Special Cases** **

**Bunching or Pooling Contracts:**A first special case of incentive fea- sible menu of contracts is obtained when the contracts targeted for each type coincide, e., when*bunching*or*pooling*of types.

The incentive constraints are all trivially satisfied by these contracts. Incentive compatibility is thus easy to satisfy, but at the cost of an obvious loss of flexibility in allocations that are no longer dependent on the state of nature. Only the participation constraints matter now. However, the hardest participation constraint to satisfy is that of the inefficient agent since inequality (2.12) implies inequality (2.11) for a pooling contract.

**Shutdown of the Least Efficient Type:**Another particular case occurs when one of the contracts is the null contract j0p 0k and the nonzero contract (*t*,^{s}*q*) is only accepted by the efficient Then, (2.9) and (2.11) both reduce to^{s}

The incentive constraint of the bad type reduces to

If the inequality (2.14) is strict, only the efficient type accepts the contract. With such a contract, the principal gives up production if the agent is a θ¯-type. We will say that it is a *contract with shutdown *of the least efficient type.

As with the pooling contract just seen above, the benefit of the j0p 0k option is that it somewhat reduces the number of constraints since the incentive (2.9) and the participation (2.11) constraints take the same form. Of course, the cost of such a contract may be an excessive screening of types. Here, the screening of types takes the rather extreme form of excluding the least efficient type.

### 3. Monotonicity Constraints** **

Incentive compatibility constraints reduce the set of feasible allocations. Moreover, in well-behaved incentive problems these constraints put lots of structure on the set of feasible profiles of quantities. These quantities must generally satisfy a *mono- tonicity constraint *which does not exist under complete information. In our simple model, adding (2.9) and (2.10) immediately yields

Independently of the principal’s preferences, incentive compatibility alone implies that the production level requested from a θ¯-agent cannot be higher than the one requested from a __θ__-agent. We will call condition (2.15) *an implementability condition*. Any pair of outputs (__q,__*q*¯) that is *implementable*, i.e., that can be reached by an incentive compatible contract, must satisfy this condition which is here necessary and sufficient for implementability.

Indeed, suppose that (2.15) holds; it is clear that there exists transfers *t*¯ and * t *such that the incentive constraints (2.9) and (2.10) both hold. It is enough to take those transfers such that

**Remark: **In our two-type model, the conditions for implementability take a simple form. More generally, with more than two types (or with a continuum), the characterization of these conditions might get harder, as we demonstrate in appendix 3.1 and in section 3.1. The conditions for implementability are also more difficult to characterize when the agent performs several tasks on behalf of the principal (see section 2.10).

Source: Laffont Jean-Jacques, Martimort David (2002), *The Theory of Incentives: The Principal-Agent Model*, Princeton University Press.