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)