Contrib.social

Make it possible to poll and see what the agent is doing.

Open on Drupal.org →
Created on 27 August 2025, 19 days ago

Problem/Motivation

Agents can be long running processes, and having ways of being able to get partial information on what is happening while they are processing, is vital for good UX/UI.

Also being able to show this in a structured manner, instead of just showing the textual outputs on each loop is important for specialized third party apps.

We have in agents a way to interupt each loop and proceed to run in later again via this issue 📌 Make it possible to fetch and build the state of the agents as an array Active and this issue ✨ Add Javascript orchestration for each loop in the Chatbot/Assistants API Active . While that solves many of the timeout issues that hosters might have, where they kill off the processing, it doesn't solve the UX issue above.

We had a research and feedback issue here 📌 Research best way to return constant feedback and do long running tasks in a chatbot Active and while it said that polling is not the optimal solution, it might be it for specific apps that does not have high traffic and needs to create specific structured output.

What we need is the possibility for the Agent to update every step it takes and feed that update partially, including:

  • Start off an agent run.
  • Start off a loop with system prompts, tools available, chat history available, provider information (model, settings etc.)
  • End off a loop with text responses and tool choices.
  • Start off a tool execution with the structured inputs.
  • End off a tool execution with the results.
  • End off a loop
  • End off an agent run.
  • TBD

Currently in the AI API Explorer we have a way where we do this and store it in custom entities, but this should be possible to store in the PrivateTempStore, KeyValueExpireable or SharedTempStore and have a service that you can poll a unique id against and get an object of the latest updates for your API polling service to respond with.

Proposed resolution

  • Create a method for ConfigAiAgentInterface that enables/disables the progress service.
  • This will require that a jobId is set for the agent, otherwise warn and throw an exception when trying to run the agent.
  • If this is enabled while running an agent, make sure to use the events to update this to a storage of choice.
  • Create an interface to store this, so it can be easily swappable. PrivateTempStore works with AIAssistantsAPI, but requires a session, so it might be a bad choice here. PrivateTempStore is however naturally secure. Maybe persistant storage/entity is interesting at a later stage.
  • Create an interface called AgentStatusUpdateItemInterface, that holds what kind of status it is (enum?), when it started and a natural language description.
  • Create interfaces that extends this for different type of events, that might hold specific data like tool_id, tool_results, tool_input,
  • Create an interface called AgentStatusUpdateInterface, that should store the items in the order they come in.
  • Create object for it.
  • Create a service that takes the jobId and gives back the AgentStatusUpdate object if it exists.

Open questions:

  • Initial storage - should we do PrivateTempStorage and force sessions/login? Otherwise KeyValueExpireable might make sense. We could do cache as well if the full data is given back on each update.
  • If we do not do PrivateTempStorage we need some kind of permissions check for a jobId. Should the jobId itself have a uid on it or some other authentication?
📌 Task
Status

Active

Version

1.2

Component

Code

Created by

🇩🇪Germany marcus_johansson

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @marcus_johansson
  • Comment 19 days ago →
    🇩🇪Germany marcus_johansson
  • Comment 14 days ago →
    🇵🇹Portugal catia_penas
  • Merge request !181Resolve #3543377 "Make it possible" → (Merged) created by marcus_johansson
  • Comment 13 days ago →
    🇩🇪Germany marcus_johansson
  • Comment 7 days ago →
    🇵🇹Portugal catia_penas
  • Comment 7 days ago →
    🇩🇪Germany marcus_johansson
  • Comment 6 days ago →
    🇩🇪Germany marcus_johansson

    So here is a general issue, if someone can think of a smart solution.

    We need to frontend to know a thread id before its starting to poll an agent, because otherwise you only access this information when the response comes in. Unless you are streaming, this is when the agent is finished, so then this serves no purpose for anyone wanting to poll in realtime.

    This means that everytime you send a request to an agent, this has to be included. This means that we need a way to get a cycle_id before you send the agent request, which is not great, but I can't think of another solution.

    I'm not sure if cycle_id is the correct id name as well, right now there is basically:

    * thread_id - if there is some history from the main caller, you can see this being followed up here. So this could be the session history for the assistant. This needs to be set from the caller.
    * cycle_id - the stateless loop from the main caller. This is what needs to be set from the caller.
    * caller_id - if the agent is being called from another agent, this will set a unique uuid. Happens automatic in the service.
    * agent_runner_id - this is a unique id for the first agent and all sub agents, so you for instance can see when the same sub agent is called twice, with two separate tasks. Happens automatic in the service.

    So if you are the assistants api, you are in charge of creating and maintaing the thread_id, which you can reuse and getting a cycle_id from the polling service that has to be unique.

    Does this make sense?

  • Pipeline finished with Success
    3 days ago
    Total: 163s
    #596302
  • Pipeline finished with Success
    3 days ago
    Total: 197s
    #596889
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024