Problem
Webhook mappings (hooks.mappings) support action: "wake" | "agent", but there is no way to specify the target agent. All webhook-triggered agent runs always go to the default agent.
This makes it impossible to use webhooks in multi-agent setups — e.g., routing incoming emails to a dedicated "email-agent" with its own tools, workspace, and persona.
Proposed Solution
Add an optional agentId field to hooks.mappings[*]:
{
hooks: {
mappings: [
{
match: { path: "/email" },
action: "agent",
agentId: "email-handler", // <-- NEW
messageTemplate: "New email from {{from}}: {{subject}}",
deliver: true,
channel: "telegram",
to: "123456789"
}
]
}
}
Semantics
agentId optional (default: default agent)
- Must exist in
agents.list[].id
- Agent run uses workspace, tools, and model config of the target agent
- Session key is scoped under the target agent (
agent:<agentId>:hook:...)
Use Cases
- Email processing: Dedicated agent with restricted tools (no shell access, only email reply capabilities)
- GitHub webhooks: CI/CD agent with repo access, isolated from personal assistant
- Support inbox: Separate agent per webhook source with different personas/system prompts
Alternative (less elegant)
If agentId in mappings is too complex: A separate endpoint /hooks/agent/:agentId that takes the agent from the URL path.
Problem
Webhook mappings (
hooks.mappings) supportaction: "wake" | "agent", but there is no way to specify the target agent. All webhook-triggered agent runs always go to the default agent.This makes it impossible to use webhooks in multi-agent setups — e.g., routing incoming emails to a dedicated "email-agent" with its own tools, workspace, and persona.
Proposed Solution
Add an optional
agentIdfield tohooks.mappings[*]:Semantics
agentIdoptional (default: default agent)agents.list[].idagent:<agentId>:hook:...)Use Cases
Alternative (less elegant)
If
agentIdin mappings is too complex: A separate endpoint/hooks/agent/:agentIdthat takes the agent from the URL path.