BeeAI
Replies: 2 comments 4 replies
-
|
cc: @anafucs can you help the images above when you get a chance? Screenshots of the not-so-happy path we have now in the handoff GUI and of the happy paths we had in the opinionated implementation and/or in designs? |
Beta Was this translation helpful? Give feedback.
-
|
As I've been thinking about this, I think this discussion is the right place to try to understand how backend agent servers should share an opinionated view of their data models and the corresponding UI elements that a GUI can/should surface based on that data model. On the one extreme, an agent server could simply surface a url for its GUI and expect clients to access it or embed it as an
On the other hand, drawing a strict boundary around the set of components an agent server can leverage in a UI will make for a significant innovation bottleneck where individual agents that want to deviate from the set of prescribed components will first need to work through changing the central data model before being able to surface their UIs. I think a middle ground would be to take inspiration from the idea of a |
Beta Was this translation helpful? Give feedback.
-
|
I love this model. There are no-brainer first-class resources: agent-message, user-messages, citation, CoT, file/artifact etc. what we can be opinionated about and provide a useful out-of-the-box abstraction. Then it's choose your own adventure. |
Beta Was this translation helpful? Give feedback.
-
|
cc: @JanPokorny as it relates to #473 |
Beta Was this translation helpful? Give feedback.
-
|
@gabe-l-hart We had a similar iframe-based model in mind. If you fully sandbox it, and use only postMessage to communicate, it's as safe as any regular webpage. We actually already did this with the Bee App Builder aka app🐝lder, which builds and runs apps in the browser. Regarding custom UIs, I'm not entirely sure if they're a right thing to do, though... We're building agents, and agents are supposed to talk by exchanging messages. Allowing for arbitrary UIs means that you could just implement anything, like a Flappy Bird clone and call it an "agent". The platform already needs to make some assumptions on what an agent is and how it communicates, in order to be able to orchestrate workflows. The idea with custom components is interesting. We could offer a library of components and let agents define custom components (iframed), like in Streamlit. |
Beta Was this translation helpful? Give feedback.
-
|
@JanPokorny I agree. We can pull back from arbitrary UIs and just think about common components. These represent repeatable patterns in human <> agent interaction that go beyond the message. I think we're all pretty much settling on the first set being:
|
Beta Was this translation helpful? Give feedback.
-
Motivation
Agentic behavior moves us beyond simple LLM-powered chat, where the primary
componentsare user message and assistant message. We need to define an official set and a mechanism for identifying them and handling them. A salient "client" for this abstraction/designation is the GUI, but any interface with an agent (agent-to-agent) will benefit from our ability to tag/identify these components and decide how to treat them.Examples
BeeAI handoff GUI with mashup of agent message, artifact, and sources:
CoT, sources, artifacts handled distinctly (drafts for canvas or inline):
Components
Priority components to solve for are
When building an opinionated system with a single agent powering it, the developer has the ability to control this and handle it across the stack. When handling multiple languages, frameworks, models, and prompting strategies, it becomes a challenge to standardize this.
For discussion
Beta Was this translation helpful? Give feedback.
All reactions