My first week at a large marine logistics company, in June 2025, I had a clear technical direction. The procurement team needed an AI agent that could answer common policy questions for stakeholders across the company, and when it couldn't, draft an escalation email to the procurement team on the stakeholder's behalf so the question got routed cleanly instead of disappearing into someone's inbox. The company was Microsoft-native. The documents lived in SharePoint. Microsoft Copilot Studio gave me Teams integration and SSO essentially for free.

The path was obvious. I prototyped in Copilot Studio and the RAG functionality worked. SharePoint documents indexed in minutes, and the answers were grounded and useful. By the end of week two, I was confident the project would ship on time.

Then I tried to build the email approval workflow.

The wall

When the RAG layer couldn't ground an answer to a stakeholder's question, the agent had to draft an escalation email to the procurement team on the stakeholder's behalf, but it could never dispatch one autonomously. The stakeholder had to approve, edit, or revise the draft before anything actually went to procurement. This was non-negotiable for governance reasons.

Copilot Studio could not do this cleanly. The conversational state required to support multi-turn revisions (RAG comes up empty, the agent drafts an escalation email, the user edits it, the agent regenerates with the edits, the user approves, and only then is the email dispatched) was beyond what the platform's branching logic could express. I spent two days trying to make it work. The closest I got involved encoding state in the conversation history and parsing it on every turn, which was fragile, and which I expected to fail silently in production.

So two days in, the question stopped being how to implement the approval flow inside Copilot Studio and became whether to keep using Copilot Studio at all.

The decision

I saw two options. The first was to descope the email approval workflow to something simpler (a one-shot draft with no revision) and ship on the original timeline. The second was to abandon Copilot Studio entirely and build a custom agent with LangGraph and FastAPI, which would mean rebuilding the RAG pipeline, configuring SSO manually, and shipping a custom Teams tab application instead of a native one.

I chose the second option, knowing it would cost me at least two weeks of work I'd already done.

The lesson I took from this isn't about Copilot Studio specifically. It's about prototyping order: the workflow that puts the most constraints on the architecture is the one to build first, because it is the one that can invalidate the platform choice while there is still time to change it.

I had inverted that. RAG was the visible feature, the one stakeholders would see in the demo, so I built it first. The HITL workflow was the structurally harder requirement, but I'd treated it as a follow-on. By the time I discovered the platform couldn't support it, I'd invested two weeks in the wrong foundation.

What I built instead

The custom architecture was a coordinator agentic pattern in LangGraph. A top-level coordinator agent routed each question to one of two specialized sub-agents: a RAG sub-agent for policy Q&A grounded in Azure AI Search, and an email sub-agent that took over when the RAG layer came up empty, drafting an escalation email and managing the multi-turn approval state. FastAPI served as the backend. Azure Logic Apps handled the actual email dispatch, gated by the agent's tool calls. The Teams tab application was a React/TypeScript frontend, which gave me an admin dashboard with health checks and node traces I couldn't see a way to build in Copilot Studio.

Getting back to where the prototype had been took about two weeks. Building out from there, the HITL approval loop, the two sub-agents, the audit trail, and packaging it all as a Teams tab, took the rest of the summer. The dispatch tool was never invoked without an explicit approval turn. I tested that, stakeholders tested it, and I had monitoring in place to catch it if it had been. The system shipped on time, with a week of buffer.

What I'd do differently

The decision was reasonable on what I knew. The order was wrong. If I were building this again, I would have spent the first two days of the project specifically on the HITL flow, not the RAG pipeline, not the indexing strategy, not the agent prompts.

The other thing I'd change: I should have written down the architectural assumption I was making. Copilot Studio can handle multi-turn approval flows was an assumption I'd inherited from the platform's marketing materials, and I never tested it before committing. If I had written that down as an assumption rather than carrying it as a background belief, I would have had something concrete to test in week one instead of something I only discovered in week three.

A coda on the timing. I made this call in week three, at the end of June 2025. About nine weeks later, on 19 August 2025, while I was still on the same internship, Microsoft shipped Request for Information: a native human-in-the-loop action for Copilot Studio's agent flows that pauses a workflow to collect input from a human reviewer, close to what I'd been trying to build by hand. It shipped in preview then; as of August 2026 Microsoft's documentation no longer marks it preview. That doesn't make the decision wrong; in week three of a fifteen-week project I needed something that worked, not a feature that didn't exist yet. But the gap I hit closed within weeks of my hitting it.

This is, broadly, what I think about when I'm building production AI systems now. The capability layer is impressive and improves quickly. The constraints (governance, audit, approval, validation) are where this project got stuck, so they are what I prototype first now.