Incentive Feasible Menu of Contracts

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



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   and  both  types of agent accept this contract. For those contracts, we say that there is 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 (ts ,qs) is only accepted by the efficient Then, (2.9) and (2.11) both reduce to

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.

Leave a Reply

Your email address will not be published. Required fields are marked *