Add the Strands Integration to AG-UI

[UmarMajeed-Rana]

Closes #35

• Implement StrandsAgent wrapper for AG-UI protocol
• Add example agents (agentic_chat, backend_tool_rendering, agentic_generative_ui, shared_state)

[liorheber]

Thank you very much for pushing this!

I'm wondering if a wrapper pattern for Strands makes sense here vs. something like the callback handler they have there.
The reason I'm asking is that it's not clear to me how multi strands agents (swarm, graph, etc.) would work this way, along with persisting streams and messages while the client is not connected, and overall non http based communication (e.g. through some messages queue).

Do you have any insights on these patterns?

[NathanTarbert]

@UmarMajeed-Rana, I know you're making good progress, any thoughts regarding @liorheber's question?

[UmarMajeed-Rana]

@liorheber @NathanTarbert Right now the Strands integration is intentionally “just” a wrapper around agent.stream_async(...), because that’s the quickest way to make Strands agents behave like every other AG‑UI integration: you drop in a StrandsAgent, point create_strands_app at it, and you get the standard SSE stream with PredictState support, tool snapshots, etc. That covers most of the current Dojo/demo scenarios, where a single Strands agent produces one stream and the HTTP client stays connected.

• Your concerns are valid, though, and they’re the reason I have added configurable tool behavior, PredictState mappings, etc.
• For multi-agent swarms, persisted streams, or non-HTTP transports we’ll layer in an event-translator/callback handler (similar to the ADK middleware). The plan is to register Strands’ hooks inside the wrapper, feed them through a translator/queue, and keep the simple API while gaining the richer metadata + transport flexibility you’re looking for.

Thank you very much for pushing this!

I'm wondering if a wrapper pattern for Strands makes sense here vs. something like the callback handler they have there. The reason I'm asking is that it's not clear to me how multi strands agents (swarm, graph, etc.) would work this way, along with persisting streams and messages while the client is not connected, and overall non http based communication (e.g. through some messages queue).

Do you have any insights on these patterns?

[NathanTarbert]

This is awesome @UmarMajeed-Rana!