How the Functions Skill Works
The Functions Skill connects conversational AI with backend execution. With configured endpoints, access, permissions, and tests, agents can retrieve CRM data, book appointments, trigger actions in other software, or query databases in response to user requests.
Instead of just answering questions from static vector store knowledge, an agent with the required function configured and tested can recognize when a request requires external data or action. If a user asks "Can you check the status of my order?", the agent:
- Detects the intent (order status check)
- Extracts the parameters (order number from the conversation)
- Calls the
get_order_statusfunction via a webhook - Returns the live result in natural language
Configuring a Function
In the Skills tab of the Launch Pad, toggle the Functions Skill to Active and click Create Function. Define each of the following fields:
| Field | Description | Example |
|---|---|---|
| Function Name | A clear, user-friendly label | Check Order Status |
| Internal Name | A unique system identifier used in code | get_order_status |
| Status | Private (this agent only) or Shared (organization-wide Functions Library) | Private |
| Instructions | A prompt telling the AI exactly when and how to use this function. Critical for accurate intent detection. | "Trigger this function when the user asks about the status of their order and provides an order number." |
| Webhook to Call | The external HTTP endpoint (URL) the AI will contact | https://api.yourcompany.com/orders/status |
| Parameters | The data inputs the AI collects from the user | order_id (string, required), email (string, optional) |
| Headers | Only the authentication headers the destination API requires (endpoint-dependent) | Authorization: Bearer YOUR_API_KEY |
1 · Name the function. Choose an approved template in Chose function from a template, or enter Function Name and a no-space Function Internal Name, such as Check Order Status and get_order_status.
- Highlight 1: Chose function from a template
- Highlight 2: Function Name
- Highlight 3: Function Internal Name
2 · Define the request. Write Function Instructions, enter an owner-approved test Webhook to Call, and select HTTP Method. With GET, parameters are sent in the URL; do not include sensitive data.
- Highlight 1: Function Instructions
- Highlight 2: Webhook to Call
3 · Define inputs and review. Enter Function Parameters as a JSON Schema. Use Header Name and Header Value with + Add Header only when your test server requires them. Review the placeholder configuration before Create or Update, then reopen it to check the settings. Test only against an approved read-only endpoint.
- Highlight 1: Function Parameters
- Highlight 2: + Add Header
- Highlight 3: Create
Agent-to-Agent (A2A) Routing: A Custom Pattern
A common design pattern for the Functions Skill is Agent-to-Agent routing. A primary agent (a general customer service bot) can route specialized queries through a custom function to an endpoint that consults a secondary expert agent (billing, technical support) and returns the answer. This is a pattern you build, not a verified built-in endpoint, schema or authentication contract. A dedicated Agent-to-Agent setup is not shown in the reviewed Skills menu; see Agent-to-Agent Connection and check with raia which approach is available for your workspace.
Designing an A2A function:
- Webhook URL: Use the destination endpoint defined by an owner-approved contract. Older material showed
https://raia.app.n8n.cloud/webhook/...; that is a nonstandard, unverified legacy illustration, not a working raia URL. Never send credentials there. - Parameters: Use the inputs the approved contract defines. A single
queryparameter (type: string) carrying the user's question is one illustrative shape, not a required schema. - Headers: Add only the headers the approved destination API requires. Older material named
Call_Agent_APIKEY; treat it as a nonstandard, unverified legacy example, not a raia standard.
In this illustrative design, when the primary agent meets a question outside its domain, its instructions can lead it to call this function, passing the query parameter to the destination endpoint. How that endpoint authenticates, which agent it consults and what it returns are defined by its approved contract; test it against an approved read-only fixture.
Best Practices
- Write clear instructions: Function Instructions guide when to trigger the webhook alongside the model, configuration, and available tools; permissions and server-side checks control access. Be explicit — e.g., "Trigger this function ONLY when the user explicitly asks to cancel their subscription and provides an account ID."
- Define strict parameters: Use clear parameter names and mark required vs optional. Do not assume the AI will always ask for a missing required input: test missing and malformed parameters against an approved read-only fixture, and validate inputs on the server.
- Use the Logs tab: If a function isn't firing correctly, inspect the recorded request, response and errors where Logs or Debug are available to you. What is recorded can vary, so check what your view actually shows rather than assuming an exact payload.
Debugging Tip: If a function isn't triggering, a common place to start is the Function Instructions field: make the trigger conditions explicit. Also check that the function is active, its parameters, and any recorded errors.