Is your feature request related to a problem? Please describe.
When using a VoltAgent instance, dynamic agents allow model and tools to be functions that receive context, but they do not have direct access to the underlying HTTP request headers. This forces us to create a manual proxy layer that reads headers (e.g., auth tokens, tenant IDs, custom headers) and copies them into request.body.options.context so that:
model: ({ context }) => ... tools: ({ context }) => ...
can see them.
Ideally, there would be a way to access request‑level headers (or some headers object) at the same scope as context during model and tool construction, so we don’t need to rewire every request through an ad‑hoc proxy.
Use case:
- 3rd‑party services call our VoltAgent endpoints and pass auth / custom headers.
- Those headers are required to configure internal model providers and tools (e.g., X‑Tenant‑ID, Authorization, X‑User‑ID).
Describe alternatives you've considered
I’ve tried using the configureApp property exposed within honoServer, but it doesn’t seem to execute the passed‑in middlewares on the agent routes, since those routes are added before any custom app.use calls are defined in configureApp.
As a workaround, I used configureFullApp, but that required me to explicitly pass in all the routes and middlewares needed for the VoltAgent instance to function, which is quite verbose:
new VoltAgent({
agents: { agent },
server: honoServer({
configureFullApp: ({ app, routes, middlewares }) => {
middlewares.cors();
middlewares.auth();
middlewares.landingPage();
app.use("*", headerToContext);
routes.agents();
routes.workflows();
routes.tools();
routes.logs();
routes.updates();
routes.observability();
routes.memory();
routes.triggers();
routes.mcp();
routes.a2a();
routes.ui();
routes.doc();
}
}),
logger,
});
Additional context
No response
Describe the thing to improve
We’d prefer a first‑class mechanism such as a headers parameter alongside context in model / tools, or a way to expose headers to the dynamic agent function without header‑to‑context transformation in the HTTP layer.
Is your feature request related to a problem? Please describe.
When using a VoltAgent instance, dynamic agents allow
modelandtoolsto be functions that receivecontext, but they do not have direct access to the underlying HTTP request headers. This forces us to create a manual proxy layer that reads headers (e.g., auth tokens, tenant IDs, custom headers) and copies them intorequest.body.options.contextso that:model: ({ context }) => ...tools: ({ context }) => ...can see them.
Ideally, there would be a way to access request‑level headers (or some
headersobject) at the same scope ascontextduring model and tool construction, so we don’t need to rewire every request through an ad‑hoc proxy.Use case:
Describe alternatives you've considered
I’ve tried using the
configureAppproperty exposed withinhonoServer, but it doesn’t seem to execute the passed‑in middlewares on the agent routes, since those routes are added before any customapp.usecalls are defined inconfigureApp.As a workaround, I used
configureFullApp, but that required me to explicitly pass in all the routes and middlewares needed for the VoltAgent instance to function, which is quite verbose:Additional context
No response
Describe the thing to improve
We’d prefer a first‑class mechanism such as a
headersparameter alongsidecontextinmodel / tools, or a way to expose headers to the dynamic agent function without header‑to‑context transformation in the HTTP layer.