Built-in platform actions and LLM-native tools available to every agent
Default functions are pre-built actions provided by SubVerse AI and the underlying LLM provider. They are always available to the LLM during an active session — no webhook or custom code required. Simply enable the ones you need and instruct the agent when to use them.
Default functions cover the most common actions an agent needs during a session. You do not need to create or configure them — just enable the ones relevant to your use case and instruct the agent in its system prompt when to call them.Common patterns:
End the session automatically once the user’s query is resolved.
Search the web when the agent needs real-time or external information.
Store customer preferences in memory to personalise future sessions.
Query the knowledge base for product details or policy documents.
Be explicit in the agent’s system prompt about when to call each function. For example: “When the customer says goodbye or their issue is resolved, call end_session.” or “Use web_search only when the knowledge base does not contain a definitive answer.”
fetch_memory is a pre-session function that retrieves previously stored memory and injects it into the agent’s context before the conversation begins. The retrieved memory is placed into a dynamic variable that you define, which you can then reference anywhere in the agent’s system prompt.
When a session starts, fetch_memory looks up the memory stored under the given memoryId and makes it available as a dynamic variable named by paramName. From that point on, you can reference the memory in your system prompt using the standard double-curly-brace syntax — {{ paramName }}.
ID of the memory to retrieve. Accepts dynamic variables — use a session variable like {{ claimId }} or a nested tool body field like {{ body.userDetails.id }}.
paramName
string
Yes
Name of the dynamic variable the retrieved memory will be injected into.
memoryId supports both top-level session variables ({{ claimId }}) and nested tool body paths ({{ body.userDetails.id }}). This makes it straightforward to scope memory to the specific customer or entity being passed in the request payload — no extra configuration needed.
// Tool paramsmemoryId: {{ claimId }}paramName: claimMemory// Tool response{ "dynamicVariables": { "claimMemory": "Previous conversation memory for this claim..." }}// System prompt usageHere is the previous claim memory which you can refer to if needed: {{ claimMemory }}
Memory is shared across all agents and customers in your workspace. Always use a customer-specific memoryId — such as the customer’s user ID or claim ID — to prevent one customer’s memory from being accessible to another.
If no memory exists for the given memoryId, the dynamic variable returns null. Handle this gracefully in your system prompt — for example: “If {{ claimMemory }} is empty, treat this as a new customer with no prior history.”
update_memory is a post-session function that extracts key information from the conversation and saves it under a given memoryId. If memory already exists at that ID, the function merges the new conversation with the prior memory to produce an updated record — nothing is lost.
After the session ends, the LLM reads the full conversation alongside your prompt instructions, extracts the relevant information, and writes it to the memoryId. If existing memory is found at that ID, it is combined with the new extraction so the stored record stays cumulative across sessions.
// Tool paramsmemoryId: {{ claimId }}prompt: Store what has been discussed for this claim with dates and issues
Be specific in your prompt. A vague instruction like “summarise the conversation” produces vague memory that is less useful on retrieval. Instead, describe exactly what to capture — dates, decisions, open issues, customer preferences — so the stored memory is immediately actionable next session.
