Sub-messages flow problem

[franckdsf]

When an orchestrator agent triggers a sub-agent (photographer) as a tool call, the sub-agent’s internal tool calls and message updates are not saved as part of the same mutation cycle.
Instead, they are created and then later deleted and reinserted, causing major flickering and message duplication in the UI.

---

💡 Expected Behavior

• The orchestrator triggers the photographer as a tool call.
• The photographer executes its sub-tools, and all messages (both from the orchestrator and photographer) are recorded as part of a single message stream (or not, but at least, not merged at the end).
• Once the photographer is done, the orchestrator finalizes the result cleanly, without message re-creation or flickering.

---

🚫 Actual Behavior

1. The orchestrator starts handling the request via streamText.

2. It triggers the photographer tool → message saved as toolCall started.

3. A new message is generated for the photographer’s tool calls.

4. Once the photographer is done:

   • The orchestrator’s status is set to done.
   • All photographer messages are deleted.
   • The same photographer messages are re-saved as part of the orchestrator’s final message content.

Because these steps occur sequentially, each sub-step triggers its own render instead of being part of a single mutation.
This produces heavy UI flickering, duplicated data, and message jumps.
Additionally, the orchestrator’s “done” status appears before messages are merged, causing inconsistent intermediate states.

---

⚙️ Example Flow (expected vs actual)

Expected

1. Orchestrator handles request
2. Triggers photographer
3. Photographer triggers sub-tools (all messages saved under same message or own message)
4. Photographer returns result
5. Everything is tidy and clean

Actual

1. Orchestrator handles request
2. Triggers photographer (toolCall started)
3. Separate message chain created for photographer
4. Photographer completes
5. Orchestrator marked done
6. Photographer messages deleted & re-added → UI flickers

---

Notes / Possible Fix

It seems the issue stems from message synchronization happening after the orchestrator finalizes.
Maybe the orchestrator’s done status and message merging should occur within the same atomic mutation, ensuring the whole process updates in one go.

Currently, I’m working around this by:

• Hooking message merging at runtime when the orchestrator isn’t done yet. (since it produces an orchestrator message AND a photographer message at the same time).
• Debouncing the orchestrator’s done status until merging finishes...

However, that’s only a partial fix.