One provider can have many execution transports¶

October 4, 2026 · Kishore Babu Gutta

A useful architecture shift happened while building the GitHub provider.

GitHub is not "a REST integration."

It is not "a GraphQL integration."

It is not "a gh CLI integration."

GitHub is the provider.

REST, GraphQL and gh are different transports that can reach it.

Provider first, transport second¶

Intent
  ↓
GitHub provider
  ├─ REST
  ├─ GraphQL
  └─ CLI

Different operations may naturally fit different transports.

The caller should not need to redesign its intent around that fact.

That leads to a useful principle:

Transport is an execution decision, not the user's product model.

The same idea generalises to cloud and infrastructure providers.

A provider may expose APIs, CLIs, SDKs, files, protocols or MCP servers over time.

Engineering Runtime can preserve a stable intent layer while adding those execution paths underneath it.

Hiding transports completely would also be a mistake.

Transport affects:

So the Runtime can choose or compile an operation while still reporting which transport performed it.

That gives users abstraction without losing evidence.

Intent
  ↓
Provider operation
  ↓
Runtime controls
  ↓
Selected transport
  ↓
Provider system

This is the basis of Engineering Runtime's Provider Multi-Transport Model.