Improve AI SDK - #126
Conversation
piiq
left a comment
There was a problem hiding this comment.
Hey, I've made 2 commits to clean up the markdown and add a link to the agents.json
There is the whole section that explains the client-side tool calls that IMO needs to be rewritten/simplified. Let me know your thought
| ## The Widget Data Flow | ||
|
|
||
| The SDK simplifies streaming responses by handling SSE formatting automatically. You can yield message chunks like this: | ||
| The most critical pattern in OpenBB agents is the widget data flow. This is a **pause-and-resume pattern** where your agent requests data and then waits for the Workspace to call back with results. |
There was a problem hiding this comment.
Hey, I think this section (especially Step 1) is very confusing. We're talking about client-side function calls where the AI agent is invoking a tool on the front end, but we're naming them "widget data flow" which in context of the workspace reads as something very different (i.e. how the widget is populated with data etc.)
In step 1 we are talking about "orchestration". What is that? TBF I can't explain what is meant to be meant here.
The "get_widget_data" is a tool that can be added to the tool list of the agent so that the agent can request this data.
Explaining that the agent execution loop needs to break once the request to the front-end has been made is needed, that's true. So we are on the right track here. I would just suggest avoiding adding additional terms and keeping it as simple as possible. The fact that we duplicate the same code multiple times (first as snippets then as a full example) actually doesn't help. More code to maintain and it will result in folks copy-pasting outdated stuff and being frustrated that things don't work.
piiq
left a comment
There was a problem hiding this comment.
This is a lot better compared to the "widget data flow thing". A LOT!
| ``` | ||
|
|
||
| **Related models:** | ||
| Use `request.widgets.primary` for widgets the user selected in chat and `request.widgets.secondary` for widgets already on the dashboard (when the dashboard features are enabled). The SDK formats the tool call for you—your only responsibility is to pause after yielding `get_widget_data` and handle the callback that arrives as a `tool` message. |
There was a problem hiding this comment.
Suggestion:
The SDK formats the tool call for you. Your only responsibility is ...
| - **`api_keys`** - Custom API keys from user | ||
| - **`workspace_options`** - Enabled feature flags (including custom ones) | ||
|
|
||
| ## Requesting Widget Data |
There was a problem hiding this comment.
I would maybe also mention that the same logic of tools being executed client side is true for mcp tools.
Also, maybe a bit more info on what happens that simply "pauses" since the connection is actually stopped and broken.
- Agent sends tool call/widget request
- Connection closes (breaking the stream)
- Frontend executes the requested tool call/widget request
- Frontend sends a new
POST /queryrequest with the result - Agent resumes streaming with the new context
Or point to the SDK readme where you have a good sequence diagram of this.
There was a problem hiding this comment.
Yeah, this is a good explanation @MagnusS0
This comment resonates with it OpenBB-finance/agents-for-openbb#84 (comment)
@MagnusS0 is this better?
I pointed to https://github.com/OpenBB-finance/openbb-ai/blob/main/openbb_ai/models.py in the end as I think that this makes it easier to look into the latest models.py file and it should be quite descriptive.
But if you have any better ideas here pls let me know!