Welcome to our four hundredth episode of the
Microsoft Cloud IT Pro podcast
recorded live 04/21/2025.
This is a show about Microsoft three sixty
five and Azure from the perspective of IT
pros and end users, where we discuss a
topic or recent news and how it relates
to you.
This week, after eight years and 400 episodes,
Ben and Scott thought about doing something special
to celebrate this four hundredth episode, but instead
just decided to talk more about Copilot.
This time, discussing getting started with declarative agents
in Copilot Studio Agent Builder. They discuss everything
from getting started building agents to how you
might use them to licensing and costs.
Hope you enjoy episode number 400.
How was your weekend, Scott?
My weekend? Oh, it was
a a a quiet stay at home weekend.
I've still got a little bit of my
radio voice here as I get over my
my first spring cold or whatever is going
around. I've been getting over one for, like,
two weeks. So since I don't have my
notes up yet and they do not appear
to want to come up, what are we
gonna talk about today, Scott? What are you
gonna talk about today? Well, I try to
get my notes to load. What am I
gonna talk about today? Sure. Let's
let's have the guy who has no voice
be the one who talks a bunch of
well, today, we are going to
talk
about
no code declarative agents
and Copilot Studio Agent Builder,
if that's not a mouthful for you. But
effectively,
the little Copilot agents
that you can take and build for yourself
inside of Copilot
in a nice little
next next next GUI. Perfect.
Sounds good. And now my notes are coming
back to me. I'm well, in my head.
In my head, I have notes. So this
is something I've started playing with a little
bit. I've actually had clients start asking about
this too. So
this could be an interesting topic because even
I spent a bunch of time even deciphering
licensing around this. Like, even licensing around this
seems goofy to me. So I wanna build
an agent with no code. Where should I
start? Should we start with licensing, or should
we start with just how to start building
it? Why don't we start with how to
start building it, and then we can get
into
a little bit about licensing
and things like that as as we go
along. Sounds
good.
So starting to build it, there's a website.
So there's a couple ways, I guess, you
could start building this, can't you? There is
in Teams now or in Copilot, I guess
it's actually in the Copilot app, you have
agents
in the upper
right hand corner, and it looks like there's
already a few agents in there, potentially,
depending on what you set up, but you
also have a button up there to just
click on build an agent. It turns out
that you've probably been interacting with these in
some way, shape, or form, and you just
might not have noticed. So
there's things like a prompt coach. So you
you wanna get better at writing prompts, you
can go down that path and work with
those.
There's a generic writing coach.
There's all sorts of just
built in agents
that are
ready to ready to go for you should
you want to use them. And then you
can build out your own agents on top
of those and leverage the connectors within
your organization.
So
why would you want to
build your own agent? Well, like, there there's
a whole bunch of things that you can
do
within even, like, our world and and our
roles and and the things that happen. So
for you, I could think about maybe,
hey. I would like to build the
the the the project knowledge bot for IntelliJunk,
and you wanna point it at maybe your
document
repository
for where you've done things like your SAUs
or you have artifacts from deliveries, things like
that. Like, teach me about past things and
help me make this next one better. You
could also build probably a pretty good, like,
SAU bot, like a statement of work agent
based on statements work and things like that
that are out there. I've been taking these
and building these.
So part of my role involves working with
products that are released on GitHub,
and all the code lives on GitHub, the
releases, the wikis for these things. So I've
been using them within my organization where the
GitHub connector is turned on to point directly
at Git repos
and get insights on
not only the
the repos themselves, but also the the code
within those repos.
So I'll give you an example. We have
a
product that gets distributed to customers. It gets
compiled and and pushed out. That product has
a bunch of
hidden flags inside of it. And those hidden
flags are they're they're sitting there in the
code if you know where they are, but
I don't always remember, like, which file to
go into at which time to look up
which code.
So
enter my little my little product helper agent
that can tell me those things. And then
it can also maybe be augmented with documentation
from internal wikis, SharePoint,
things like that as well. So
these become powerful little helpers
against your knowledge bases. So you can effectively
think about it as a or the way
I think about it is a very quick
onboarding,
no code flow
to be able to
leverage
RAG, retrieval augmented generation.
So RAG with my own documentation, my own
code basis, things like that, to ground these
models
and further refine the responses before they spit
some stuff back over the fence to me.
Me. Yeah. And I think even the part
you brought up there about, like, looking at
GitHub is
it's also a way to
bring in some of that additional
context
or
refine these Copilot agents or build these agents
to look at other data sources. Like, as
you go into these Copilot agents, it's not
just I wanna go look at this specific
SharePoint site or
look at
this specific,
I guess, context for the Microsoft three sixty
five. It's go pull in data from
GitHub. Let's go look
at Confluence wikis. Let's go look at Trello
boards. Let's go look at a SQL database.
There's lots of other date or this allows
you to build these agents that are not
only just specific, but also pull in data
from a lot of other data sources
to,
help with these Copilot responses, these
conversations
you have with Copilot.
Yes.
So
I I I think, like, there there's a
world where
some of this stuff can get more complicated,
and you can go down a path of
needing
to actually build an agent
and do some code around it. And then
there is the
Copilot agent studio
experience, which is
zero code, super easy to onboard. So you're
kinda getting out of the world of those
more traditional
language bots
that are gonna require some measure of I
don't wanna say, like, extensive coding, but they're
gonna require some knowledge
and things to get in there versus these
things, which are
declarative. Like, you just go in and and
and declare what you want
via the Copilot agent studio, and then it
effectively
ends up in this what you define is
what you get kind kind of
bot that that's out there. The other cool
thing is because
it's all built on top of m three
sixty five Copilot,
if you think about things that you might
want
in
a workflow
so let's take, like, kinda like one of
the easier examples. So employee onboarding. So when
I do a new hire for an employee,
there's typically a slew of documents that employees
need to sign when they come in, like
get this going, get this going, get this
going kinds of things.
There's probably also, like, security groups they need
to sign up for. There might be
meeting series that they need to be a
part of, like an all hands, things like
that. So you could build an agent that
has those assets inside of it,
like, point it to your HR onboarding documents,
have a baked prompt in there, a system
prompt that you've already worked on, and and
you've kind of gotten to where it needs
to be. And you could do that across
a series of system prompts that are baked
into that agent and augmented with the data
that you need for your onboarding process, and
you could just make that employee onboarding super
easy to do right there.
And then if there's even things that you
wanna do outside
of just
retrieval augmented generation, like, with documents that are
sitting, like, in SharePoint or, like, my example
would, like, GitHub, things like that, Because this
is m three sixty five Copilot, and it's
connected to the rest of your data sources,
like,
if if I'm chatting with that agent, that's
my team's chats, that's
my mail sitting in my mailbox kinda thing.
You can also bake those system prompts so
that they further go out and spider and
get information from those sources as well. So
not just go get the HR doc, but
or go get the blah blah blah project
start doc, but maybe go back through my
mail and look at the last five projects
I did and help me write up my,
introduction for this one kinda thing. Absolutely. And
as you're going to build these, like, there's
a few different steps once you go in
here to build these agents. So we've kinda
talked about, like, what you can do with
them. I think the fascinating part is when
you go in to build these agents, like,
you click on that. Like you said, you
go to the the agent builder, and the
first thing you do is you actually use
Copilot to try to build the agent. Like,
it'll ask you,
what do you wanna do with this agent?
What are you trying to accomplish with this?
And you can just type in what you
wanna build to get started building these agents.
So you'll actually see the system agents in
there, So, like, that prompt coach, things like
that. So you can get a sense not
for, like, how those are built if you're
looking for a little bit of information there.
The the docs are pretty good here as
well about kinda giving grounding and and what
each of the options are that are available
to you. But it is kind of just
as easy, like, licensing aside.
Once you've got the ability to create these
things, it's literally just go to Copilot, and
that could be Copilot the app, the m
m three sixty five Copilot, whatever the business
one is. Like, it's pinned to your desktop
automatically in most cases,
you've got that one, or you can just
go to office.com/shop.
And
right up there in the upper right, like
you said, you've got your list of kinda
system agents, and then you can just go
ahead and build a new agent right on
top of that. So you just go ahead
and click create agent, and then you're kinda
off to the races
from there. So it it's it's meant to
be
super
quick. Like so so that agent builder is
there to kinda show you the template, show
you what can be done, get you through
that creation process
pretty quickly,
and then get you to publish and then
maybe come back and and make updates and
refine and things like that as you go.
Yeah. And those different things. So once you
do that, you get your agent built or
as a process of building it, if you
wanna add different things,
it is. It's going in, giving it a
name. Like you said, this could be the
internal knowledge base. This could be
employee onboarding,
give it a quick description, and then you
can give instructions
for your agent too. So this is, like
you said, how you direct the behavior of
this agent, different tasks, how it's supposed to
complete different tasks,
but all those prompts around
how it builds agents,
and then it gets into that other thing
we said, the knowledge.
Where is this agent gonna start looking for
stuff? Is it gonna look in
SharePoint? Is it gonna look at a public
website? Is it gonna look at a SQL
database?
Adding all those different sources
into your agent,
and then even some starter prompts. So you
can go in and add some number of
starter prompts for your
different users so that
you can help them get started with the
agent, help them figure it out. But it
really is. It's just that GUI
work through the
different
the different steps in it to really refine
that knowledge, instructions,
even capabilities. Is it gonna have a code
interpreter, image generator as a part of it,
and then what those starter prompts are? And
then you just hit publish, and it'll be
there to start using, and then you can
go in and tweak it, refine it, configure
it as you go. Some of that stuff's
relatively
new or it kinda, like,
evergreen SaaS product. Right? It's always changing underneath
you kinda thing. So some of those connectors
that are available like, I noticed, like, in
my organization,
like, on day one, the number of
pre enabled
Microsoft Graph connectors
was pretty
low, like, low to nonexistence.
And now there's a whole bunch of them
in there, things like connecting to ADO, connecting
to
the ServiceNow, connecting to SAP. Like, there's a
whole bunch of them that have just been
added in there, and then some of those
capabilities you talked about. So
code interpreter is an interesting one.
It uses
Python
in the background
to analyze data that's being input by users.
So maybe if you're, like, trying to build
an agent where you're trying to have the
agent help you solve a math problem, things
like that, That's where the the code interpreter
comes into play. And then the image generator,
just image generation one zero one, and I
think the things that folks are probably used
to from from seeing most of these systems.
You do have to keep in the back
of your head that this is all built
on m three sixty five Copilot,
so it's going to kinda behave like m
three sixty five Copilot.
And the reason I call that out is,
like, image generation and, like,
just chat GPT
versus, I don't know, maybe going out and
using, like, stable diffusion OSS versus
mid journey versus Copilot are all very different.
And they all have their kinda baked in
system prompts along the way and and their
own flavors, so you can't override some of
that stuff. Like, I don't know, maybe there's,
like, a prompt injection thing or something. But
for the most part, like, yeah, I'm I'm
not hacking away at these things like that.
So you can't override them. Right? You kinda
live with the outputs
in some cases that those systems give you.
Yeah. And I noticed even with setting up
these connectors to your point of different ones
showing up, even setting them up, I was
working through some of the documentation the other
day, and they're even set up a little
it's interesting how you set them up. Well,
how about that?
It's not necessarily straightforward as I thought. Like,
I can go into mine right now when
I see
just one of those knowledge sources. And I
was going in and trying to figure out
how to add more, and you can, like,
click to add more knowledge sources and you
see them there, but you can't really add
them. It's like you have to go connect
to them first. And you actually have to
go into, like, your Microsoft three sixty five
admin and go into the search settings
in Microsoft three sixty five admin and go
configure these additional
sources
in your Microsoft three sixty five search setting,
and that's where you set up these connectors
that can then be used in Copilot Studio
to add those additional
or that additional context, those additional knowledge sources
to Copilot Studio. So there is a little
bit of that. I mean, that's how it
works under the covers. Right? Like, if you're
gonna exclude something from Copilot using sensitivity labels,
you also exclude it from Microsoft Search. End
of the day, from all this different knowledge
that gets pulled into Copilot, it's very heavily
using the Microsoft three sixty five search under
the covers for everything from connectors to pulling
your Microsoft three sixty five data. Yes. Search
plus. So so it depends. Sometimes it's using
the
existing indices that are already there. Like like,
hey. They're all ready to go. In the
other cases,
it's
let's take, like, a graph connector, for example.
So you go and configure a graph connector
for
for a ADO kinda thing. Part of that
experience of turning that on is actually not
only lighting up the connector, but, like you
said, lighting it up to search, and then
not only lighting it up to search, like,
just from the top level of saying, like,
oh, it's enabled within m three sixty five
search. It's also going so far as to
do things like
enabling your connectors for inline results.
So you're gonna go through, like, your search
verticals and make sure that they're enabled
up up where they need to be that
way. So, like, it is, like, embedded in
there. So I think you do have to
think about it a little holistically if, like,
before you turn this stuff on. Like, you're
not just to your point exposing it to,
Copilot. You're exposing it to search,
and you're kinda built in search experience. But
then it's still security trimmed, all that kind
of
stuff
around me. Do you feel overwhelmed by trying
to manage your Office three sixty five environment?
Are you facing unexpected issues that disrupt your
company's productivity? Intelligink is here to help. Much
like you take your car to the mechanic
that has specialized knowledge on how to best
keep your car running, Intelligink helps you with
your Microsoft cloud environment because that's their expertise.
Intelligink keeps up with the latest updates in
the Microsoft cloud to help keep your business
running smoothly and ahead of the curve. Whether
you are a small organization with just a
few users up to an organization of several
thousand employees,
they want to partner with you to implement
and administer your Microsoft Cloud technology.
Visit them at inteligync.com/podcast.
That's intelligink.com/podcast
for more information or to schedule a thirty
minute call to get started with them today.
Remember, Intelligink
focuses on the Microsoft cloud so you can
focus on your business.
I would say the other interesting thing I
was talking to a client about this the
other day, and they got all excited when
I mentioned public websites as a data source.
This is not just any public website. I
cannot go point this to, like, learn.microsoft.com
and have that be a knowledge source source
for my bot. Like, you have to confirm
this is a website you own, DNS records,
all that good stuff with public websites. That
was a funny example for me because I
can build declarative agents. You can burn learn.
Okay. Yeah.
Look at me. I'm special. I can use
learn.Microsoft
for my agents. Yeah. There we go.
No. I'm not coming up with another example.
But I also know that because I've I've
played with this even with search, like, pointing
the Microsoft three sixty five search to my
own website is there's also limits on search
and how much you can crawl with search
before you have to start paying. So we
haven't talked about licensing Copilot Studio yet, but
I think depending on these agents and how
they interact with search, there could potentially
be some additional
cost considerations
there because
you start running into limits on what search
can actually
go
pull access based on licensing, etcetera, from things
like public websites. So it does start to
kinda run away a little bit, like, once
you start to light up all the
all all all the little options that are
available for you. So
graph connectors,
they do require a license or some kind
of meter usage.
SharePoint, obvious, you gotta have a license to
SharePoint, OneDrive, things like that.
Web search, funny enough, does not require a
license,
but scoped web search does.
So you gotta kinda think through maybe a
little bit of nuance there. And then there's
some things that are outside the agent builder,
but they're available through
Teams and and building declarative agents in Teams.
So things like a Dataverse connector for your
dynamic CRM data,
email people, Teams messages. That that stuff's all
part of the Teams toolkit,
and then that all requires licensing as well.
So
it it it can be, it can be
a thing. So why why don't we talk
through some of
the other
licensing constraints here? Because you mentioned Copilot Studio,
and there there is some stuff to do
there. It's interesting how they license it. And
I don't know that I would say the
documentation is clear. Imagine that. Right? Yeah. I'm
shocked. Yeah. So there's three different ways
based on all the reading through the documentation
and looking at this that I did that
you can license Copilot Studio to go build
these agents. And it's not it's not actually
like you're licensing Copilot Studio. It's more like
you're licensing the interaction of your users with
these agents, but it falls under this Copilot
Studio license
umbrella. So first, you have your pay as
you go option. So I wanna go build
an agent. I want my users to be
able to use it, but I just want
to pay when they use it. And this
is where you go
set up a PayGo connection,
and it is 1¢
per message
for licensing
or leveraging these agents. And I'm gonna come
back to messages here in a little bit.
Then you can also buy message packs. So
instead of paying on a
per message
basis,
you can go buy a message pack for
$200
per tenant per month. And this essentially gives
you pooled messages. And if I remember right,
I think it's 10,000
messages
no. 25,000
messages
in that $200 plan. So now 200
a month, you're buying 25,000
messages that you can use within your company.
And as users use it, it will deduct
from
this message pool. And then the other way
is you already have Microsoft three sixty five
Copilot,
the $30 per user per month plan,
and then your Copilot Studio is just included
within that $30
per user per month. It's kinda sort of
included. So so some of the limits you're
talking about, like, you're talking about message inclusion.
Yep. PAYGo is PAYGo. Like you mentioned, the
message packs come in 25,000
message
increments
or Copilot Studio with m three sixty five
Copilot unlimited.
But that's just for the messages component. It's
it's a little weird to say
that it comes with everything because the the
one thing that
stands out that Copilot Studio
usage rights when you're using Microsoft three sixty
five Copilot,
oh my gosh. It's a mouthful,
is that you are not allowed to create
and publish your own agents anywhere.
So with that PAYGo and with that message
pack model, you can absolutely create and publish.
But with the Copilot studio usage rights, you
can't publish them anywhere. They're only within your
tenant and your users, that that kind of
thing. So
you you do have to decide, like, what
kind of business you're in and and what
the ultimate, like, intention is for these things
along the way. There's some other things as
well that change around, like, the channels you
can publish in and and stuff like that.
Generally speaking, like, that Copilot
Studio usage rates, because you're already a
Microsoft three sixty five Copilot
subscriber,
that's going to give you, like, your most
bang for your buck across all of these
things that are out there. Well and I
don't think so you mentioned building them in
Copilot Studio. There's a table. We'll link to
this in the show notes. It actually says,
like, create and publish your own agents anywhere.
It's like it's weird because Copilot message packs
and PAYGo, it's included.
Studio, it's not included. But create and publish
your own agents and plugins to extend Microsoft
three sixty five, it's not included with Studio,
PAYGo, or message packs, but it is included
with the $30 a month plan. So they,
like, flip flop. Well, there's an unwritten word
that you have to extend in. So create
and publish your own agents and plugins to
extend Microsoft three sixty five Copilot
in your tenant. Yeah. So it kinda becomes
in your tenant versus multi tenant. Versus anywhere.
Yeah. So, like, if you were a builder
and you wanted to build and deploy an
agent across multiple tenants, then you you might
be in one of the other kinda
one of the other buckets there. So it's
it's weird when they talk about extensibility
that way, but it's really, like,
extensibility
within your tenant
is is the way that I I think
about it in my head. You'll look at
it there. Yeah. And then we talked about
messages. This is the other thing that you
need to be aware of is you may
think messages is
I send the agent a message. I ask
it a question is a message. Kinda like
maybe you'd chat in Teams and you'd send
someone a message.
But different
actions
in
Copilot
count for different messages. It's like another one
of Microsoft's weird, we're gonna use this to
measure your usage without really
making it clear
how that's what that unit is.
So in the billing rate table, and we
can throw this out there, like, a classic
answer is one message. So maybe that's where
this started is I asked Coppola the question,
it gives me a classic answer, that's a
message. But if now I'm doing a generative
answer, it's two messages. If I'm doing an
agent action, it's five messages. If I'm sending
agent flow actions,
it's 13 messages per every 100 actions.
Text and generative AI is a message, but
text and generative
or basic
is
per 10 responses
as one message. But if you're doing text
and generative
AI tools premium,
it's a hundred messages per 10 responses.
So this is, I feel like, definitely a
little bit more of an art than a
science, and you could have some
huge fluctuations,
I would say, in some of this PAYGo
pricing or your message pools
based
on how you're allowing your users to leverage
Copilot within these agents that you build. I
mean, Happy Path is certainly, like, you've picked
up m three sixty five Copilot like you
talked about. Right. The $30 per user per
month or or whatever number that eventually ends
up being.
And and and you've gone down that rabbit
hole, but that's happy path. Like, to your
point, not everybody's in the happy path. And
some of this stuff is a little confusing.
Like, really, when they're talking about messages, they're
talking about tokens. Like, as much as I
hate talking about tokens and context windows with
LLMs,
at least, like, token makes sense to me.
Right? Or you could say, like, fuel up.
Like, hey. I'm I'm going to
in The US, we have, like, Dave and
Buster's, and you're gonna go refill your party
cards so you can go hit more video
games. Same kinda thing. Right? Let let me
go let me go fill up my card
with tokens, and then boom, I'm gonna go
spend 25
tokens to play this game. Or same kinda
thing here. I'm gonna spend one token
to to to generate an answer. I I
think you do have to understand a little
bit about
your patterns for these things and and how
they come across and and plan for them.
So
the the the things here that start to
get you
are the
agent to agent actions. So, like, if you're
autonomously executing agents or you're having one agent
interact with another one, like, great. That's five
tokens.
The other one is the graph grounding stuff.
It can hit you.
So you're saying, okay. Hey. I'm I'm hooked
up to my tenant graph, like Microsoft Graph,
and I've I've turned on these connectors to
extend
Copilot within my tenant. Well, that stuff starts
to get expensive as well. And then from
there, you might actually wanna, like, turn things
off. Like, you might not want to allow
for, like, generative images because of the high
cost and and the tokens associated with them.
Yeah. It is
definitely
something to be careful of, and I would
say I've I've started having conversations too is
looking at how much you expect or where
you start. I would say even the message
packs. I did the math here quick a
minute. If you're buying 25,000
messages for $200,
you're only spending
0.02¢
per message less. So as opposed to the
PAYGo for 1¢,
if you buy a message pack, you're spending
0.8¢
per message. I was talking to a client
about this the other day. I'm like, just
start with PayGo. Use PayGo until you hit
essentially $200.
Once if your PayGo is consistently
$200 a month, then maybe you switch to
the message packs, and you essentially pay the
same amount, and you get a few bonus
messages. But I don't know that there's a
lot of benefit to necessarily starting with message
packs unless you're a huge organization,
but you're just gonna blow through messages and
you're like, yeah, we're gonna be spending a
thousand, 2 thousand dollars a month. PAYGo makes
sense. Or like you said, in a happy
world, you're just licensing Microsoft three sixty five,
getting the $30 a month license. Yeah. You'll
look at the cost. Maybe you only have
five or six users in your organization.
Buying six $30 licenses a month is still
still cheaper than $200 a month for message
pack. So really looking at users usage, where
do you wanna start with this when you're
getting into some of that
pricing and
trying some of this stuff out? So you
probably want PayGo there anyway,
at least if you're doing the
the the,
sorry, the
the consumption
or or you're doing kind of the the
bigger
messaging packs that you talked about. Like, hey.
If you buy 25,000,
you're probably gonna wanna PAYGo to bump up
behind it anyway. So you're gonna go and
configure all that stuff on the Azure side.
Like, it's it's it's a little weird the
way it happens too because you end up
taking what's effectively
a
an a linked environment from Power Platform and
bringing that over to Azure, and then that's
your you you end up with this weird
linked billing construct. Like, yeah, you can go
into the Azure portal, and you can see
Copilot Studio, but and your, like, message consumption,
but then there's other stuff going on over
in PowerPlat.
And you have to maintain that connection too.
Like, if you take that connection away, then
the billing relationship is severed. It's it's a
little weird still, the the way it gets
wired up. Anything else? You've been talking. We've
been talking for thirty minutes.
You're getting over your cold. You're starting to
lose your voice, Scott. You still have your
entire week to go. Anything else you wanna
touch on before we wrap up for day
and you wrap up for today, can you
give your voice a little break before you
dive into all your meetings? So I think
a couple of things. Maybe just some, like,
high level tips and tricks and and things
to keep in mind. So one is
design with
when when you're building one of these things,
you kinda have to decide, am I building
it for myself? Am I building it for
my team? Am I building it for a
wider audience?
So as you're going down that path and
you kinda understand your audience and who you're
building for, that'll help you do better grounding
in your instructions,
maybe your
your your preprovided
prompts, things like that.
You do have to think through maintaining your
knowledge sources.
So, obviously, like graph connectors, things like that,
they can be a little bit more evergreen.
But say you had augmented with some documentation
that you dropped in a SharePoint site and
that documentation changes over time, you've gotta remember
to go back and update that documentation,
and keep dropping it in there and landing
it in that place, and potentially
updating
and
refining the prompts within your agent to make
it work with that new data.
The other thing to think about is who
you publish your agents to. So I've I've
seen this, like, at least within, like, the
stuff that I've done, and and, like, I've
built some stuff for myself, some stuff for
our team. And all of a sudden, somebody
will come back to me and they'll say,
like, oh, hey. I was showing off your
blah blah blah to a friend, and and
they wanted access to it. I'm like, well,
they really shouldn't have access to it because
it's our agent. It's, like, for our team,
and it goes around just this subset of
data. Right? Like, back to that, if you
built the statement of work thing for yourself,
you're probably not gonna give that to every
person in your organization. It'll be for you
and a select set of salespeople and things
like that to to to go drive that
through. And then finally,
these are
still
nondeterministic
systems.
They're gonna have wonky answers sometimes.
They're gonna hallucinate. They're they're they're gonna need
refinement, all that kind of stuff. So as
you publish these out, particularly for anything that
you publish that goes beyond the scope of
you, whether that goes to a team of
two, a team of 10,
or your entire company, like, it doesn't matter,
you should be prepared to kinda take feedback
and iterate on that feedback and and republish
these things occasionally
so that they can pick up the new
capabilities. Like, maybe your tenant admin went in
and added a bunch of new graph connectors,
or you're just on that kinda journey of
of continuous improvement with those. Like, I have
found that to be important. Like, you can't
just often do the wrong appeal, set it
and forget it kinda thing. You do have
to kinda come back, care, feed,
water, and and make sure that your garden's
flourishing. % increase or change those instructions. Your
point is data's changing too. You may have
to go update the instructions
to your
agent.
I would say even knowing
you have to know where these agents are
pulling data from because the other thing is
you don't want somebody in your company
to go drop a particular document in a
document library
and a particular SharePoint site, publish a particular
article
in Confluence,
and not realize that there's an agent that's
open to the whole company that's pointing at
this, or there's all that
security compliance governance stuff to think about as
well because now you may have these agents
pointed at very specific spots and allow it
it's like almost allowing your employees to know
where different agents are pulling data from so
they can be cognizant of that as they're
updating data. It is a consideration because one
of the things you can do is you
can take an agent, and because you have
access to the SharePoint site, you can point
it over to that SharePoint site. And I
haven't seen
at least in I don't know. I'd have
to play around with it. I don't know
if everybody that I've shared some of these
things with actually has access to the SharePoint
site or if it's SharePoint or the agent
or like, it's a little weird in my
head, right, for how it all ties together.
I would think at least for SharePoint, it's
going to be using it's gonna respect permissions.
Like, if I have permission to the SharePoint
One would think. One would think. But other
sources, like maybe a SQL database
or a Confluence page or something like that
or, again, you drop it.
Yeah. It's
it's definitely something to be aware of. We'll
leave it at that. I'll have to go
play with that one, Scott, because I'm definitely
making some assumptions there. I am too. But
SharePoint permissions tend to be pretty wide and
open no matter how much you want them
to be locked down. So that's why I
don't know if it's a me thing, if
it's a SharePoint thing, or if it's an
agent thing. Or a combination of all of
those. Yes. Or all of the above, for
sure. We'll throw a bunch of links in
the show notes about
all the licensing stuff, steps for building these,
hooking up different,
different data sources,
all of that. So it would be interesting
too, Scott, to hear how other people have
used agents, what they've built. And I know
I'm starting to build some. Like, I'm working
on building an internal knowledge base one for
me where I can look at different solutions,
documentation,
all of that we've created for clients. But,
yeah, hearing how other people are using agents
as well, reaching out to us on the
socials or any of that and having some
discussion out there on agents and usage around
it. For sure. Awesome. Well, thanks, Scott. Go
get better. Go drink some more tea. Try
to let other people talk in all your
meetings this week, and we will talk to
you again soon. Alright. Sounds good. Thanks, Beth.
If you enjoyed the podcast, go leave us
a five star rating in iTunes. It helps
to get the word out so more IT
pros can learn about Office three sixty five
and Azure.
If you have any questions you want us
to address on the show or feedback about
the show, feel free to reach out via
our website, Twitter, or Facebook.
Thanks again for listening, and have a great
day.