What you want and why
Users should be able to configure personal information / context directly from the /chat UI — things like member IDs, location coordinates, preferences, or any free-form key-value pairs — without needing access to environment variables or server configuration.
This context is stored in state.pi (personal information field on AgentState) and is automatically injected into every LLM call as a ## User Context block appended to the first user message. Right now this field can only be set programmatically (e.g. CUGA_DEMO_MODE=health injects a hardcoded HEALTH_USER_CONTEXT). There is no way for an end user to set or update it through the UI.
How it could work
- Add a "Personal Context" settings panel accessible from the
/chat page (e.g. via a user profile icon or a settings drawer).
- The panel allows users to input free-form text (or structured key-value pairs) that represents their personal context — e.g.:
Member ID: 121231234
Location: latitude 40.7128, longitude -74.0060
Preferred language: English
- On save, the value is persisted (localStorage or a backend
/api/user/context endpoint) and sent with each chat request so the server can populate state.pi.
- The server's
event_stream reads the provided context into local_state.pi (same injection point already used for the health demo today).
- The field should be editable at any time; changes take effect from the next message.
- When
state.pi is already set by a server-side mechanism (e.g. CUGA_DEMO_MODE=health), the server-side value should take precedence (or the UI should show it as read-only / pre-filled).
Links or extra context
state.pi injection in the graph: src/cuga/backend/cuga_graph/nodes/cuga_lite/cuga_lite_graph.py — lines ~844–890 (appended as ## User Context to the first user message).
- Current server-side injection point:
src/cuga/backend/server/main.py event_stream function — sets local_state.pi from HEALTH_USER_CONTEXT when CUGA_DEMO_MODE=health.
- SDK path:
src/cuga/sdk.py — user_context parameter already accepted in invoke() and mapped to state.pi.
- The chat request handler in
main.py would need to accept a user_context field from the frontend payload and pass it through to the existing local_state.pi assignment.
What you want and why
Users should be able to configure personal information / context directly from the
/chatUI — things like member IDs, location coordinates, preferences, or any free-form key-value pairs — without needing access to environment variables or server configuration.This context is stored in
state.pi(personal information field onAgentState) and is automatically injected into every LLM call as a## User Contextblock appended to the first user message. Right now this field can only be set programmatically (e.g.CUGA_DEMO_MODE=healthinjects a hardcodedHEALTH_USER_CONTEXT). There is no way for an end user to set or update it through the UI.How it could work
/chatpage (e.g. via a user profile icon or a settings drawer)./api/user/contextendpoint) and sent with each chat request so the server can populatestate.pi.event_streamreads the provided context intolocal_state.pi(same injection point already used for the health demo today).state.piis already set by a server-side mechanism (e.g.CUGA_DEMO_MODE=health), the server-side value should take precedence (or the UI should show it as read-only / pre-filled).Links or extra context
state.piinjection in the graph:src/cuga/backend/cuga_graph/nodes/cuga_lite/cuga_lite_graph.py— lines ~844–890 (appended as## User Contextto the first user message).src/cuga/backend/server/main.pyevent_streamfunction — setslocal_state.pifromHEALTH_USER_CONTEXTwhenCUGA_DEMO_MODE=health.src/cuga/sdk.py—user_contextparameter already accepted ininvoke()and mapped tostate.pi.main.pywould need to accept auser_contextfield from the frontend payload and pass it through to the existinglocal_state.piassignment.