Simplify and Validate Prompt Management System

Summary

Can you help rip out promptix and implement a lightweight prompt management system that reads templates from the same folder, though now we just need the current.md file no need for versioning.

One thing though these prompt templates needed to be loaded in memory we should not be loading them from file whent he /completions endpoint is hit.

Let me look at the template files and understand the Promptix API surface being used.

Let me check if Promptix is initialized/configured anywhere else.

Now replace all Promptix usage in llm.py:

Now remove promptix from pyproject.toml:

Those are pre-existing unused imports, not from my changes. Let me verify the final state of the edited files:

Done. Here's the summary:

Created backend/src/lib/prompt_manager.py — a ~40-line module that:

On import, reads every backend/prompts/<name>/current.md into an in-memory _templates dict
Exposes render(name, **variables) which does {{var}} substitution via regex
Raises clear errors for missing templates or missing variables

Updated backend/src/lib/agent/llm.py:

Replaced from promptix import Promptix with from src.lib import prompt_manager
build_agent_voice now calls prompt_manager.render("agent_persona", ...)
build_system_prompt now calls prompt_manager.render(modality_prompt_name) for modality instructions and prompt_manager.render(base_prompt_name, ...) for the main prompt
Stripped the verbose docstrings

Removed promptix>=0.2.0 from pyproject.toml.

Templates are loaded once at process startup (module import time), so /completions never touches the filesystem. The config.yaml and versions/ folders are just ignored — only current.md matters. You can clean those up whenever.

is there a library of some sort we can use for tempalting instead of using regex substitutions @backend/src/lib/prompt_manager.py:30-36

Yeah, Jinja2 is the standard — already battle-tested for exactly this. It's what Promptix was likely using under the hood anyway.

Already a transitive dependency, so no new install needed. Jinja2 uses {{ var }} syntax natively — the templates won't need any changes.

Actually, let me use Jinja2's built-in StrictUndefined instead of that hacky lambda:

Clean. Jinja2 is already in the dependency tree (transitive via FastAPI/Starlette), uses {{ var }} natively so the templates work as-is, and StrictUndefined will blow up loudly if a variable is missing — same behavior as before.

@backend/src/lib/prompt_manager.py:26-34 we have a config.yaml file for each prompt template does jinja2 have a way to verify that the variables are given at render time?

Jinja2 has Environment.parse() which extracts all undeclared variables from a template via meta.find_undeclared_variables(). But honestly, StrictUndefined already handles this — if you call render() and miss a variable, it throws UndefinedError immediately at render time.

The config.yaml files were a Promptix thing for metadata/schema. They don't add value here since Jinja2's StrictUndefined already enforces that all referenced variables are provided. I'd just delete them along with the versions/ folders — they're dead weight now.

Want me to clean those up?

@backend/src/controllers/agent.py:198-201 address this review comment `🚩 No validation that prompt_template maps to an existing template at update time

When team_prompt_template is set via update_agent_configuration, there is no validation that the value corresponds to an actual loaded template (e.g., checking prompt_manager._templates). An invalid value like "nonexistent" would be accepted and stored. The error would only surface later during create_agent_chat_completion when prompt_manager.render() raises a ValueError — resulting in a 500 error for the caller. Whether to add upfront validation is a design decision: it trades API-time safety for coupling the API layer to the template registry.`

Done. Added validation to update_agent_configuration:

python

Now setting team_prompt_template to "nonexistent" will fail fast with a 400 at update time listing all available templates, instead of blowing up with a 500 during /completions.