Dev/gc learnings update

assistants/prospector-assistant/gc_learnings.md

@@ -6,10 +6,9 @@ This doc is intended to capture our team learnings with using Guided Conversatio
 
 ## Notes - To Be Updated
 
-1. Artifact accessibility - When using GC as a component conversation of a larger conversation, it would be helpful to set an artifact BEFORE starting up GC. Currently, GC takes in a schema and produces the original artifact. As a result, we are having to hack inputs via context, rules, or conversation flow. I (Mollie) have been trying the context approach to add information such as attachment filenames, if this is the first call to this particular gc within a larger conversation or a later call (see startup status below), and possibly chat history and attachment content (not just filenames).
+1. Artifact accessibility - When using GC as a component conversation of a larger conversation, it would be helpful to have a way to set an artifact before starting up GC. Currently, GC takes in a schema and produces the original artifact. A current hack is to add information via context, rules, or conversation. Another approach is to start the GC in order to create the artifact, and then call call it again after manipulating the artifact.
 
-2. Startup status - Within a larger conversation scope, a single gc (w/ config) may be called multiple times. BUt without the correct context, that gc may think its starting a new conversation, when its not. Right now I am getting a GC saying "Hello!" every time it starts, even though it's like the 5th time I'm calling it for the sole purpose of talking to me about updating an outline. Another templated field that might be helpful is the context of where this gc falls within the broader conversation. This points back to the artifact as a template, and how I would rather set some values ahead of time within a template for GC to use than hack the context with custom prompt engineering.
+2. Startup status - Within a larger conversation scope, a single gc (w/ config) may be called multiple times. But without the correct context, that gc may think its starting a new conversation, when its not. Currently a "Hello!" is emitted from GC every time it starts, even though it's in the middle of a large conversation context. A startup-status templated field in the artifact could help address this.
 
-3. Completion status - Would love to get more information on why gc decides a conversation is over. Right now its just a bool in the result at the end. There is other data i'm also interested in using at the completion of a conversation "round" as I'm calling it. Currently using the artifact to access this info, and this seems to be working decently well. (This might be the better approach in general because it is customizable.) Via the artifact, rules, and conversation_flow, I can tell the gc what the conversation_status options are and when to use them (especially what to use at the end), and i'm experimenting with a user_decision in the artifact that upon completion, will tell the code what branch path to take next (kinda like the OpenAI tool selection concept if I'm understanding it correctly, but hackier). The issue is that I'm having to prompt engineer all of this and I'm making mistakes. Sometimes no final response is given even when I think I've given GC all the information it should need.
-   --> This all points to a more robust template that relies less on individual prompt engineering but uses well-tested prompts that fill in basic variable names, absolutes (such as MUST or NEVER), and other prompting best practices that yield consistent results. The programmer should not have to keep reinventing the prompting wheel on some basic data needs, like completion status or completion-next-action.
-   --> Another note, its possible that prompt instructions for setting a conversation status to "complete" does not coincide with gc thinking the "coversation_is_over". I suspect because the instructions I have given it to determine the convo is complete (via using the artifact field) uses different prompting internally than the `result.conversation_is_over` uses. As a result, I am not checking conversation_is_over at all.
+3. Completion status - More information is needed when GC decides a conversation is over. Right now its a bool in the result at the end. Using the artifact may be a better approach in general -- this can allows customization. Some completion fields of interest are the status (a 'why' the conversation ended: user-completed, user-exit, etc.), a next-function call (to support branching in the code based on user decision), and final user message. (Currently a final message from GC appears to be hardcoded.) These could also be templated fields in the artifact, which could help the dev avoid re-creating prompts that can introduce bugs. (Currently the rules, context, and conversation flow are free form. It may benefit to tighten up certain aspects of these fields to be more structured.)
+   > NOTE: It is possible the prompt instructions for setting a conversation status to "complete" will not coincide with GC setting its result "conversation_is_over". It is likely best to depend on one or the other, and not depend on both to be true at the same time.