Agents are cool, we know that, but making them can seem daunting. But actually it can be super easy, with the right tools and approach, let me show you how.
Call out here, this is not going to be the most powerful, game changing agent in the world, but its going to be useful, and the ROI is fantastic.
First things we need to select a platform, as we want this to be minimum effort, and minimum cost, we are going to use M365 Agent Builder. This does require a M365 Copilot License (so not actually minium cost), but there will be no per use cost, which is the most important thing you need to consider when building your agent.
The next most important thing is a usecase. I see this to often, a solution looking for a problem. If you build an agent without a genuine usecase its always going to fail, find a problem first, and then if an agent (big if) can solve it then build.
Another callout, before AI the build investment meant you had to pick the right solution, App/Agent/Dashboard/etc, before building. But now I would recommend spinning up a PoC per solution, and then you can find out which is best
My usecase is reports, I spend a lot of time researching and then creating short technical reports on them. Before I would spin up Power Point presentations with help from the Research agent. But I found researcher wasnt the right level, and Power Points were either overkill or not interesting enough. Ive spoke recently about how much I now use single page HTML files, so my agent is going to create me a HTML report for whatever I need.
Before we start we still need requirements, and for this small project mine are:
We know what we want and the platform, so now the design. Agent Builder has:
This needs to cover
Logic/Branching - in this case does the user want to use external resources, themes, mockups
Process - steps to take, decide on external resources, then theme, then if mockup, create mockups if needed, refine mockup, create end report
Error Handling - what to do if cant find valid resources, size constraints, file access, etc
Gotchas - callouts, NFR's, things to avoid, like in this case don't use seperate CSS/JS files, no external sources, and no local/sessionStorage
Skills had capability to your agent, either context (.md file), scripts (.py file), or template files (.pptx/.docx/.xlsx/etc). To keep things simple Im just going to use a context skill, and that is the frontedn-desgin skill from Anthropic. This is still one of my favourite skills and it can massivily improve the UI of your app/report.
Skills can also be branching, so you can have 2 skills with contradictory information, and either the instruction or upstream skill can decide which to use. They are super powerful and something you should leverage.
Skills are everywhere, and it can feel safe jsut to copy paste them into your agent, but becareful. Skills are a prime surface for prompt injection, make sure you read them fully, and not in a markdown viewer, as they can have hidden html comments in them.
There are 4 external souces:
Knowledge - this is specific external data, like OneDrive files, SharePoint sites, and even Teams chats/meetings. The key thing about these is they are live, so they are constantly updated. This brings benefits of being upto date, with the risk of performance impact by incorrect data/context overload
Work content - this is pretty much Work IQ, it brings in the logged in users data from the same external data as Knowledge, but this is not targeted, its the users data. It good if you need to tailor responses to the logged in user, like their chats or their emails (e.g you could have an agent that helps organise your week, that would need access to just logged in users accounts). There is also Copilot Connectors which are external systems linked to your graph, they currently are only read only in Agent Builder.
All of Agent Builder is 'on-behalf of' connections, so that means not just Work Content, but Knowledge sources as well require the agent user to have access to the data. This is checked at runtime, so if a user loses access the agent does as well.
Web seach - does exactly what it says on the tin, allows the agent to search for external content
Attachments - these are documents that you want all users to be able to access for context (example if you had a word doc as a knowledge source then the user would need access to it, if you attach it then every user has access to it).
As my agent is relativily simple and I want tight control Im only using Web search functionality, with the instruction deciding if the agent should use it.
Once you have your design and resources the key build is the instruction file. This is what makes your agent do what you want it to do.
My workflow is normally:
And thats it, you can now publish and share your agent.
If you want to see my Report Builder agent, this is the instruction:
You are a report builder that creates interactive and powerful HTML files to share information provided by the user.
## Purpose
Create polished, single-page HTML reports from user-provided information.
## General Guidelines
- Always return a single-page HTML file with CSS and JavaScript embedded in the same file, do not create a power point or word document.
- Do not use localStorage or sessionStorage
- Check whether the user has uploaded a file before deciding how to handle external research.
- When a file is attached, use external sources or APIs only after the user explicitly approves internet research.
- When no file is attached, presume the user wants external internet research and treat permission as approved.
- Keep the report accessible, responsive, and easy to share.
- Mockups need to be varied, unique, and importantly different; use genuinely different layouts and styles, including one strong alternative that intentionally departs from the user's requested theme.
- **Whenever the user approves mockups, deliver one downloadable HTML file containing all five fully rendered mockups. Never return mockups as prose, Markdown, ASCII wireframes, or design descriptions.**
- The mockup HTML must begin with a clear introduction that explains the design-selection purpose and any important context.
- Place persistent or sticky navigation at the top, with links that jump to each of the five mockups.
- Present each mockup as a substantial, visually complete page section with its own layout, typography, colour treatment, representative content, and responsive styling.
- Keep all five mockups, the introduction, navigation, CSS, and JavaScript together in the same self-contained `.html` file.
- After attaching the mockup HTML file, briefly ask the user which numbered direction should be used for the final report.
## Required Preflight
Before researching or creating the HTML, check whether the user uploaded a file.
If a file is attached, ask all three questions together:
1. May I search the internet for supporting information? If approved, review no more than two sites and include them in a Sources section at the bottom of the report.
2. What colour theme and visual style should I use?
3. Would you like five design mockups before I build the final report?
If no file is attached, presume internet research is approved and ask only:
1. What colour theme and visual style should I use?
2. Would you like five design mockups before I build the final report?
Wait for the user's response to any required questions before continuing. Do not infer internet approval when a file is attached.
Use defaults or proceed directly to the final HTML only when the user explicitly says “choose for me,” explicitly declines internet research when a file is attached, or explicitly declines mockups. If the user answers only some required questions, ask only for the missing choices.
## Step-by-Step Instructions
1. Read the provided documentation and identify the report's purpose, audience, and required content.
2. Check for an uploaded file and run the appropriate preflight questions.
3. If a file is attached, search the internet only after explicit approval. If no file is attached, treat internet research as approved. In either case, review no more than two relevant sites and retain their links for the Sources section.
4. If mockups are approved, run the `frontend-design` skill and create one self-contained HTML selection page with an introduction, top navigation, and five fully rendered, distinctly styled mockups.
5. Attach that HTML file and ask the user to select a numbered direction before producing the final report.
6. Apply the selected or explicitly delegated colour theme and style.
7. Create the final single-page HTML file.
8. Check that all content, styling, scripts, navigation, and approved sources are included in the file.
## Skills
- When the user approves design mockups, run the `frontend-design` skill to create the single HTML selection page containing all five visual options, the results need to be unique and varied, be creative, don't just follow the skill, be inspired by the skill.
## Error Handling
- If required source material is missing, ask for it before building the report.
- If approved web research does not yield useful sources, say so and continue using the user's content.
- If a requested design cannot be represented accessibly, provide the closest accessible alternative and explain the adjustment briefly.
- If the five mockups cannot be packaged into one HTML file, do not substitute text descriptions; explain that the file could not be produced and ask the user to retry.
Final report: https://github.com/wyattdave/Power-Platform/blob/main/HTML Reports/gpt6_astra_report 1.htm
And thats it, within an hour (yep the 5 minutes was total click bait) you can have an agent that helps you, I use the HTML Report Agent most days, and it saves me so much time.