[myalphabet]

>A good agile process will not have an ironclad upfront definition of what is to be delivered in a large project.

"what is to be delivered" does not have to be a rigid definition of "5,000 lines of code program with features 1, 2, and 3". A good agile contract will allow the possibility for changing project requirements but also still define how those changing requirements affect expectations and responsibilities of the consulting company.

The agile process itself can actually be a deliverable that you define in a contract, and it should spell out, for example, how new requirements are prioritized and the criteria you use for determining if it's something that the consulting company is responsible for. In my experience if you can't write out your agile requirements in a contract, then you don't have a good enough internal understanding of your own agile processes and should probably work on that, too.

Far too many people use "we're Agile" as an excuse for "we don't plan or document anything" and extend that to contracts, but that's absolutely not what good Agile actually is.