Grok Bot — Delegated Cloud Agents Are Running but Parent Bot Appears Idle

[Sanghoon_Kang]

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Hello Cursor / Grok Bot team,

I’m actively testing Grok Bot as a multi-agent product-development organization, with a persistent CEO / orchestrator Bot, project-specific Builder and QA Bots, and a shared Research Bot.

The multi-agent delegation itself is working impressively well, but I encountered a significant observability problem that makes it difficult to trust autonomous workflows without manually checking on them.

1. Background work is not persistently visible

My CEO Bot delegated two evidence-export jobs to Cloud Agents. For approximately 10 minutes, the CEO conversation appeared idle and there was no clear persistent UI indication that work was still running.

I assumed the workflow had stalled and manually asked the CEO to inspect its delegated tasks.

Only then did it report that two Cloud Agents were still actively running:

Sent liquid capture export — RUNNING
Contract 03 capture export — RUNNING

So the underlying agents were working correctly, but the parent Bot UI did not make that state sufficiently visible.

For a multi-agent orchestration product, I believe the parent Bot should persistently surface something like:

RUNNING — 2 delegated agents

Contract 03 evidence export — Running
Sent liquid evidence export — Running
ETA: approximately 5–10 minutes / unknown

This status should remain visible even when the parent Bot itself is not actively producing chat messages.

2. ETA / progress visibility

When a Bot delegates a potentially long-running task, it would be very useful to show an estimated completion window.

The ETA does not need to imply false precision. Values such as:

ETA ~5–10 min
ETA unknown — waiting for first checkpoint
Running longer than expected — ETA updated

would be enough.

The important point is that the user should not have to ask, “Is it still working?”

3. Explicit BLOCKED / WAITING / HUMAN ACTION REQUIRED states

When an agent cannot continue, the parent Bot should surface a persistent state such as:

BLOCKED

Reason: Cloud Agent permission required
Blocked task: Contract 04 QA
Human action: Approve “Run once”
Resume behavior: Automatically resume the same workflow after approval

I would distinguish this from:

WAITING — normal dependency/callback wait
HUMAN ACTION REQUIRED — explicit user input/approval needed
BLOCKED — workflow cannot progress
RUNNING — active delegated work
COMPLETE — workflow finished

4. Parent/child delegation callback visibility

I also encountered cases where Builder, QA, or Research work had completed, but it was unclear whether the CEO/orchestrator Bot had received and consumed the completion callback.

For persistent multi-agent organizations, the user should be able to see a simple chain such as:

CEO → Builder → QA → CEO

with each stage showing RUNNING / WAITING / COMPLETE / BLOCKED.

This is particularly important because the core value proposition of Grok Bot is that users can delegate work and come back later rather than continuously supervise agents.

5. Human review should be review, not operational work

Another related UX opportunity is the final Human Review handoff.

Instead of asking the user to browse artifact directories, launch local servers, find screenshots, or manually reconstruct QA evidence, the orchestrator should be able to present a curated Human Review Package directly in the conversation:

key screenshots/evidence
before/after or expected/actual comparisons
what specifically requires human judgment
PASS / FAIL as the only required human action

This would make Grok Bot feel much more like an actual AI organization rather than a collection of agents that still require the human to act as project manager and QA operator.

Why I think this matters

Grok Bot’s persistent Bots and cloud computers make it possible to build something much closer to an autonomous organization than a conventional coding assistant.

In that model, orchestration observability becomes critical. If two agents are working in the background but the UI looks idle, users will interrupt healthy workflows, manually poll agents, or lose confidence that delegation is working.

The underlying multi-agent behavior I tested was largely successful. The missing piece was visibility into that behavior.

I would strongly suggest a persistent Active Work / Delegated Tasks indicator at the parent-Bot level, including:

number of active agents
task names
RUNNING / WAITING / BLOCKED states
approximate ETA
Human Action Required flag
resume condition
completion callback / next routing state

I can provide screenshots from the actual multi-agent workflow if useful.

Thank you.

Steps to Reproduce

1. Create a persistent Grok Bot that acts as a parent/orchestrator (in my case, “CEO — Product & Development”).

2. Have the parent Bot delegate multiple tasks to other Bots / Cloud Agents.

3. Let the delegated Cloud Agents continue running in the background without sending additional messages to the parent Bot.

4. Return to or observe the parent Bot conversation.

5. The parent Bot UI appears idle and does not persistently indicate that delegated Cloud Agents are still running.

6. Ask the parent Bot to explicitly inspect the status of its delegated tasks.

7. The parent Bot then reports that the delegated Cloud Agents are still RUNNING.

In my reproduced case, two delegated Cloud Agents were simultaneously running:

• Sent liquid capture export — RUNNING
• Contract 03 capture export — RUNNING

Before manually asking for status, there was no sufficiently visible persistent indication in the parent Bot UI that these two background jobs were active.

Expected Behavior

When a parent/orchestrator Grok Bot has active delegated work, the UI should persistently expose that state without requiring the user to manually ask for status.

For example:

RUNNING — 2 delegated agents

• Contract 03 evidence export — Running
• Sent liquid evidence export — Running
• ETA: approximately 5–10 minutes / unknown

If work stops or cannot proceed, the UI should clearly distinguish:

WAITING — waiting for a normal dependency/callback
HUMAN ACTION REQUIRED — explicit user action or approval is needed
BLOCKED — workflow cannot continue
RUNNING — delegated work is actively executing
COMPLETE — delegated workflow has completed

For BLOCKED or HUMAN ACTION REQUIRED states, the parent Bot should also surface:

• why the workflow stopped
• which task is affected
• exactly what the human needs to do
• whether the workflow will automatically resume afterward

For long-running delegated tasks, an approximate ETA or progress/checkpoint indication should also be visible. The ETA may explicitly be “unknown” rather than presenting false precision.

The user should be able to understand whether the AI organization is working, waiting, blocked, or finished without manually polling the orchestrator Bot.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

버전: 0.53.0
릴리스 트랙: stable
OS: darwin

For AI issues: which model did you use?

Auto (Grok Bot default orchestration)

This issue does not appear to be model-specific. It concerns persistent background/delegated Cloud Agent status visibility in the Grok Bot UI.

For AI issues: add Request ID with privacy disabled

Background Agent IDs:

Sent liquid capture export:
bc-1bef88bc

Contract 03 capture export:
bc-e199dc6a

These two agents were reported as RUNNING by the parent CEO Bot while the parent conversation UI appeared idle / did not persistently expose the active delegated work.

Additional Information

This was observed during a real multi-agent development workflow, not a synthetic test.

My Grok Bot organization currently consists of:

• CEO / orchestrator Bot
• project-specific Builder Bot
• independent QA Bot
• shared Research Bot

The delegation itself is working well. The main problem is observability.

Because the parent Bot appeared idle while two delegated Cloud Agents were actually running, I initially interpreted the workflow as stalled and manually asked the CEO Bot for status. Only after that manual query did it reveal that both Cloud Agents were still running.

For an autonomous multi-agent workflow, this creates unnecessary human supervision and reduces confidence in delegation.

Ideally, a user should be able to leave the workflow running and later immediately understand:

1. What is currently running?
2. Which agent owns each task?
3. How long might it take?
4. Is anything waiting or blocked?
5. Does the human need to do anything?
6. What will happen automatically after completion?

I believe persistent parent-level orchestration status would substantially improve the Grok Bot experience for multi-agent workflows.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Colin]

Hey @Sanghoon_Kang, thanks for the detailed write-up!

You’re right that the parent bot goes quiet once it hands off the work. Today, it only speaks up again when a delegated agent finishes (it gets woken automatically at that point), so a long-running job looks idle from the chat even though it isn’t. The team is actively working on making that in-flight state visible in the parent conversation, so keep an eye on upcoming Grok Bot releases.

In the meantime, the Cloud Agents your bot launches are ordinary Cursor cloud agents, so you can watch their live status (running, finished, errored) at cursor.com/agents or in the Cursor desktop app without asking the bot. You can also ask the parent bot to attach the agent card when it mentions a delegated agent, which shows Running / Done inline.

[Sanghoon_Kang]

Thanks Colin — this is very helpful and confirms exactly what I was observing.

Knowing that the parent bot is intentionally quiet while delegated Cloud Agents are running, and is automatically woken when they finish, clarifies the behavior.

The upcoming in-flight visibility in the parent conversation sounds like exactly the improvement I was hoping for. In a persistent multi-agent setup, being able to distinguish “idle” from “delegated work is actively running” without manually polling the parent bot will make a significant difference.

I’ll also try the workaround you mentioned: asking the parent bot to attach the agent card whenever it delegates work, so Running / Done remains visible inline.

One additional related limitation I encountered during the same workflow may also be useful to the team:

A delegated Cloud Agent successfully generated a Human Review evidence package containing PNG screenshots inside its VM, but the parent bot was unable to retrieve those binary artifacts and attach them back into the parent conversation. We attempted an in-chat/base64 handoff, but it was truncated, and the parent bot reported that it had no available path to pull the generated artifacts from the child Cloud Agent VM.

So in my workflow:

child agent generates visual evidence successfully
→ parent orchestrator receives task/status callbacks
→ but the parent cannot necessarily collect and present the child agent’s visual artifacts to the human reviewer.

For multi-agent workflows, it would be extremely useful if files/screenshots produced by delegated Cloud Agents could return to the parent bot as first-class artifacts, similar to the status callback.

That would enable a workflow like:

Builder → Independent QA → evidence/screenshots → CEO/orchestrator → curated Human Review Package → Human PASS/FAIL

without requiring the human to open individual agent environments or manually retrieve artifacts.

Thanks again for the clarification, and I’m looking forward to the upcoming Grok Bot releases.

[Sanghoon_Kang]

Hi Colin — one follow-up issue from the same multi-agent workflow.

Since yesterday, my Grok Bot has been unable to launch a delegated Cloud Agent because of the following error:

ResourceExhausted — vttablet transaction pool connection limit exceeded

Latest Caller ID:
jqftxh24a9mn90ceno1y

This does not appear to be my plan usage limit.

I upgraded to Cursor Ultra ($200/month), and my current usage is still very low:

• Cursor Models: ~6% used
• Other Models: ~1% used
• Grok Bot weekly usage: ~5%
• On-demand spending: disabled

The workflow itself is ready and authorized, but the Cloud Agent cannot launch. We have retried at widely separated times, including again today, and the same ResourceExhausted / vttablet transaction pool error persists.

The parent/Builder correctly stops retrying and reports the task as PLATFORM BLOCKED, so there have been no repository changes or repeated retry loops.

Could you please confirm whether this is:

1. a Cursor-side Cloud Agent infrastructure/capacity issue,
2. an account/workspace concurrency or connection-pool limit,
3. or another Cloud Agent quota/limit that is separate from the Ultra usage shown in Plan & Usage?

If there is a way to inspect or reset the relevant Cloud Agent transaction pool for my account/workspace, that would also be very helpful.

The important distinction for me is whether I should simply wait for platform capacity to recover, or whether there is an account/workspace condition that needs intervention.

Thanks!

[Colin]

@Sanghoon_Kang Feel free to raise another thread instead of adding a bug report to a feature request.