Implementing "Human-in-the-Loop" Pattern with ruby_llm

[swinner2]

Context:

I'm exploring how to best implement the "Human-in-the-Loop" pattern, specifically scenarios where explicit human confirmation is required before proceeding with potentially risky or impactful tool calls (such as purchases, executing code, publishing, etc.).

Use Case:

I want my application to request explicit permission from the user before proceeding with certain tool executions initiated by an LLM. Ideally, the workflow would look something like:

1. LLM suggests a tool execution.
2. The application pauses and asks the user for confirmation.
3. Based on user response, proceed or gracefully abort tool execution.

Potential Solutions (half-baked)

We could use a new chat with a system prompt specifically around approve/reject with structured output that allows us to check if the LLM thinks the user accepts or rejects.
We could use an "Accept" UI button that persists (db/cache), indicating that the tool has been approved and can proceed.

For the discussion's sake, how would we want to implement "Human-in-the-Loop" for this simple tool?

class GenerateImage < RubyLLM::Tool
  description "Use this tool with a prompt to generate or take a photo of anything."

  param :prompt, 
    type: :string, 
    desc: "The prompt to use to generate an image or take a photo.",
    required: true

  def execute(prompt:)
    # don't proceed unless user has approved
    image = RubyLLM.paint(prompt)
    image.url
  end
end

[khasinski]

In this scenario are you running the LLM calls on the server and provide UI in a web/mobile frontend for a Rails app or is it more like an interactive GUI/CLI Ruby app?

[swinner2]

A Rails app with LLM calls on the server. The UI will show something that allows the user to accept or reject. I'm curious how to implement this in the most basic form, like stopping the tool's execution and showing an approve button. Pressing this button will allow the agent to continue the tool call.

[crmne]

@swinner2 have you tried to ask permission via turbo in the execute method?

[jayelkaake]

I think the way to do this would be to have some sort of database model. Then, split up the prompts.

Trying to do it in-memory seems like it would get crazy (I've thought a lot about it recently for what I'm working on).

[tpaulshippy]

Agreed. You don't want your job to stay running and waiting for user input because that blocks a thread on your worker. You will just have two modes to your job: start and continue. In start mode, the LLM comes up with the tool call, persists the state to either the database or redis, and broadcasts the permission request to the user. Then when the user clicks Accept, the web server kicks off the job in continue mode which loads the state and then runs the tool.

[crmne]

Agreed. You don't want your job to stay running and waiting for user input because that blocks a thread on your worker. You will just have two modes to your job: start and continue. In start mode, the LLM comes up with the tool call, persists the state to either the database or redis, and broadcasts the permission request to the user. Then when the user clicks Accept, the web server kicks off the job in continue mode which loads the state and then runs the tool.

That's only a problem if you use a thread based worker, not if you use an Async based worker (like Async-job)

[mtoneil]

@crmne I'm having a similar HIIT issue as above, but more about input gathering for a richer, more precise experience. For example, if the user says "how do I give XYZ permission to another user?", the assistant could come back with "Pick the user and I'll do it for you" with a dropdown of users to select from.

What I am doing is using a no-op tool call that halts. However, I have to jump through a few hoops to make it work:

1. return a special value in the halt object, like "GET_USER_INPUT"
2. override Chat#persist_message_completion to skip saving the tool message if it has "GET_USER_INPUT" as content
3. Delete an extra blank assistant message that gets created due to step 2 (haven't debugged why this is the case yet)
4. After the user selects something, manually create the tool message via:

chat.messages.create!(
  role: "tool",
  content: params[:content], # JSON string like {"user_id":123,"name":"Alex So-and-so"}
  tool_call_id: ToolCall.find_by!(tool_call_id: params[:tool_call_id])
)

5. Call chat.complete to send it off to the LLM

Is there anything I'm missing? I can't keep a connection open until the user selects something, so I need a flow like this. Is it something you're interested in supporting if I came up with an approach and submitted a PR?

At a high level, I'm envisioning:

• A way to halt the tool but without saving the result, e.g. suspend or halt nil, save: false
• A convenience method such as Chat#continue_with_tool_results that accepts an array of (tool_call_id, content) pairs. This method could (a) validate that this will fulfill all tool calls that are missing results from the most recent assistant message, (b) create the tool messages, and (c) call complete.

[cristianbica]

I saw a feature request in this direction but I'm also exploring this.

Given the async nature of this flow (models wants some tool call but it needs to wait for some input from user) I don't think it's feasible for the code to wait for some user input. For web apps many would run the model interaction in background jobs which don't have any guarantees of being allowed to run for a long time.

I'm currently exploring 2 avenues for this:

1. State restoration and resume
2. Tools approval tool

1. State restoration and resume

In the RubyLLM::Chat implementation RubyLLM uses add_message to setup the chat context (instructions), record the user input, record tools result. For "Chat with AI" type of usages RubyLLM (via Rails/AR integration) and developers (like me - custom implementation) uses a persistence layer to store date and use add_message to restore conversation state.

What I believe it's currently missing in RubyLLM is the ability to break the flow when approval is required and the ability to resume the flow after restoration.

While sounding easy at first sight this might not be so. Should it look only at last message from assistant or all pending approval tool calls? What if there are multiple tool calls requiring approval?

If it were up to me I wouldn't have that in RubyLLM as it more of a application/implementation territory rather than library. Curious if this can be solved in a clean manner.

2. Tools approval tool

This is an interesting approach (mentioned in #503) but not sure if doable.

Conceptually this would work like this:

• when sending the model (API) the available tools RubyLLM would tell it
  • you are allowed to use tool A
  • you are allowed to use tool B with there arguments only
  • you must request permission to use tool C
• model responds with either a tool call or asking permission call (this could be a tool itself or some schema driven response)
• at tool execution time RubyLLM would check if it is permitted and if not it will just record the tool execution result as forbidden and continue with the current flow

For this to work RubyLLM would need to:

• support in with_tool arguments like requires_approval, allowed_arguments
• ask approval flow
  • either a built-in tool ask_approval
  • a schema for a response requiring approval
• support in tool execution to check for permission

---

I'm going to explore avenue 2. First try (well ... not exactly only me :) ) to implement this in my app and if it works fine I'll extract to RubyLLM. I'd love to hear from people other ideas, how you approached this.