Thanks for the responses Mike. See inline:

To be clear, I think we're happy to test third-party agent in our CI

pipelines to ensure they'll continue to work. I think this addresses your
"breaking change" point in a very sustainable way.

Adding thirdparty agents to the CI pipeline will help. But, if there is
ever a breaking change in a buildpack we now have a loose dependency on the
thirdparty broker being upgraded before I can potentially upgrade to a new
cf-release. It is that kind of loose dependency breakage that I'm more
concerned about.

I'd like to explore whether we can meet agent requirements with profile.d
and/or buildpack lifecycle hooks. If we find a compelling blocker, we can
revisit this and related decisions. Hopefully we can convince you as well
as agent vendors that this is a reasonable path forward.

Perhaps the buildpack lifecycle hooks you mention will be good enough of an
api. Do you have anything describing the makeup of these hooks?

* Integration customization:

One of the nice things about buildpacks is the very clear customization
path. We use app dynamics and we have custom requirements for how app
dynamics should be configured that app dynamics won't want to support.
What would the story be for customizing the app dynamics broker's code that
gets injected? It would be nice if there were a simple and consistent
mechanism in place similar to what buildpacks already provide.

This isn't a use case we considered. Can you help me understand what kinds
of customizations you're making? Specifics will help drive this
conversation.

Here is our use case. App Dynamics designates an application with a
location in its UI using an App Name, Tier Name, and Node Name. Our
organization has placed specific standard naming conventions around what
specifically the App Name and Tier Name should be. My organization also
uses ServiceNow for CI management. The App Dynamics naming standard is to
use specific field in the application's CI for App Name and Tier Name. We
only allow applications to use app dynamics if they have a service now
service bound and we configure their App Name and Tier Name with values
from the service now service's credentials. That is an example.

If you think other use cases should be prioritized, then maybe we can have

that conversation with Danny.

I wasn't suggesting that you move focus off of this problem area and
towards something else. I was just pointing out that there may be an
opportunity here to kill 2 birds with one stone if we look a little
broader, since the problem appears similar to me.

You guys are the experts but let me brain storm a little here to perhaps
help the discussion along. This proposal already introduces the new
concept of some kind of "buildpack hook" contract. What if you made it
possible for users to specify buildpack hooks an needs in addition to the
buildpack as part of the application model? (Lowest common denominator this
could be an Environment Variable) Then also allow service brokers to
supply the same type of hook via VCAP_SERVICES (as this proposal
proposes). It would be nice if broker hooks could be overridden by
application configured hooks to cover odd use cases. Thoughts?

Agent components may not be open-source (or OSS-compatible with APL2.0),

and may not be licensed for general redistribution by Foundation vendors.
We'd like to enable those companies to participate in the CF ecosystem.

I agree this is an issue. Does the binary redistribution aspect of the
proposal cover this concern? Or are there also legal issues with code that
might go into a buildpack to configure these non ASL compatible agents?

Thanks for taking the time to work this through with me.

Mike