Does it provide any value to our forum (in areas such as Ideas, Feedback, Development) to link the native Discourse AI agent feature with a foreign expert system?
See the thread on the Discourse meta forum:
Both could be of interest:
- build up an AI agent that “knows” the Gramps wiki, all development documents (RAG) and open that agent via MCP to the Discourse AI assistant
- Connect the Gramps Assistant of @dsblank to Gramps Discourse in order that this assistant can use all the knowledge documented in Discourse to offer better help to its users.
Interesting, I hadn’t thought about a discourse connection. I did try connecting to our wiki, but it was slow, and bad. A good model already knows that info anyway.
The MediaWiki site is a bit of quagmire at 4,700 content pages, 19,800 total pages and 6,000 uploads.
Do you think connecting to the PDF of the Wiki chapters would be better… or an index of those primary chapter pages?
The big, modern LLMs have already been trained on the Gramps sites’ data, so they know it directly. For smaller, local models… no, they need the text directly, and probably using something like a RAG (what gramps-web uses). But that is outside my scope.
Of course, others can hook their gramps MCP or other agentic system to the proposed right-hand persistent sidebar, and they may want to work on that.
I have to admit that my interest in using AI is more forward-thinking than retrospective.
I want it to help build tools for Gramps… not interpret genealogical data. (It seems like solving the genealogical puzzle is what attracts people to the hobby. Usurping that part of the task kills some of the appeal.) And it is hard to trust that the evolving model won’t invisibly mangle the data in unanticipated ways.
I’d rather it help build solid, repeatable functionalities. Ones that are unlikely to ever draw the attention of human developers.
Like the humongous list of requested Filter Rules.
Or knocking down the issues and features backlist on MantisBT. So that unclogged tool could become useful to Developers again.
Or re-writing the wiki manual to fill in the old stubs. And add the missing new feature documentation since 5.1 version. (Or something far beyond any current aspirations… totally rebasing it!)
As a user, I would like to have more filter rules available, but also would not like to be overwhelmed with a huge list that I have to look through to find the ones I need. I don’t know what the right balance is.
I think I’d like to be able to describe the result set I’m trying to create, and be given a custom filter based on available rules (or the “recipe” for me to create it myself), plus any new rules that may be needed.
Challenge accepted! I will try to make Gramps Assistant do that.
That is a useful list. Currently, there are 250 filters in core gramps. I’m working on an addon that will allow a database to implement filters directly. I’m not going to commit to those 250, let alone more, until we have some of the PRs approved and merged.
That’s cool. A few days ago, I asked Claude AI to review that list, organize, prioritize and choose 1 to start as a test. (Fortuitously, it chose one that was of real interest to me.) And to develop some sort of prompting reference for building a Rule addon.
As is Claude wont, it started to over-complicate things. And it also built custom code for interface parts that should have been done through the Gramps API.
So, when my session ran out of complimentary prompts, the project was moved to where Codex could see it, then prompted for a re-write of the options. Instead of that, Codex chose to rewrite the whole module from scratch while dropped most of the options. After several rounds of pointing out where it ignored criteria and asking for corrections, it wasn’t getting any closer to working. So we started over with restrictions on “interface” being the only allowed changes. Still, no success.
Where Claude built addons that successfully registered, Codex addons are still silently failing to register.
My experiments so far have shown a pattern of ChatGPT (or Codex, since that is based on ChatGPT) and Perplexity being remarkably obstinate. They seem to be okay for working on snippits but not so good for the overall picture.
Claude does better at actually delivering working addons and suggesting revisions to core core that work (but do not necessarily leverage pertinent API) within our existing framework. It is hard to make Claude “color within the lines” but fairly easy to get something out of it that works.
If you’re mainly using “Claude AI” in the browser, that might explain the limitations you’re running into. For coding workflows you’ll get far better results by switching to tools that are actually designed for full‑project context, such as:
- Cursor (Pro + token add‑ons) – the best option if you want the AI to understand your entire project structure
- Claude Code app – much better than the browser version for Python and multi‑file work
- Perplexity Developer Mode – excellent for smaller, well‑defined coding tasks
- A fully local setup using
- VS Code + Continue
- LM Studio or Ollama
- and a coder‑optimized model like Qwen3/Qwen3.5 in 7B, 11B or 14B depending on your VRAM
No matter which option you choose, you’ll still need to structure your project in modules. Large tasks always work better when broken into smaller components. I’ve spent almost a year planning the module structure for my own projects, and most of that time has gone into testing prompts and refining the architecture — not writing code. But my projects are also far more complex than what you’re describing here.
You’re right and I am intentionally handicapping the AIs as a stress test.
My reasoning is that this may be a user’s first foray into developing. That they will not want to put the effort into setting up a complex environment nor expend a lot of thought on a minor task.
Much like the first use of Gramps, they will be testing if the initial results are worth the investment.
If they do see even rough results, they will be more willing to try more. Thus slowly build expertise and explore options.
I don’t think that makes much sense. It’s like not pushing down all the way on the gas pedal and measuring the speed. It really isn’t a test that means much.
It is testing whether there is a barrier or springboard to entry.
Would it work better if you could first give it a boilerplate prompt containing specific rules (do’s and dont’s) for Gramps coding, rather than just relying on whatever it may already “know”?
And if such a prompt existed, could it be used with the others (Codex, Perplexity, etc.) to make them more capable? Or at least enough to mitigate your concern:
Yes. This is among the experiments being tried. Whether we need different Agent priming prompts to make the various AI models more effective… and whether there need to be an array of priming prompts for different.
Part of that aligns with your challenge that piqued the interest of @dsblank : Making the Gramps Assistant design custom filters (with existing rules) to achieve a described set of results.
I’ve populated my personal preferences in Claude with the Gramps Agent.md and some basic guidelines. The objective being to make starting a new prompt to create a Gramps add-on plug-in less onerous.