You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
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
Beta Was this translation helpful? Give feedback.
All reactions