LangGraph needs a distribution model, not just a runtime
LangGraph executes graphs well. What it can’t do is let teams share them without copy-paste, fragile cross-repo imports, or ad-hoc HTTP calls with no contract.
The result: every multi-team in the enterprise reinvents the same plumbing. Research agent, review agent, planning agent - duplicated across repos, drifting apart, impossible to version or replace independently.
The fix isn’t a new runtime. Something like a thin contract layer on top of what already exists:
CapabilitySpec: id, semver, explicit I/O schemas - nothing more
GraphCapability: wraps a builder function; attaches as a node via existing add_node
ServiceCapability: wraps RemoteGraph; same contract, different delivery
No new dependencies. No second execution engine. Pregel stays untouched. The only addition is a stable surface that lets a graph say “here’s what I consume and produce” - and let consumers depend on that instead of internal state channels.
The alternative is the ecosystem scaling by duplication. That’s already happening. This proposal just names it and gives it a seam.
Phase 1 is purely additive: one module, one spec class, one reference capability. If it’s wrong, it’s easy to remove. If it’s right, it’s the thing OSS graph libraries have been waiting for.
Together, that gives you a shareable, versionable contract (what the graph accepts/produces and how it’s wired). Implementation still lives in code (pip + langgraph.json) or behind RemoteGraph for deployed graphs , but the introspection surface is already there.
Optional add if you want one more line: for deployed graphs, the same schemas are exposed via GET /assistants/{id}/schemas (docs).
Hi @keenborder786,
Thank you for the feedback.
Your arguments are partly right, mostly incomplete for the problem I care about.
They fall short in these points:
Schemas describe a compiled graph, not a capability product. No stable capability id, semver policy, side-effect declaration, or “this is the public module; internals are not the API.” Every team still invents those norms.
get_graph() is often the wrong thing to share. Enterprises usually want less structure (black box / boundary only), not more wiring for consumers to couple to. Treating topology as part of the contract encourages exactly the dependency on internals I’m trying to avoid.
Introspection ≠ distribution. JSON schemas don’t give package entrypoints (build_*), catalog/discovery, config refs (service:foo@1), version windows, or parity between local and deployed forms. That’s still tribal + bespoke glue.
Remote and local stay two different stories. Assistant schemas help after deployment; they don’t unify “install this library capability” and “call this service capability” under one identity and version line, which is the enterprise-shaped requirement.
It optimizes for the team that already knows LangGraph deeply. Maintainers can wire this today; the gap is making reuse default, teachable, and non-forky at org scale - not proving it’s possible.
Bottom line: Treat that rebuttal as: “core primitives exist; formalize conventions, maybe thin helpers.” That’s a valid slim alternative to a big capability module.
It does not fully rebut: “enterprises need a first-class capability abstraction (contract + semver + package/service delivery + composition norms), not only schema/graph introspection.” Introspection is a necessary substrate; it is not the productization layer.
Agree schemas/RemoteGraph/pip are the substrate. Still, the missing piece is naming, versioning, boundaries, and dual delivery as one concept - even if v1 is mostly docs + thin wrappers over those APIs, not a second engine.
Internal platform libraries: Platform/agent teams publish steps like research or review as versioned capabilities; product apps compose them via package install + parent graph without copying code or depending on internal nodes/state.
Or Open-source / external graph kits: Authors ship a capability as a normal Python package (I/O schemas + builder); consumers pin semver and embed it locally, optionally mirroring the same id/contract behind a hosted service later without redesigning the API.
Services: A central team deploys a capability (tools, secrets, policy inside the service); other teams call the same contract remotely as a black box, with semver/id only - no access to implementation or shared state.
Now these use cases are not first-class citizens. You cannot see them across LangGraph, right?
A good example is the Amazon services + boto3. I want something like this.
Those two use cases aren’t first-class in LangGraph today. There’s no unified capability id, semver, or catalog that treats “pip install” and “call as service” as the same thing.
The primitives exist though:
Local libraries: versioned Python package + public build_*() + input_schema/output_schema, embed as a subgraph node
Remote services: deploy + call via RemoteGraph as a black-box node; schemas at GET /assistants/{id}/schemas
What’s missing is the distribution layer you’re describing , shared identity, discovery, config refs, and local/remote parity under one contract. That’s convention + thin wrappers today, not a built-in concept.
Yes, that’s exactly my point.
It could be implemented in thin wrappers without disturbing existing parts, as a true addition-only. Easy, simple. But it opens many doors in the enterprise world.
It is even implemented
Right now LangGraph is solid as an execution layer, but everything around reuse basically falls apart once you go beyond a single repo or a single team.
We keep hitting the same wall: graphs become “projects” instead of “components”. And once that happens, you’re back to copy-paste or these messy HTTP wrappers that nobody really treats as a contract.
The idea of a thin capability layer actually feels like the missing middle. Not another orchestration system, just a stable boundary so a graph can be referenced like an API with real inputs/outputs instead of internal wiring.
What I like about your proposal is it doesn’t try to re-architect execution at all. Pregel stays, runtime stays, nothing gets broken. It just forces a discipline on how graphs are exposed and composed.
