When developer Dax Raad tweeted about the mess of infrastructure management in March, over fifty thousand developers felt seen. Every service has its own CLI, its own config format, and they don't play nice with tools like Terraform anymore. Matthew Clevenger, a Staff Software Engineer at Stripe, saw that frustration and released OpenBindings, a specification that takes a different approach. Instead of building another abstraction layer on top, it creates a standard underneath.
The core idea is simple. An OpenBindings Interface (OBI) separates what a service can do from how you talk to it. You define operations once, then bind them to whatever protocols the provider uses. REST, gRPC, GraphQL, MCP, CLI. Two providers can implement the same interface, and a tool can verify they're compatible without making a single request. Services publish their OBI at /.well-known/openbindings, the same convention websites use for index.html. Tools discover it and start interacting, no hard-coded knowledge required.
This matters for Agent Skills. Right now, LLMs read documentation, guess at endpoints, and infer what operations mean. That works, but it's just brute force at higher speed. An LLM that finds an OBI gets machine-readable operations, schemas, and bindings. It doesn't have to guess. The specification includes an ob CLI for converting existing specs like OpenAPI or Protocol Buffers into OBIs, plus SDKs in Go and TypeScript. The project sits at version 0.1.0.
Clevenger compares the approach to Go's structural interfaces: you code to the shape, not the implementation. That inversion means new providers can show up without changing anything upstream. Whether OpenBindings gets adoption is the real question. The spec needs providers willing to publish OBIs. But the framing is right. Abstraction layers keep breaking because they chase APIs that constantly change. A shared language for describing what services do, independent of how they're accessed, addresses the actual problem.