Using Pathom3 as AI Query Layer for Business Data

[jiegao19771010]

Hi Pathom3 Team,

First, I want to thank you for your incredible work on Pathom3. It is truly a brilliant framework — the attribute-centric, graph-driven model is not only elegant for backend development but opens powerful opportunities in AI-driven systems.

I am currently designing a system where Pathom3 acts as the data query layer for an AI agent. The basic idea is:
• The backend defines resolvers for business data entities (such as Purchase Orders, Vendors, etc.).
• The AI generates EQL queries, selecting attributes based on prompts and context.
• The AI doesn’t need to understand the database schema — it only picks attributes declaratively, and Pathom handles graph resolution automatically.

To further simplify the AI’s task, I’m considering:
• Combining related attributes (for example: grouping ship_to_zip, ship_to_country, ship_to_address1 into a single logical attribute like vpo/ship-to).
• Reducing the surface area of the attribute model to make it easier for AI to reason about available data.

This way, AI prompts and attribute selection remain clean, and internal complexity is hidden behind Pathom’s resolver logic.

I would love to hear your suggestions on:
• Whether you see any potential pitfalls or opportunities for improving this approach.
• Best practices for defining attribute metadata (descriptions, types) that would make AI generation even easier.
• Any features in Pathom3 that could further support an AI-facing usage like this (such as query validation, dynamic attribute discovery, etc.).

I truly appreciate any feedback you can offer. Thank you again for building such an amazing system — Pathom3 is not only powerful for humans but seems incredibly well-suited for machine-driven applications as well.

Best regards,
Jie Gao (gaolinux@sohu.com)

[wilkerlucio]

Hi @jiegao19771010. I find the idea fascinating. I didn't have a chance to try something like that myself, but I'm looking forward to hearing about your findings. Please feel free to continue using this discussion to bring in updated points, and other users can also share their thoughts here if they are exploring this AI side.

On your questions specifically:

I don't see any specific pitfalls, but to be honest, I've been mostly on the user side of AI. I haven't done any development in the field, so I don't have much to contribute here.
On the attributes, I think using bigger names can help in larger contexts, which may help the AI disambiguate attributes more effectively.
One feature that's in Pathom 2 but should be relatively easy to migrate is the query generator. You can find it here: https://github.com/wilkerlucio/pathom/blob/main/src/com/wsscode/pathom/connect/gen.cljc#L81-L162
This might be useful to generate some random (but valid) queries to train the AI somehow.

[jiegao1977]

I created a simple demo using Pathom3 to explore our Vendor Purchase Order (VPO) data—both Header and Detail—along with related entities like Vendor and Part Master. I found the experience not only straightforward but, most importantly, stable. It performs reliably and, in my view, is a significant improvement over the traditional “AI SQL Generator” approach.

In conventional setups, we typically build AI agents that rely on a combination of AI and tool-based APIs. By contrast, Pathom3 offers several key advantages:

• Efficient data handling: Only relevant attributes are retrieved and sent to the AI, resulting in lower token usage and improved performance.
• Simplified logic: The AI doesn't need to understand or manage relationships between multiple APIs, which reduces complexity, eliminates potential errors, and improves overall efficiency.
• Easy customization: Few-shot examples can be added quickly to guide the AI in generating queries and answers, making it easy to train and extend.

[jiegao1977]

I am considering the possibility of developing functions within Pathom that would facilitate the creation of resolver functions, as well as the automatic generation of indexes based on OpenAPI specifications.