Out-of-Scope Bot Guardrails
In order for orchestration to work, Intelligences must be able to successfully recognize that a request is not within its executional purview, and in such cases, should make the tool call: callAvatar.
Example Golden Path
I am talking with my Biographer on the Memory Team about a class I took where I learned SQL, and it has created a memory for me. I then request that the Biographer add this new skill to my resume
The Biographer Bot cannot perform this function, so I see a popup on my screen above the active item with a cameo of my Resume Builder Bot, who asks if I just want to add this to my skills section, or if I would like to add it to my education. It is now the active bot I am chatting with. I am given a button that can make this bot and team active and primary, but I do not click it.
I respond in normal chat input that I only want the skill added. It returns a success message, then fades out, and I once again am continuing with my Biographer, now active again, and can add more detail to my class memory.
Todo
@ajfrist As discussed today (thank you!) here are the core elements that I want you to conceptualize and make adjustments to the branch; this will not be immediately testable (for several reasons) so when complete, just let me know and we'll set up time to review, and I'll show you how we pipeline it make it testable by you
Orchestration Plea Pipeline
- Active Intelligence (
botAgent.activeBot) recognizes (via instructions alone, or some metadata/dumb-code?) that a given request is out-of-scope for its activation
- It produces a tool call (and possibly also a text response indicating it needs to find the appropriate intelligence to reconcile the request) to
callAvatar
callAvatar parameters (suggestions only)
request: string - The request content the member had inputreason: string - Why the intelligence considered this request to be out-of-scopecontext: string - Additional relevant information derived from active item and/or conversation (from example: biographer would include the skills that were referenced and perhaps the name of the class`itemId: Guid - Optional, gives item id so that any bot can use: getSummary to retrieve additional context
Out-of-Scope Bot Guardrails
In order for orchestration to work, Intelligences must be able to successfully recognize that a request is not within its executional purview, and in such cases, should make the tool call:
callAvatar.Example Golden Path
Todo
@ajfrist As discussed today (thank you!) here are the core elements that I want you to conceptualize and make adjustments to the branch; this will not be immediately testable (for several reasons) so when complete, just let me know and we'll set up time to review, and I'll show you how we pipeline it make it testable by you
inc\json-schemas\openai\functions\callAvatar.json: Update the shell document to include additional properties that would be useful, relevant or insightful to pass to the Avatar's request observer so that it can route the request with high fidelityinc\json-schemas\intelligences\biographer-intelligence-1.9.json: underinstructionsproperty, I addedoutOfScope- this is the natural language description that describes how the intelligence will determine when to consider something "out-of-scope" and run the functioncallAvatar--outOfScopeis the field you should focus on to elicit the appropriate behaviorOrchestration Plea Pipeline
botAgent.activeBot) recognizes (via instructions alone, or some metadata/dumb-code?) that a given request is out-of-scope for its activationcallAvatarcallAvatarparameters (suggestions only)request: string- The request content the member had inputreason: string- Why the intelligence considered this request to be out-of-scopecontext: string- Additional relevant information derived from active item and/or conversation (from example: biographer would include the skills that were referenced and perhaps the name of the class`itemId: Guid- Optional, gives item id so that any bot can use:getSummaryto retrieve additional context