Allow to modify the name in Behavior Graph Debug panel & Potential not target to GameObject?

Context:
My project uses plain C# objects as behavior targets instead of GameObject.

Current Approach:
To bridge this gap, I’ve created a centralized GameObject with 100+ attached Behavior Agent components. (I attempted to manually bootstrap the Behavior Graph SO, but internal variables in the framework prevent external access. This forces me to rely on the Behavior Agent…)

Key Issue:
In the Behavior Graph debug panel, all agents shows the name of the Self GameObject, making it impossible to distinguish between individual behaviors during debugging.

Question:
Is there a way to override the debug display name for each Behavior Agent, rather than relying on the GameObject’s name?

btw, does the Unity behavior team have any plan to decouple the Behavior Graph and GameObject?

Hey, sorry but we don’t have a solution for this yet, however we’re working on better ways to choose which agent to debug.

We’ll need to add a way for you to register running agents without our BehaviorGraphAgent or GameObject if I’m reading your request correctly? And perhaps callbacks and API to set the active one for debugging?

Generally speaking, you can run the Graph directly like our BehaviorGraphAgent does, and I don’t believe we’re relying on the GameObject variable in our nodes, it’s just there for users’ convenience.

That will be good if we can not rely on GameObject or Monobehaviour stuff!, The callbacks & APIs will definitely make life easier!
also from my understanding, to support non-GameObject based agents, the Behavior Graph debug panel should indeed display runtime blackboard variables as a unified solution. Currently, variable inspection depends on the agent’s Inspector panel, which isn’t viable for agents not tied to GameObjects. Centralizing this in the debug tool should address the gap.
and this will be a ton of work? before that, will we have mitigated way?

While I understand that graphs can be run directly (as BehaviorGraphAgent does), the internal visibility of variables currently forces users to rely on reflection workarounds. Will we have a improvement for that?