Service Level Agreements (SLAs) provide a contract between an application user making demands on resources, and application providers determining what should be made available for external use. To enable resource sharing in multi-application environments, SLAs may be used to define: (i) requirements that such an application would place on resources (and services) owned by a third party; (ii) check whether these requirements have been met during use. An SLA must also encode some policy that specifies the penalty that a service provider may incur if terms in the SLA are violated. Currently, SLAs are defined in a static manner, i.e. the terms within an SLA must adhere to strict constraints, and monitored during application execution -- such as in WS-Agreement. However, within many scientific computing applications, it is often difficult to define such constraints very precisely -- thereby leading to a large number of violations. The need to modify an agreement that had already been established especially if the agreement is used at a time much later than when the agreement had been defined is necessary. These requirements relates to comparing the cost of re-establishing a new agreement vs. being able to adapt an agreement that is already in place. Secondly, there is a need to support flexibility in the agreement if an agreement initiator is not fully aware of the operating environment when the agreement is defined. In this case, the agreement initiator may not have enough information to determine what to ask for from a provider. This is likely to be the case when an agreement initiator or provider operates with imprecise knowledge about the other party involved in the agreement. This talk will describe the need for such dynamic SLAs and identify possible mechanisms that may be used to define and manage them. Changes needed to WS-Agreement to develop such dynamic SLAs will also be discussed.