AI-Powered Webhook Agent Workflow
n8nAI agentsRoute GET and POST webhook requests, retrieve document context, and connect an AI agent to an HTTP output.
- Platform
- n8n
- Focus
- AI agents
- Evidence available
- Original screenshot
Project overview
A webhook-based n8n agent combines an explicit response path with a document-backed AI-processing path. The screenshot shows the connected model and memory components without exposing request configuration or the destination service.
Business problem
An incoming request may need to be checked, enriched with reference information and passed to an AI step before a response or downstream request is produced. The exact business channel has not been established.
Automation solution
Use the Webhook node’s separate GET and POST outputs: GET connects through If to Respond to Webhook; POST connects through a Filter and Google Docs retrieval to an AI Agent and HTTP Request.
Simplified process summary. Explore the architecture below for branches and decision logic.
Workflow evidence
Original image, preserved in full. Enlarge and zoom to read individual nodes.
Workflow architecture
Trigger & input
The Webhook node exposes visible GET and POST outputs. GET goes to If and Respond to Webhook; POST goes to Filter and the AI-processing path. Authentication, payloads and response settings are not shown.
Processing & output
- GET requests enter an If node. Its true output connects to Respond to Webhook; the false output is visibly unconnected.
- POST requests enter a Filter, whose Kept output connects to Google Docs Get a document.
- The document action connects to AI Agent, with OpenRouter Chat Model attached to the model input and Simple Memory attached to memory.
- The Agent’s Tool input has no connected tool visible. Its main output connects to HTTP Request; the endpoint and request body are not exposed.
Conditional logic
GET and POST take distinct paths. The GET If condition and POST Filter rules are hidden. No connected agent tool is visible, so additional tool-use capabilities cannot be claimed.
Key features
- Separate GET response and POST processing paths
- Conditional webhook response
- Filtered document retrieval
- OpenRouter-backed AI agent with Simple Memory
- HTTP request after the AI step
Technical challenges
The canvas demonstrates separation of request types, model context and memory. The screenshot does not show session-key rules, webhook validation, prompt configuration, output mapping or downstream HTTP error recovery. These are verification needs, not documented problems already solved.
Business value
Intended to connect inbound requests with reference content and AI-assisted processing. The original filename references an FB agent, but the visible canvas does not identify Facebook or Messenger as the HTTP destination.
Project status
Testing & limitations
Test execution shown
Green markers and item counts are visible on the POST/document/agent/HTTP path. The GET response path has no equivalent completion markers in this capture. The screenshot does not independently verify response correctness or production deployment.
Source: Kyle’s original workflow screenshot and project brief. The visible canvas has been reviewed; exported configuration, output contents and production run history have not been independently verified.
Limitations & next steps
What needs verification: resolve these open questions before treating this design as a verified implementation.
- Business channel and downstream HTTP destination
- GET condition, POST filter and webhook authentication
- Document content, agent prompt/model and memory session configuration
- Request/response payloads, unconnected false-path handling and production run history