Skip to content

router: add pluggable networking providers#85

Closed
John Howard (howardjohn) wants to merge 1 commit into
agent-substrate:mainfrom
howardjohn:router/pluggable-networking
Closed

router: add pluggable networking providers#85
John Howard (howardjohn) wants to merge 1 commit into
agent-substrate:mainfrom
howardjohn:router/pluggable-networking

Conversation

@howardjohn

Copy link
Copy Markdown
Collaborator

This PR extends the router to support pluggable network providers rather than a hardcoded Envoy. Envoy remains the default with no changes.

As we build out the feature set of substrate, we will have an expanded set of requirements on networking. For example, #15 (comment) expresses a need to inject credentials and a desire to be able to plug in the proxy of your choice. IMO this is very important: there are a number of projects coming up in this space specializing in the needs of agentic traffic that make sense to plug in here.

  • Tests pass
  • Appropriate changes to documentation are included in the PR

@bowei Bowei Du (bowei) self-requested a review May 26, 2026 20:04
@bowei Bowei Du (bowei) self-assigned this May 27, 2026
@bowei

Copy link
Copy Markdown
Collaborator

Question: if the AgentGateway doesn't use XDS, you might get broken if some logic gets pushed into the XDS configuration? The XDS is minimal right now, but will highly likely change.

That being said, Envoy should be an implementation detail and I think it makes sense to make this pluggable.

Also, it would be good to use package boundaries to delineate the providers if possible.

@howardjohn

Copy link
Copy Markdown
Collaborator Author

Question: if the AgentGateway doesn't use XDS, you might get broken if some logic gets pushed into the XDS configuration? The XDS is minimal right now, but will highly likely change.

One note on this - agentgateway does support dynamic configuration via the XDS gRPC APIs it just has different types sent over that service (so cannot use the existing xDS server which sends Envoy-specific Listeners/Clusters/etc).
I kept it as a static file today since there is nothing dynamic but if we need to we can easily move it over to being dynamic.

@bowei

Copy link
Copy Markdown
Collaborator

Sorry for the late reply.

I think at this point in the project, it will be hard to maintain two separate implementations of routing logic in tree -- it's highly likely that the configuration will evolve quite a bit in the early stages of this project. I just think it's going to be difficult pre-alpha/beta to consolidate on any real contracts here as of yet.

It probably makes the most sense to add an option to disable reconciliation of the envoy and only run the ext_proc plugin. We keep the K8s Service and you can use the Deployment with the same labels in your custom implementation of the router.

@bowei

Copy link
Copy Markdown
Collaborator

Hi John Howard (@howardjohn) -- looks like there are further discussions that have elaborated on this (see #393). Do we want to keep going on this or close this?

@howardjohn

Copy link
Copy Markdown
Collaborator Author

yeah I think we can replace with 393

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants