|
|
|
|
|
by jacobheric
40 days ago
|
|
It's provisioning expressed as an API, but wrapped in a cli that agents can very easily use. Then anyone that implements the API is added to a marketplace of services. And the ability to pay for service is baked in because it's stripe. The end result is that as an engineer I can ask an agent to use the stripe cli to discover and provision, including paying for, a wide variety of services and it mostly just works. |
|
In theory, this is a cool idea, but in practice I think this being done through a proprietary, locked-in Stripe product, is going to ultimately hinder adoption.
The security implications here are also concerning - from what I can tell - Stripe seems to have access to all of the keys/credentials for third party accounts/resources provisioned via Stripe Projects.
So stripe has centralized control over payments, KYC, credentials/keys (full lifecycle, not just storage), the provider marketplace, and even over the availability/reliability of anything built with on top of Stripe Projects (since now your credential/key lifecycle has Stripe on the hot path).
This is like a more janky/less reliable loveable, without the handrails, and with a mere illusion of less lock-in.
Imo, this kind of thing will only work long-term as an open protocol without Stripe lock-in, and I know certain people/companies are already working in this direction.