Hi and welcome to this AI in C# video
on the Microsoft Agent framework.
Today we are going to cover the DevUI,
where we will give an introduction, meaning we
will only see what it can do and
later we will go into a bit more
real life scenarios, but more on that in
the end part of this video.
So inside the tool I put DevUI down
here, because I probably don't think there will
be more videos about it in terms of
new code, so I put it down here
so it's easy to take hold of and
in my case I'm using Azure OpenAI and
then using the new package here called DevUI.
So I think it's easier that I show
you the code first and then we will
talk about the end result of the code,
because this is a web API running normal
ASP.NET Core and once it runs we
end up with this website and this website
is a developer website, a little like Aspire
started out as a developer website, or something
that you don't release, but is something you
have doing testing and deployment and so on.
And what it can do is, we can
just talk to it, in this case it's
the comic guy from South Park, so we
can say, what is best, Star Trek or
Star Wars?
And for people who know the series, he's
very, very condescending, so we will get a
long answer back.
So what you can see is, you can
do a normal chatbot, you can get the
raw events from all the responses, you have
some traces that don't work, because this tool
is a port of something for Python, and
it is sort of ported over, but not
entirely ported over, it's a bit buggy still
in this traces part don't work, the tools
do, I can show that if I go
to another agent and say, what is the
weather like in Paris?
And we can see it made a tool
call, and we can see arguments in and
out of those tool calls and so on.
And this one talks like a pirate, so
let's just shut up.
But again, it is a bit not finished
for .NET yet, because this is not what
you do in .NET, and the deployment guide
talks about Docker and Python things, so it's
not really finished yet.
But the main part, which is the conversations
work, we can go in and see a
backend URL, which is also wrong, because that's
not the URL.
And all the things is more or less
Python-y, there's also a box like if
you press this button, it just fails.
And up here, it has a gallery that
is Python-only anyway.
But up here, there's some agents, so let's
see some code, why they are there, and
then let's dive back to it after the
fact.
So again, this is a normal web API,
and nothing special anywhere in app settings or
anything.
The only thing I have done is I've
taken the launch settings here, and went in
and said I want to run slash dev
UI whenever it starts up, else you would
need to do it manually.
So I said launch browser equals true, and
launch yourself the dev UI.
That's the only changes I've made here.
Then I make a normal web application builder,
and I make my Azure AI client, just
like normal.
Then in order for this to work, we
need to, in our builder services, add three
things.
We need to add the chat client, and
it's not a chat agent, it's the chat
client, so we go in and take our
normal chat client, and say Ichat client.
We then add the OpenAI responses API, and
the OpenAI conversations API.
And these two are just so this site
works.
The agents themselves use them through that, but
in real life, you don't need to.
And then you have this builder.addAIagents, where
you just give it a name, and you
give it a description, or instructions.
So in this case, it was the reason
why it was a comic require facade.
And then you can give it to tools
like this, but with AI tools, get weather.
Probably should increase this a bit.
I'm on the new, this is 2023, so
I'm back in defaults.
Let's do this so you can better see.
Then we can also, instead of building the
agent like this, I will come back to
why I feel this is wrong to do
this way.
You can still build real agents.
So just an agent, just like we do
normally with instructions, names, and tools.
The important thing is, it needs a name,
else it won't work.
And that name is the one it's being
registered by here.
Before, we saw it just used name and
instruction.
Now we're actually using name and a delegate
in order to create the agents.
So we get access to the service provider,
and we get access to the key.
And the reason for that is, behind the
scenes, if we go into the code that's
there written, is that it's just adding the
different agents as keyed singletons, meaning we have
the name to find the specific agent, and
that's what being used when we have the
Dropbox in the GUI.
In my case, I don't need anything extra,
and I don't need the key to set
it up, so I'm just adding my agent
here and giving it the same name both
places, else it wouldn't work.
Another thing we can do in this is
to have workflows up and running.
So in this case, we are building two
agents that are part of the workflow, a
French translator that translates any text that's given
into French, and a German translator.
And with such agents, you can, of course,
go in and build workflows, just like we've
seen up in the workflow.
Let's find the workflow.
There we have it, where we do the
Agentic workflows, the concurrent, sequential, and so on.
And that's exactly what I'm doing here.
So I'm just, from these builders, getting the
agents, so it's using dependency injection to get
the keyed service of that agent, and I'm
just putting those two agents into a build
sequential workflow, and a concurrent workflow.
Just the same agents to see two different
workflows.
Once we've done up with all the setup,
we can now go into building our web
application like normal.
And in development modes, of course, you could
technically do it out of development mode, but
I would not recommend that.
Again, more on that later.
We map our OpenAI responses, the AI conversations,
and the dev UI, which is the one
that actually makes it so the UI is
there.
And then we run the, down here is
our tool that the agents were given.
So if we do that and come back,
let's see a little more in details what's
going on.
So we can choose our agent up here,
and whenever we choose them, we can go
in and make multiple conversations with them.
And the real agent was behind the scenes
where we knew the other agent instead of
these add agent UI.
Then we have the French and the German
translator, and have them also as workflow sequentials
part.
And we can't get rid of these.
The reason that they are is that whenever
we do the workflow, we need to say
as AI agents, because if we don't do
that, the view I would not work.
So when I was making this demo, I
was trying to get rid of them here.
But apparently, I can't see how to get
rid of them, because I only want to
see them in the workflows.
But these are very simple and just underlying
features.
So if I say hello, it answers back
in French and so on.
So up here, the four here is not
really interesting, because that's just dumb agents.
And again, if I take one of these
and say hello, it will just say hello.
And then just after that, say Bonjour and
hello in German.
And I think there might be some issues
with using the workflows as we hear, because
they just come back in one go.
Technically correct, but that's the way they do
it.
But the workflows is perhaps one of the
most enticing features of this.
All this up here can perhaps be used
for some discovery and that's it.
I was almost about to say debugging, but
in my book, it's not really that.
But I will get to that in a
second.
But the workflows are down here, and they
are actually shown visually, which is really cool.
So if I take this sequential workflow that
takes my text when I say hello world,
it will then run it visually.
This is a quick one, but else it
would still spin here, then go to this
and spin and go to this and spin
and so on.
But we see that it come back and
say hello world in the French one and
hello world in German one.
And so this was a sequential where it
just run one at a time.
While if we took a concurrent, this is
actually how a concurrent look in real life.
In code, it's very simple to just say,
here's the agent.
But some batch concurrent nodes will be created
on the fly for you.
And if we run that again, we will
also see that it comes back and it
says, in this case, German and then French.
And you can actually get it to write
it in the different order because it's concurrent
and just works depending on who comes back
first.
Let's see if we can get it to
happen.
Yeah, so in this case, it was French,
German, French, German.
I have seen it the other way around.
Yeah, here it came that the German one
was faster in this case.
And so that also proved that a concurrent
one just runs concurrent.
And whenever someone come back, they are the
first output, which you, of course, need to
take care of.
So this is very much work in progress.
Again, there's various buttons that don't work.
There's sidebars here.
There's deployment guides that have nothing to do
with C Sharp.
Of course, all that will be fixed.
My more pressing concern in all this, when
I look at this code, is it's a
cool demo, but is there actually some scenarios
where that would in any way resemble real
life and for this to be useful?
Because if we look at this code, I'm
not making my agents up front.
That is simply not happening.
Because I often need the setup to be
dynamic on the fly that the user can
choose which model to use, which tool to
use.
I often have multiple agents that talk with
each other on the fly, building up the
instructions based on input data.
The input data in general is very long.
It's a lot of JSON and so on.
So, yes, I could go in here and
whenever I want to run in, put in
a very big JSON that I need to
construct and often don't have because it comes
from an external webhook or something like that.
Structured output, you cannot test.
Like 75% of all my outputs from
an AI is structured output.
But there is no way to tell that
because we are never ever running the runAsync
or runStreamingAsync where you tell AI needs structured
output.
So, we get a cool looking UI that
can do chatbots, but in my opinion, we're
not building chatbots so often.
That's already been done by ChatTBT.
So, I'm struggling a bit to see the
real value other than discovery, learning for the
first time how this works, what comes back,
what comes forward.
So, as I mentioned in the slide here,
to be continued, question mark.
I will try to see and force myself
in the real life scenario to see how
I can do this because how can I
make my AIs upfront with the data I
want upfront, with the output I want upfront
because I have not seen a way that
you can use DevUI in any other way
than building up the services at startup of
your code.
So, I might find something and there might
be a second video on this to figure
out how this actually is useful in real
-life production because, yes, just expose my agents,
but if they are not the same way
as my real agents in my applications, then
I'm just testing Hello World more than anything.
So, that's the reason why I've been a
bit hesitant to make this video, but I
honestly don't think I will use this much
state today.
But, again, cool demo and definitely a good
way to also tell others, hey, this is
how it works, this is how things run
and so on, visualising workflows the way you
can and so on because all the Python
stuff will, of course, slowly over time go
away and it will become a direct .NET
part.
But day-to-day, I would much more
rely on function calling middleware that I can
control and save in databases and stuff, the
raw HTTP calling if I want to see
what's going on.
But I might change my mind, especially when
I go and do more workflows in the
future.
That's the most enticing part to me, that
you can go in and see your workflows
like these and see them run because then
I at least just should give the input
because they will not have on-the-fly
input like the other ones.
But only time will tell.
I will definitely follow up.
But for now, cool party trick, but not
any real value to me at least.
So then, see you in the next one.