Add "agent_id" and "conversation_id" to the new "start_conversation" service

Feature Requests
1

I think we need to be able to use “agent_id” at the very least and ideally “conversation_id” as well with the new “start_conversation” service.

For example we might have a greeter agent that uses the extra_system_prompt to address an identified guest and the default system prompt / conversation agent may struggle with that. It would be nice to use a custom conversation agent with a custom prompt to handle guest interactions (as an example).

2

Hello tuckwoor,

You should look at a trace. There may be a variable there that you can use.

3

Then setup a custom conversation agent with a custom prompt? M having trouble understanding what you’re asking for?

4

@NathanCu - That’s why it needs the agent_id parameter. You can set up a custom conversation agent no problem, but you can’t tell start_conversation to use that custom agent.

5

Does it…

Just pick one of your available options and set the selct just before your call - the call then goes to the assistant set to that satellite.

You have to think of it as… I’m casting a call to whatever agent is on that satellite, not I’m opening an agent and sending it to that satellite. A discrete but important difference and how this appears to be built.

sequence:
  - action: select.select_option
    metadata: {}
    data:
      option: Jarvis
    target:
      entity_id: select.office_voice_assistant_assistant
  - action: assist_satellite.start_conversation
    metadata: {}
    data:
      start_message: this is a test
      preannounce: true
      extra_system_prompt: testing...
6

@NathanCu - I did not know the conversation agent was a select state for the satellite! Will give that a try, thanks! I still think start_conversation should mirror the conversation process and allow conversation IDs (for extended conversations etc), but this should work for my requirements for the time being. Thanks again!

1 Like
7

I think this is how they intend it to work. They appear to want the agent at endpoint experience to be stable and set at the endpoint. At least if you use the method above you’re ‘conscious’ that the agent state is the last one you set. (im playing around with the idea of having the agent redirect to a different model based on home state. For instance, in entertainment mode - expect company - switch the agent to one that doesn’t have access to family personal data, etc)

Im not entirely sure I don’t prefer your version long term as an override option. It’s certainly easier than the script above. For ‘safety’ you’ll probably want to capture current setting in a variable and restore when you exit the call. :wink:

Let us know how it works.

1 Like
8

It definitely works for making that first response more relevant and “rich” but as start_conversation is essentially stateless, it is a bit frustrating as we only get one back and forth and not a conversation beyond that. Would be amazing if we could keep the satellite listening beyond that first response for extended chats (my visiting mother in law would appreciate it!).

9

Continued conversation now works on the voice assistant satellite. Friday asked me a question 30 seconds ago.

You can open a conversation with a question and it will listen. Then if the response is also a clarifying question it does it again…