Building your Agent with Microsoft Frontier Tools
In this article
Creating agents within the Microsoft platform
Within the Microsoft ecosystem there are several ways to create an agent, from a no-code Agent Builder within Copilot to a full coding experience via integration into Microsoft Foundry. In this article we define the correct Agent path, review how an Agent is created, walk through the Agent build process, as well as the design and governance choices that allow safe agent publishing within the environment.
Start with the Overall Vision, not the Tool
The most common mistake within an agent project is leading with tool selection. It's imperative that you start by identifying the job the Agent is expected to accomplish. Start this journey by defining how the agent helps and what the expectations are.
Here are some examples of positive and negative use cases for Agent definition:
| Good candidate | Poor candidate |
| A well-defined job with clear inputs and outputs | A general assistant for anything |
| Content that is current, owned and already shared with the right people | Content that is old, ownerless or shared with everyone |
| Low consequence if the answer is wrong, or a human reviews every action | Irreversible actions with no review |
| A result you can measure | No way to tell whether it helped |
Well-suited use cases:
- Project briefing assistant that answers inquiries from a project folder within SharePoint
- Policy assistant focused on two current document locations to provide assistance
- A site visit scheduler that drafts replies and proposes calendar events
Examples that need much more care to deploy:
- Anything that interacts directly with customers
- Agents that participate in financial transactions like moving money or scheduling payments
- Agents that automatically make critical updates like changing access without human approval
The Agent AI Build Path
Microsoft describes multiple use cases, from using agents that already exist to building your own with code.
Each step adds capability and responsibility within the organization.
| Path | Who it suits | What it is | Strengths and limits |
| Built-in agents | Any Copilot user | Agents Microsoft ships for common jobs, such as research and analysis, that you switch on rather than build | Minimal to no build effort; limited customization |
| Agent Builder in Microsoft 365 Copilot | Business users and champions | A no-code builder inside Copilot where you describe the agent in plain language and point it at knowledge | Fast and grounded in Microsoft 365 content you can access; scoped to Microsoft 365 Copilot; limited actions and integrations |
| Microsoft Copilot Studio | Makers and IT teams | A low-code platform with tools, connectors, authentication options, triggers and publishing to Teams, Microsoft 365 Copilot and other channels | Richer actions and integrations, with Power Platform environments and admin controls; needs more design and testing |
| Microsoft Foundry | Developers | A pro-code platform for hosting agents with model choice, custom tools and evaluation | Full control and production operations; needs an Azure subscription and engineering skills |
| Agent frameworks and the Agent 365 SDK | Developers using their own stack | Code-first options that add identity, governed tool calls and observability to agents built any way you like | Maximum flexibility; the most to build and secure yourself |
Practical starting point: Start with the easiest path that can accomplish the vision. If an agent is built within Agent Builder and later requires more revisions, you can always copy it into tools like Copilot Studio to keep building and enhancing the AI Agent scope there.
Anatomy of an Agent: Four Pillars of Design
Every agent, whatever path you use, has the same four pillars that need to be addressed to successfully deploy agents within the organization.
| Pillar | What it is | Design guidance |
| Instructions | What the agent is for and how it should behave… | Be specific: Answer only from the specified knowledge source(s); name any collateral used; set the length; say what to do when the answer is missing/not applicable |
| Knowledge | The files, sites or data it may read | Keep it small and relevant; prefer current, owned content; never point it at everything that happens to be shared widely |
| Tools | The actions it can take | Give the fewest tools needed; prefer drafting to sending data; require confirmation before any action that changes something |
| Identity and permissions | Who it is, and what it may reach | Prefer acting as the signed-in user so your permissions are the ceiling; if it needs its own identity, give it a sponsor and narrow scope |
When an agent misbehaves, the cause is almost always one of these four:
- Wrong/misleading instructions
- Wrong knowledge or material
- Too many tools/sources
- Too much access to data
Access Capabilities: Delegation and Ownership
This distinction shapes key factors like risk, governance and licensing. It is imperative to make these decisions early within the development and planning phases.
| Delegated access | Own access |
| The agent acts on behalf of a signed-in user, with that user's permissions | The agent acts with its own identity and permissions, for example a service-style agent that triages tickets behind the scenes |
| It can never reach more than the user can | It may reach more than any single person, so scope matters more |
| The accountable person is the user | It needs a named sponsor and owner |
| Typical for personal and team assistants | Typical for shared or autonomous agents |
Microsoft Agent 365 is designed to govern both kinds, which is why the next article treats the sponsor, not the agent, as the unit of accountability.
AI Agent Walkthrough: Agent Builder in Action
1. Choose the job example – Site Rollout Briefing agent that answers questions about one project.
2. Describe it – Give it a name and a one-sentence description so people know when to use it.
3. Write instructions – Be specific and thorough about the context of what we want the Agent to attend to.
4. Add knowledge – Point the Agent towards a few project folders that your account already has access to, and not a trove of data.
5. Add starter prompts – Provide two or three realistic questions that help users begin using the Agent.
6. Test it, including a question it should not answer – Test the Agent by asking about something outside of the Agent's knowledge vector and check that it says it could not find it.
7. Decide who can use it – Maintain the Agent as Private while you test, then share only with the people who need it.
Key Design Concepts Before Publishing AI Agents
* Least privilege. Start with no access and add only what the job needs, for only as long as it needs it.
* Draft, do not send. Let a person read and send. A limit is often the cheapest control you have.
* Confirm before consequential actions. Approve, deny or adjust should always be available.
* Small, current knowledge. Archive superseded files so no agent can read them by mistake.
* Plan for misuse. Test what happens when a document contains instructions aimed at the agent, a practice often called testing for prompt injection.
* Make it observable. Be able to answer what it did, which sources it used and who approved what.
The Core Agent Checklist
| Test | What you check |
| Golden prompts | The five questions the agent must always answer correctly, with the expected source |
| Boundary questions | It says it could not find an answer when it should, and does not guess |
| Permission tests | It cannot reach content a test user is not allowed to open, and gains access when access is granted |
| Action tests | Each action asks for confirmation, can be denied, and can be reversed |
| Adversarial tests | It does not follow instructions hidden in a document, and does not reveal restricted content |
| Content tests | It cites current sources and flags superseded ones |
| Regression tests | The same prompts still pass after every change |
Models can vary their wording from run to run, so grade answers on facts and citations rather than exact phrasing.
Governance at Agent Creation
The best time to provide governance for an agent is at initial creation. Record these functions prior to releasing the AI Agent to users/customers:
* Purpose: Keep this minimal (one sentence).
* Sponsor: The named person who accepted the role for AI Agent creation/deployment (do not use a public resource like a shared mailbox).
* Access: Ensure permissions are noted and justified against the purpose of AI Agent creation.
* Knowledge: Verify the sources provided to the AI Agent, detail owners and review things like dates and capabilities.
* Tools: What tools are needed for action and what confirmation is needed.
* End date and review frequency: Approval for scope and capability
* Where it is registered: Appearance in any corporate Agent inventory
Administrators can manage agent visibility, sharing and lifecycle for agents built in Microsoft 365 Copilot from the Microsoft 365 admin center, and agents built in Copilot Studio or Foundry can appear in the Agent 365 registry.
Common Agent Building Mistakes
* Choosing the tool before the job. Write the job sentence first.
* Pointing an agent at too much. A small, current knowledge source gives better answers and less exposure.
* Leaving out a fallback. Without an instruction to say it could not find an answer, agents tend to guess.
* Giving tools that send or delete. Draft first and let a person act.
* Skipping the sponsor. An agent nobody answers for becomes an orphan.
* Publishing before testing permissions. Test with an ordinary user, not as the builder.
Things to Ask
1. What is the one-sentence job for the first agent you would build?
2. Which build path is the most efficient one that can do it?
3. Who would be its sponsor?
4. Which tools would you refuse to give it?