Abstractions vs Discoverability Thoughts? #1702
Rasmus Wulff Jensen (rwjdk)
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi AF Team.
First up, thank you for an awesome new framework. It feels lean and easy to get going with this new setup 👍👍👍
Digging deeper, however, I would like to hear your and others' opinions on Abstraction vs discoverability balance in the Framework.
It is clear that the Framework aims to be LLM Independent (the abstraction), but as one goes deeper into the features, this abstraction seems to come at a cost of discoverability.. Let me give a few examples of what I'm trying to say:
Example 1 - AgentThread
When we get a new AgentThread, there are no properties on it at all

... you need to know that a thread can be a ChatClientAgentThread and cast to such

I know this is just normal .NET Abstraction, but to someone starting to use this, the discoverability is low.
Example 2 - AIAgent
When you have a ChatClientAgent you have 3 options to "Run" (RunAsync(), RunAsync<>() and RunStreamingAsync())

...but if you add some Middleware, it is "suddenly" not a ChatClientAgent anymore


, but an AIAgent du not have .RunAsync<>() for structured output
Again, I completely understand why this is from a technical standpoint, but my question is:
"Is this too abstract and will hurt adoption of the Framework?"
Has this been part of the design discussions, and are there plans in the team to introduce more discoverability (optional extension methods and further, more opinionated wrappers around AF (example: one opinionated package that is optimized for OpenAI and one that is optimized for example Google Gemeni?)... or do you see this as the work of a Community Toolkit / 3rd party Nugets / the individual developer using the Framework
All reactions