Algorithms and keys sizes change over time as technology advances
 e.g. from DES (to 2TDEA to 3TDEA) to AES.
 e.g. from RSA to ECC to future Quantumresistant cryptography
 e.g. from MD5 to SHA1 to SHA2 to SHA3
If this change is not accounted for when designing a system, it can prevent future proofing, and make the transition and maintenance
 more painful i.e. more effort
 slower  i.e. increase exposure window
This page gives
 a definition of crypto agility.
 guidelines for crypto agility.
 a simple practical example for crypto agility.
Definition
Cryptographic Agility can be described as three properties, in order of priority:
 Users can choose which cryptographic primitives (such as encryption algorithm, hashfunction, keyexchange scheme etc.) are used in a given protocol
 Users can replace the implementation of an existing cryptographic primitive, with one of their choosing
 Users can set systemwide policy on choice of default algorithms
Per RFC7696, Cryptographic Agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time.
 For the protocol implementer, this means that implementations should be modular to easily accommodate the insertion of new algorithms or suites of algorithms. Ideally, implementations will also provide a way to measure when deployed implementations have shifted away from the old algorithms and to the better ones.
 For the protocol designer, algorithm agility means that one or more algorithm or suite identifiers must be supported, the set of mandatorytoimplement algorithms will change over time, and an IANA registry of algorithm identifiers will be needed.
This is really just standard good software design practice i.e. loose coupling as part of loosecoupling, highcohesion.
Examples of Cryptographic Algorithm Agility
The following well known protocol examples dynamically allow the algorithm to change while still allowing interoperability:
 TLS, IPSEC for communication
 CMS for data encapsulation
Protocol Agility
The above defintion of Cryptographic Agility is focused on Algorithm Agility. However, protocols themselves evolve over time and this changed must be supported also.
This is typically done by
 upgrading the protocol implementation (i.e. software version) that supports the later protocol version
 support the older protocol for an interim transition period
 deprecate support for the older protocol when ready
Guidelines for being Crypto Agile

Use higher level crypto interfaces i.e. standard protocols, else schemes that support "cipher suites"  don't call raw crypto primitives
 where a "cipher suite" is a set of predefined configurations for algorithm and key size and parameter size e.g. as used in TLS, or CMS.
 Avoid creating your own crypto algorithms, formats, solutions. Conform to crypto standards  making it easier to transition to a different solution.
 use identifiers and versions for crypto algorithms, messages, formats https://tools.ietf.org/html/drafthousleycryptoalgagility00 i.e. from the payload alone it should be possible to uniquely identify what crypto was used to process that payload

useaconservativeminimumtrustedsetofprimitivesandschemes
 supporting too many leads to higher probability that one will need to change
 supporting only one increases the impact if change required

Use a modular approach to security building blocks / services
 i.e. loosecoupling, highcohesion.

Walk  don't run
 i.e. do a selfassessment and come up with a longterm plan for cryptoagility and quantumresistance that fits with overall product roadmap
Example
Taking the example code from the book Network Security with OpenSSL: source code here:
This program PKCS#7 encrypts input from the command line, with the certificate specified on the command line, to create an output EnvelopedData type. The same program can do the corresponding EnvelopedData decryption.
Using PKCS#7/CMS per guidelines makes it easier to change the asymmetric or symmetic algorithm involved with encrypting the input data. The resulting Content Type is selfdescribing i.e. it says what asymmetric or symmetic algorithms were used to encrypt the data.
/* choose cipher and read in all certificates as encryption targets */
cipher = EVP_des_ede3_cbc ();
certs = sk_X509_new_null ();
....
if (!(pkcs7 = PKCS7_encrypt (certs, in, cipher, 0)))
NOTE: CMSencrypt() should be used instead of PKCS7encrypt() to support ECC.
Asymmetric Encryption
For the executable, there is no change in usage between RSA and ECC encryption/decryption (just the certificate passed in is different); Openssl PKCS#7/CMS routines know if asymmetric algorithm (RSA or ECC) should be used based on the certificate passed in to do the encryption/decryption.
ECC encrytion
echo SECRET  ./ed encrypt E_ECC.crt.pem > enc.txt
ECC decryption
cat enc.txt  ./ed decrypt E_ECC.pem E_ECC.crt.pem
RSA encryption
echo SECRET  ./ed encrypt E_RSA.crt.pem > enc.txt
RSA decryption
cat enc.txt  ./ed decrypt E_RSA.pem E_RSA.crt.pem
Symmetric Encryption
In the source code, the symmetric algorithm used is hardcoded in the source code instead of being passed in as a parameter to the program.
But even so, the PKCS#7/CMS EnvelopedData type created will indicate what symmetric algorithm was used. The receiver can identify and automatically change the symmetric algorithm used to decrypt the data.
PKCS7 / CMS EnvelopedData Type
The process by which enveloped data is constructed involves the following steps:
 A contentencryption key for a particular contentencryption algorithm is generated at random.
 For each recipient, the contentencryption key is encrypted with the recipient's public key.
 For each recipient, the encrypted contentencryption key and other recipientspecific information are collected into a RecipientInfo value.
 The content is encrypted with the contentencryption key.
 The RecipientInfo values for all the recipients are collected together with the encrypted content into a EnvelopedData value.
A recipient opens the envelope by decrypting one of the encrypted contentencryption keys with the recipient's private key and decrypting the encrypted content with the recovered contentencryption key.
The fields of type EnvelopedData have the following meanings:
 version is the syntax version number.
 recipientInfos is a collection of perrecipient information. There must be at least one element in the collection.
 encryptedContentInfo is the encrypted content information.
The fields of type EncryptedContentInfo have the following meanings:
 contentType indicates the type of content.
 contentEncryptionAlgorithm identifies the contentencryption algorithm (and any associated parameters) under which the content is encrypted. This algorithm is the same for all recipients.
 encryptedContent is the result of encrypting the content.
The fields of type RecipientInfo have the following meanings:
 version is the syntax version number.
 issuerAndSerialNumber specifies the recipient's certificate (and thereby the recipient's distinguished name and public key) by issuer distinguished name and issuerspecific serial number.
 keyEncryptionAlgorithm identifies the keyencryption algorithm (and any associated parameters) under which the contentencryption key is encrypted with the recipient's public key.
 encryptedKey is the result of encrypting the contentencryption key with the recipient's public key.
PostQuantum Cryptography
NIST Report on PostQuantum Cryptography emphasizes the real need for Crypto Agility where asymmetic algorithms especially will be replaced by quantumresistant alternatives  which have not been determined yet:
 "As the replacements for currently standardized public key algorithms are not yet ready, a focus on maintaining crypto agility is imperative."
 "The report also recognizes the challenge of moving to new cryptographic infrastructures and therefore emphasizes the need for
agencies to focus on crypto agility."
NIST Special Publication 800131A Revision 2 Transitioning the Use of Cryptographic Algorithms and Key Lengths
 "NIST encourages implementers to plan for cryptographic agility to facilitate transitions to quantumresistant algorithms where needed
in the future"
References
 Guidelines for Cryptographic Algorithm Agility and Selecting MandatorytoImplement Algorithms RFC 7696 Nov 2015
 https://media.blackhat.com/bhus10/whitepapers/Sullivan/BlackHatUSA2010SullivanCryptographicAgilitywp.pdf
 https://randomoracle.wordpress.com/2014/11/09/thechallengeofcryptographicagility/
 FORUM ON Cyber Resilience WORKSHOP SERIES Cryptographic Agility and Interoperability Proceedings of a Workshop
 NIST Report on PostQuantum Cryptography
 NIST Special Publication 800131A Revision 2 Transitioning the Use of Cryptographic Algorithms and Key Lengths