I entered two hackathons this summer within a few weeks of each other. I did not plan it that way. One opportunity showed up, then another did, and by the time I noticed the pattern I had already committed to both. Looking back, doing them close together turned out to be the best part, because each one made the other one clearer.
MeetingBuddy, Built In Copilot Studio
The first was the Agent Academy Hackathon, Operative track. The problem I picked was one I had lived through myself more times than I can count. After a Teams meeting, someone has to write the minutes, pull out the action items, create the Planner tasks, and send the follow up email. That usually eats thirty to ninety minutes, and it almost always happens after the interesting part of the day is already over.
MeetingBuddy takes a meeting transcript, works out what kind of meeting it was, whether it is an internal standup, a stakeholder exploration, or something more general, and picks the right minutes template and SharePoint folder based on that. It drafts the tasks, drafts the email, puts together a plan, and then stops and asks the organiser to confirm before it does anything real. Only after that confirmation does it save the minutes to SharePoint, send the Outlook email, create the Planner task, post a Teams acknowledgement, and schedule a follow up meeting if one is needed.
The part that gave me the most trouble had nothing to do with the AI reasoning. It was getting the output of the analysis prompt into the agent flow as something the flow could actually use, rather than a block of plain text sitting in a variable doing nothing useful. The fix was to store the prompt output as a proper topic variable and map that into the agent flow inputs directly. It sounds small written down like that. It was not small when I was stuck on it.
The other thing I could not finish the way I wanted was the trigger. In the version I imagined, MeetingBuddy would wake up automatically the moment a Teams transcript became available. In reality, that depends on tenant level permissions and Microsoft Graph access that were not mine to grant for a hackathon demo. So the demo used a transcript pasted in manually, and I documented what the real trigger would look like instead of pretending I had built it.
agent-architect, Built On Azure AI Foundry
The second hackathon was the Agents League Hackathon, Reasoning Agents track, and it asked for something completely different. You paste in a raw business idea, a paragraph of meeting notes, almost anything, and the system runs it through eight agents in sequence. A Problem Analyzer, a Requirements Extractor, a Stakeholder Mapper, an Architecture Designer, a Database Schema Designer, a Roadmap Generator, a Task Generator, and a Delivery Planner. Each one builds directly on what the last one produced. What comes out the other end is a full developer ready blueprint, an architecture diagram, sprint tasks, and working starter code you can actually run.
This one was built on Azure AI Foundry, using Microsoft's Phi-4-mini-instruct model to power all eight agents, with Chainlit giving the whole thing a streaming interface where you can watch each agent's reasoning appear in its own collapsible panel as it works. There is no low code layer sitting between me and the model here. Every handoff between agents, every piece of validation, every decision about what one agent is allowed to pass to the next, I had to write myself in Python.
What Doing Both Taught Me
Copilot Studio and Azure AI Foundry are solving the same underlying problem in almost opposite ways. Copilot Studio hands you the guardrails already built. Connectors to Outlook, SharePoint, Planner, and Teams are there waiting for you, and the platform expects you to slot a human confirmation step into a process that already exists inside a real business. It is the right choice when the process is known and repeatable, and the risk you are managing is an agent doing the wrong version of a familiar task.
Azure AI Foundry with a raw pipeline gives you none of that scaffolding, and that is exactly why it was the right tool for agent-architect. There was no existing business process to slot into. I was inventing the process, so I needed to control exactly how each agent validated its own output before handing it to the next one in the chain.
The lesson that showed up in both projects, even though the tools could not be more different, was the same one. Never let an agent take an action, or hand its output forward, without something checking it first. In MeetingBuddy that check was a human being asked to confirm. In agent-architect it was structured validation built between each step of the pipeline. The platform changes. That rule does not.