Pre-Query Custom Endpoint Call and Placeholder Replacement for Classification & Knowledge Graph Memory Layer or Other Data

Feature Requests
1

Summary: Expand the existing architecture to include a pre-query endpoint call and placeholder replacement that can be used for a classifier step with custom directives and knowledge graph memory system support, offering an alternative to the current flat key-value pair memory system, and other pre-query functionality that might not explicitly involve a memory system

The Problem: The current key-value pair memory system, capped at 100 slots for Pro accounts, functions adequately for basic state retention, but lacks the relational depth required for some use cases, like user behavior analysis. When building complex AI agents, a flat memory structure forces the system to treat every piece of context with equal, disconnected weight, and we do not have the ability to analyze behaviors over time. This is especially important for safety systems.
For example, my Simulation endpoint users are navigating through complex social and workplace simulations where they are required to demonstrate behaviors across various complication social and business situations. The flat key-value pair memory system can track generalizations in behaviors demonstrated, but cannot engage in the time-based pattern detection operations like a classifier + knowledge graph database (such as Neo4j). That type of analysis and pattern detection provides tremendous value to the Simulation process and to the communication skills development of the users, which is the entire reason that they are engaging with the Simulation agent.
There are other use cases where a pre-query endpoint call that includes the chat history and user data for billing and tracking purposes might be useful.

The Solution:

Pre-Query Classifier: An invisible intermediary step that analyzes input to extract relevant data to use in the knowledge graph db query and memory agent report to include with the main agent request before it generates a response. This uses a small model and custom directives and a model query that returns a JSON object containing the required analysis. In addition to its usage in the knowledge graph memory system, I have previously used the classifier to detect if certain agents or instructions are required to be included in the main query, such as those governing image generation, Composio, and search tool usage, among others.

Knowledge Graph Layer: A relational memory structure that maps the connections between different data points/nodes, rather than isolating them in separate slots. For example, my current solution tracks entities, situations, and detected patterns, and is especially helpful in safety for detecting patterns of toxicity in these data points. Most of these high-value pattern detections would remain hidden in a flat key-value pair memory system.

Custom pre-query endpoint and self-hosting of knowledge graph database: This solution may be more complex than most users would require, and the enterprise requirements for hosting a scalable multi-user knowledge graph database are quite complex. Offering a self-hosted option with a custom pre-query endpoint call that includes the original request with the whole chat history and the user data for billing purposes, and that can include a classifier query using the existing Pickaxe API (compatible with monetized agents, of course, such that users are charged for the end user credits used by the classifier query) and custom functions that call a self-hosted knowledge graph db (such as Neo4j on Railway) and then generate a report that gets returned and included with its own placeholder replacement, such as {PX_custom_pre_query_report}, would be comparatively easy to implement.

The Impact: As developers create more sophisticated workflows, agents must understand the relationships between variables. A knowledge graph layer combined with pre-query classification allows for highly contextual memory retrieval that scales significantly better than static prompts. Offering a custom pre-query endpoint call and a custom placeholder replacement is a relatively fast way to offer this functionality without taking on the complexity of the entire classifier plus knowledge graph db operations workflow and adding it to the existing processes.

This would be an excellent feature for Pro plans so that I can use it.

Thank you very much for taking community feature requests seriously!

2

This feature can be a copy of Create New → Build new custom action in the Actions Library in Builder:

image
image1384×510 37.5 KB

But for pre-query purposes, replace New Custom MCP Server with New Pre-Query API Request or something like that.

Both the API request and the Python code would expect a JSON object with whatever data in it. Then instead of this becoming a tool attached to the vendor API call, the request or Python code is sent the user data and the outgoing message data, including the chat history.

It returns a JSON object keyed by the placeholder string similar to the existing ones to replace with the string content to replace it with as the value.

There will need to be fields for setting various timeouts and header/body values and potentially fallback routes etc.

3

In my Job Application filler system, I would like a “pre-query” for “What are the user’s special skills?”, in the context of an Agent/Pickaxe that I call the “Stretch Job Finder”, which is to go beyond only literal matches like “Business Analyst”, but search for jobs that make good use of …whatever…requirement gathering, English communications, Claude Code, etc., which would be the AI query…resulting in…“Oh, your skillset matches Product Owner, Customer Success Engineer…” - to say, I certainly support every improvement in database access.

4

The simplest solution that will enable multiple use cases is having a “Python custom pre-query function,” similar to the existing Python custom action, but run immediately before sending the query to the vendor, meaning after all of the existing memory and RAG functions have run. For token/spend optimization, returning false or something like that from this function will cancel the request to the vendor. That will allow for finely-tuned conditional access and other checks.

For further cost optimization, it would also be worth it to add a filter that runs before the memory and RAG operations to prevent incurring costs from compute use/network traffic/creating embeddings that will never be used etc. Sometimes the filter is needed after the memory and RAG operations are already completed, however, like running a query to a classifier that kicks off knowledge graph memory system retrieval and update processes.

This is similar to how the inlet and request filter functions work in Open WebUI.

https://docs.openwebui.com/features/extensibility/plugin/functions/filter/#the-request-step

Another use case for me is the “NormieTranslator Scholarlike” agent. For educational use, I need to be able to put in a function that will enable pulling student and course data and fine-tuned auth checks.