The trouble is that they almost always stay abstract. You hear that you’re supposed to have a guardrail, without ever seeing one. You hear that an agent “uses tools” without seeing what that actually looks like when it’s wired up. The vocabulary arrives fully formed and the concrete thing underneath it never quite does.

I want to fix that here, and I want to do it in a specific place: Amazon Connect. That second part matters, because even if you’ve got a solid mental picture of what these pieces are in the abstract, Connect has moved a long way recently, and unless you’ve been following it closely you’d be forgiven for not knowing it can now host an AI agent at all, let alone how the parts fit together inside it. Connect has taken a big leap forward from being “just” a contact center solution.

This is the companion piece I promised at the end of my architecture walkthrough video:

This blog post has the same diagram, built up the same way, but slower, and in writing, so we can stop on each part and actually look at it. Let’s start with the very basics.

At its most basic, a call (or a chat, email, or any other medium) comes into Amazon Connect through a channel, and into a call flow. Within that call flow a GetCustomerInput block houses the AI Agent technology that we’ll be talking about today. Even if you don’t know anything about Amazon Connect call flows, the important thing to grasp is that this is the same input pipeline that Connect has been using for years to process incoming calls and route them to agents, except that now those agents might be AI.

Prompt vs Knowledge Base

With that minimal structure in place, here’s the first opportunity to unpack some of the abstract words, and it’s the distinction that does more work than any other once you’re actually building: the difference between the prompt and the knowledge base.

They get talked about as if they’re roughly the same kind of thing, two ways of telling the agent stuff. They aren’t. The prompt is how the agent behaves. The knowledge base is what the agent can look things up in. One is disposition, the other is reference, and keeping them apart is most of what makes an agent maintainable later.

Think about what actually goes in the prompt. It’s the agent’s character and its rules of engagement. Who it is, how it talks, what it should do when it isn’t sure, when to hand off to a human, what it must never promise. It’s small, it’s fairly stable, and you write it once and tune it occasionally. What the prompt is emphatically not is the place to put your opening hours, your returns policy, or the forty edge cases in your delivery terms. People try, because in a quick demo it works. You paste the policy into the prompt and the agent answers correctly and everyone’s delighted. Then the policy changes, and you’re editing the agent’s brain to update a refund window, and the prompt has turned into this unstable thing that nobody wants to touch, because they’re not sure how it will change how the agent behaves.

That’s what the knowledge base is for. It’s the reference material the agent reaches into when a question needs a fact rather than a judgement. The mechanism behind it is the bit you’ll have heard called RAG, retrieval-augmented generation, which is a grand name for a sensible idea: when a question comes in, go and fetch the relevant passages from your documents first, then let the agent answer using what it just pulled back. The agent doesn’t have your returns policy memorised. It looks it up, the same way a good human agent would reach for the current guidance rather than trusting what they half-remember from training.

Once you see it that way the boundary almost draws itself. If the answer would change when your business changes, it belongs in the knowledge base. If it’s about how the agent carries itself, it belongs in the prompt. The reason this is worth getting right on day one is that it’s the difference between updating a document and re-engineering a personality every time something moves.

If the prompt and the knowledge base are the part worth deeply understanding, the rest of the picture is quicker to place now you’ve got the pattern. Each of the remaining pieces is one of those abstract words made concrete, and each one is just another box that hangs off the agent.

Session memory is what stops the conversation feeling like it has amnesia. It’s the bit that remembers you already gave your order number thirty seconds ago, so the agent doesn’t ask again. Useful, occasionally the thing that makes or breaks whether a call feels human, but conceptually small: it’s the agent’s short-term recall for the conversation it’s currently having.

Tools are how the agent does something rather than just says something. Looking up a live order status, booking a slot, raising a ticket. The agent decides an action is needed and reaches out to a system that can actually perform it. You’ll hear MCP mentioned around this, which is just an emerging standard for how agents and tools talk to each other, a common plug shape rather than a different kind of electricity. The important idea is the one underneath the acronym: this is where the agent stops being a talker and starts being able to get things done.

Guardrails are the layer that sits over all of it and decides what’s allowed. What the agent must not say, topics it should refuse, the limits it stays inside no matter how the conversation is steered. In a contact centre that’s not a nice-to-have, it’s the difference between a system you can put in front of customers and one you can’t.

None of these is exotic once it’s on the diagram. That’s the point. Each is a single concrete responsibility, and the whole agent is just these responsibilities arranged around a common centre.

Scenario: re-scheduling a delivery

So let’s put it together and watch a real request move through it. This is the same one I traced in the video: a caller says “I need to reschedule my delivery.”

The call comes into Connect and reaches the agent. The prompt is already doing its work, it’s why the agent is polite, knows it’s a delivery service, and knows rescheduling is something it’s allowed to help with. None of that came from the question; it’s the agent’s disposition, set in advance.

To actually do anything it needs two things the prompt doesn’t hold. It needs to know the rules: how late a delivery can be moved, what the cut-off is, whether this customer’s order even qualifies. That’s a fact that changes when the business changes, so it comes from the knowledge base, fetched in the moment rather than baked in. And it needs to know about this specific delivery, which means reaching through a tool to the system that holds the live order, then using another tool to write the new slot back once the caller confirms.

Session memory keeps the thread together through all of it, so when the caller says “yeah, the second one’s better” the agent knows which two options it just offered. And the whole exchange happens inside the guardrails, which is what stops a determined caller talking the agent into something it shouldn’t do.

One sentence from the caller, and every piece on the diagram had a part to play. That’s the thing the abstract vocabulary never quite shows you: not what each part is, but how they share the work. And it’s also why every part is important and necessary for a well-functioning system.

When the delivery cut-off changes next quarter, you edit one line in the knowledge base and nothing else moves. The agent’s character is untouched. The tools still do what they did. You changed a fact without re-opening the brain. Build it the other way, with everything poured into one big prompt, and that same small change means going back into the agent itself and hoping you don’t knock something loose. Keep the parts doing their own jobs and the system stays something you can actually live with, and learn to trust over time.

Trust in the system is actually a really big part of deploying agentic AI solutions at scale, and is something I’ll be covering in the future.

Of all the corners of Amazon Connect, forecasting and scheduling is the one I knew least about. Although Dynamics does have FCS capabilities these days, they’re still quite new and not out of the box, so it’s not an area I’ve really ever invested time in understanding. So recording episode 36 of the podcast was partly me upskilling in public, with Pavan Dusanapudi from the Amazon Connect team doing the heavy lifting.

The thing that I realised part-way through the episode wasn’t about the features: it was the framing.

I’d always filed workforce management under “things people who run contact centres care about.” Rotas, headcount, the forecast that tells you how many agents you need at 2pm on a Tuesday. Management’s problem, agent’s consequence. What I hadn’t clocked is how much of the recent work has gone the other way, towards making the agent’s day better rather than just making the schedule tighter.

The shift exchange stuff is the clearest example. An agent can offer up a shift, swap it with a colleague, and have the whole thing happen inside guardrails the managers set, without a supervisor sitting in the middle approving every swap. Same with overtime offers and time-off requests. It all lives in the workspace they’re already logged into, so there’s no separate WFM system to learn or extra password to forget. I don’t think I’d have predicted that the headline improvement in a scheduling product would be “agents get a bit more control over their own week,” but here we are.

That isn’t to say that the engineer in me didn’t find the new shift and activity notifications, and the Data Lake integration technically interesting, and I like how they’re re-using constructs that are already there, not always creating new ones.

It is really interesting to review the trajectory of the project over the past four years. Pavan said FCS launched at re:Invent in 2022 and has shipped somewhere north of a hundred features since, all worked backwards from what customers actually asked for rather than chasing a competitor’s spec sheet. I’m naturally a bit suspicious of “we listen to our customers” as a line, because everyone says it. But the shape of what’s shipped backs it up. Shift exchange, equitable rotations, notifications that don’t need a supervisor in the loop. Those aren’t really features you build to win a tender. They’re the features you build when someone who actually does the job tells you what’s annoying.

I came into this one as the person in the room who knew the least. That’s usually when I learn the most. The bit I’ll carry forward isn’t a setting or a screen. It’s that a category I’d written off as administrative quietly turned into one of the more human-centred parts of the platform while I wasn’t paying attention.

Episode 36 is out now. Pavan was a brilliant guest and Alex, as ever, asked the questions I should have.

They know which week the spike starts, roughly how big it gets, and what types of calls dominate it. And every year, their response is about the same. Hire temporary staff in advance, hire overflow capacity, rush training, hold the line through six brutal weeks, recover, run a post-mortem, agree to do better next year, and then forget about it until the calendar comes round again.

That cycle made some sense when contact centre infrastructure was per-seat licensed and physically constrained. Capacity planning was the only lever you really had. It made less sense once consumption-priced platforms removed the year-round cost of peak capacity. It makes almost no sense now that AI deflection is a possibility, and a capable, real alternative. The pricing model changed. The tooling changed. Most operating models haven’t changed yet though.

I want to walk through that gap using two contact centres I’ve spent time thinking about, and then make a case for treating the seasonal trough as the most valuable build window you have.

University Admissions

UK universities have one of the cleanest seasonal patterns in any contact centre I’ve come across. The week of A-level results day is a wall. Volumes go from manageable to overwhelming inside 24 hours, then stay there for about three days. Most of the calls are the same handful of questions. Am I in? What are my options? What about accommodation? How do I confirm? Can I appeal? Can I defer? What’s the deadline?

The questions are bounded and they repeat heavily. The window is predictable to the day. The stakes for the caller are extremely high. I can still remember going through this process, and it sticks in the mind as the first time you feel “on your own” and having to “adult” your future, so the stress is real. And the teams handling these calls have been planning capacity for it since June (and sometimes way before).

That is a textbook deflection candidate. Not because every call should be deflected. Clearing obviously needs human judgement for the edge cases, and there are a lot of edge cases. But the volume of repeat questions during a known three-day window is exactly the shape AI handles well. You build for it, run it through clearing, and switch it off afterwards. There’s no monthly licensing penalty for the quiet 49 weeks because there’s no monthly licensing.

NHS Winter Pressures

A very different vertical, but the same shape of call data. NHS contact centres start feeling the squeeze in late autumn. By January, GP surgery phone lines, NHS 111, and trust patient contact teams are in the worst part of the year. Volumes are up across the board. The calls are about appointments, symptoms, repeat prescriptions, whether to come in, where to go, what’s open and what isn’t.

Some of those calls absolutely need a human, and the bar for getting that judgement right is high. But a meaningful fraction are deflectable, and the cost of not deflecting them shows up in queue lengths for the calls that do need a human. This is the part that gets lost in the AI versus human framing. In a winter pressures context, deflection protects agent bandwidth for the callers who really need a human. When the deflectable calls clog the queue, the urgent ones can’t get through.

The same pattern shows up elsewhere. Council tax cycles in local government. Vaccination campaigns at pharmacy chains. End-of-year claims surges in insurance. Black Friday in retail. The specifics differ. The shape doesn’t.

Where you’re making a mistake

The default response to a known seasonal peak is still capacity planning. Contracts get extended for temps. Training schedules ramp up in late summer or early autumn. Overflow capacity gets leased. CSAT degrades for six weeks anyway, and everyone files the slightly worse experience under “expected” because that’s what the season feels like.

Amazon Connect’s consumption pricing is supposed to break that cycle, and on the infrastructure side it does. You stop paying for peak capacity year-round. You stop being penalised in February for traffic you only see in November. That alone is enough to make Connect feel obvious to seasonal businesses, and it’s why so many of them end up there.

But if you’ve moved to Connect and you’re still planning peak season the same way you used to, you’ve changed your infrastructure without changing how you operate. The work is still being done in the same shape. The peak still hits the same way. The temps still get hired. The CSAT still drops. You’re just paying for it differently.

Cheaper peak absorption is the small win. Reshaping the peak itself is the large one.

When to build

If you accept that, the next question is when. The answer is the trough.

Quiet periods are exactly when a team has the bandwidth to build and test, and most treat them as recovery time. Your team has the capacity, and the demand from customers is lower. Low-stakes testing is actually possible, which it never is during a peak. And you have the entire historical record of last peak sitting in your CCaaS, telling you exactly which five or ten questions dominated the queue. You don’t need to guess at deflection candidates. They are documented in your own data. (psst: we have an app for this!)

The build is a one-time investment with compounding returns. You prototype an agent against last year’s transcripts. You test on a small slice during the slow season. You scale it before the next peak. The agent runs through the peak, sits idle for most of the year, and costs you only when it’s actually doing work. Each subsequent peak benefits from the same investment, with whatever refinements you make in the next trough.

This also changes the budget conversation. You stop budgeting for peak headcount and start budgeting for deflection capability. Different category of spend, different ROI profile, and finance teams tend to like it once they understand the shape. The temps decision becomes the residual after deflection, rather than the default go-to.

The peak-and-trough pattern that drew you to Amazon Connect’s pricing model in the first place is the same pattern that makes deflection an outsized win for you. The trough is not downtime: it’s the build window. Treating it that way is what separates teams that simply adopt Connect from teams that adopt Connect and then change how they operate.

If your next quiet period is closer than the next peak, then this is worth thinking about now.

If you’re a contact centre owner or a technical lead looking at building or buying an AI agent on Amazon Connect, the architecture matters more than any single demo. The components that make up an AI agent (the prompts, the knowledge base, the session attributes, the tools, the guardrails) each do a specific job, and the way they fit together is what separates an agent that actually helps from one that gets you into trouble.

In this video, I walk through that architecture component by component, building it up live as a whiteboard diagram. Then we trace a real call across the finished diagram to show how every piece activates in the space of a single conversation.

By the end, you’ll have a screenshot-able reference that maps how every Amazon Connect AI agent works underneath. The full transcript is below.

Transcript

I’ve sat through a lot of AI agent demos lately. They all look really impressive, but there’s one question almost nobody can answer when the demo ends: What is an AI agent? What’s actually inside one? What are the bits? How do they fit together? Today, we’re gonna draw one live on my iPad whilst I talk you through it.

By the end, you’ll have a diagram you can screenshot, one that maps out how every Amazon Connect AI agent actually works underneath, including the one you’re gonna build, the one that changes how your whole organization runs. Let’s get started.

​All right, let’s start over here on the left. This is gonna be our caller. Now it could be a, a voice call, could be a chat, doesn’t really matter for what we’re doing today. And so this is where the conversation starts, and it happens. It comes into Amazon Connect, and it comes into a channel. Now, if you’ve worked with Connect, you’ll know about flows.

Every interaction gets routed through a flow. Somewhere inside that flow is a block, and it hands the conversation off to our AI agent. I’m not gonna draw the flow today but I’ll just sort of say the flow is the, like the host. The agent is like the guest. The flow invites the agent in, the agent does its thing, and the control then returns to the flow when it’s done.

If flows are a new concept to you, there’s there’s a whole different video for another day. For everything else, though, we’re gonna focus in on what’s happening inside the agent. So I’ll, uh, I’ll just put channel here and that sort of encompasses the flow. And so the conversation then passes from the channel to the agent, and so this is gonna be the agent.

And I’m drawing this one bigger on purpose because everything else that we’re gonna draw today is just something that the agent uses. When the customer speaks, the agent decides what comes next. It might be a simple answer, might be reaching out to another system to actually do something on the customer’s behalf.

If you’ve worked with large language models before this is where the LLM lives. Um, reasoning over what was just said, choosing what happens next. It’s like the brain. It’s the brain of the operations. So now we can start adding what actually makes it useful. The agent is gonna need some instructions.

So up here we’ll draw prompts.

So this is the prompt. It’s the agent’s identity. This is the bit that says, “You’re a delivery assistant, you’re polite, you’re efficient. Here’s how to handle things when someone’s annoyed.” Prompts shape behavior. They set the tone, they tell the agent where the boundaries are. Now, here’s a trap that I see most teams fall into.

They put their entire knowledge base into the prompt. Every business rule, every product detail, the prompt grows and grows and grows into this big wall of text. Nobody can work it out, nobody can debug it, and the agent gets confused as well. The behavior of the agent just gets worse, not better. Prompts are about who the agent is.

Knowledge is a separate question, and we’ll, we’ll sort that out next.

So this is where knowledge lives in the knowledge base. Your delivery rules, your refund policies, the procedural stuff, agen- the stuff the agents need to look up to give a sensible answer. So when a customer asks something, the agent searches the knowledge base, finds the relevant bits, and uses them to construct its reply.

If you’ve heard the term RAG thrown around, this is where this shows up. The agent looks things up rather than making them up. So that’s also what enables the prompt to stay focused on identity. So policy information belongs in the knowledge base where it can be searched and updated without you needing to rewrite the whole agent each time.

So that’s what the agent knows. What about what it remembers?

So right next to the knowledge base, we’ve got session attributes. And session attributes are the… It’s like a memory store. It’s what the agent specifically remembers. So if the knowledge base is what the agent knows in general, then session attributes are like what it remembers about this specific conversation, and this is information you can give it as the conversation goes along.

So who the caller is, what order number they gave you a few minutes ago, anything that needs to persist in between turns gets stored in here. We’ll– we’re gonna come back to session attributes in a whole future video, but for now, the agent remembers things between turns, and session attributes are what enables it to do that.

Okay. So now we get to the bit that makes this an agent rather than just a chatbot. And so that’s all the way over here and in- The tools box. So let’s put an arrow there as well. These are tools. So this is what the agent can actually do. Now, without these tools, it’s really just an articulate FAQ.

So in our delivery example, when the customer says, “I want to reschedule something,” the agent calls a rescheduling tool. So that tool can reach into the delivery system, it can book a new slot, it can bring the results back. And here’s the bit I really like. Connect implements this using MCP, Model Context Protocol, so that that’s the same standard you see all across the AI world right now.

So if you’ve been working with Claude or any other LLM tools, you already know exactly what this is. So build a tool once, plug it into any compatible agents. So that kind of portability is really, really helpful, and you get it with a good standard like MCP. And once the agent can actually do things, well, there’s real power in that, which means that you do need to think carefully about what you don’t want it to do.

And so because of that, finally wrapping everything together, um, I’m gonna attempt to draw like a wiggly line around everything are your guardrails. Okay? And the guardrails are it’s like a cross-cutting layer. They sit around the whole thing. They don’t slot in. They’re not called in particular by one particular component.

The guardrails decide what the agent can say and what it can do. And so that gives you that difference between an agent that really helps you and an agent that can really get you into trouble. There’s a lot more to guardrails than I can cover today, but the short version is: don’t ship an agent without them.

So that’s the whole architecture. Let’s see how it all works together in an example.

Let’s run a real call across this. A customer dials in to reschedule their delivery. The call lands in Amazon Connect. The flow does its routing, and within a couple of cons– turns, the conversation is with the agent. So now the agent’s working, and the first thing it does is it checks who it’s supposed to be.

So using the prompt, the prompt says, “You’re a delivery assistant. You’re polite and efficient.” The customer verifies their identity, gives the agent their order number. The agent stores it here in session variables so that it remembers it for the rest of the conversation. The customer asks, “Is Saturday delivery possible?”

The agent doesn’t guess. It checks its knowledge base, okay, which knows that we can deliver Monday to Saturday, but not bank holidays. So now the customer wants to actually move the delivery. So the agent calls the redelivery tool. The tool uses the order ID stored earlier in session attributes, and from here it can reach out into APIs, legacy systems, whatever, using MCP, reaches into the delivery system, books a new slot.

The result comes back to the agent comes back in here, comes back through the same chain. The agent uses the prompt information to tell the customer when the new slot is, how to present it, what other information to provide. Some of that information may come from the knowledge base around, on the delivery day what to expect and process and protocol and all the rest of it.

And importantly, surrounding all of this, if at any point during that call the customer had done something like ask for a cake recipe or anything completely off-topic, the guardrails are there to stop things getting weird. They’re working in the background throughout the whole conversation, even when you don’t see them fire.

They’re there to make sure nothing goes wrong. That’s the whole architecture in action. Every component here doing its job all in the space of a single conversation. That’s the foundation of an Amazon Connect customer AI agent. If you wanna take one thing away from this video, it’s this diagram.

Screenshot it. Show it to anyone in your team who’s about to start building or is building an AI agent for your contact center.

Each of these components has way more to it than I’ve been able to cover today, but I’m gonna be going deep on each of them over the coming weeks, starting with how all these pieces relate to each other in a written piece next.

But the architecture itself, this thing right here, this is the map. Once you’ve got this in your head, everything else just slots in. I’ll see you in the next one.

I’ve spent years building on top of these kinds of architectures. And to be fair there are legitimate reasons the point solution approach has worked for a lot of organisations.

But I’ve noticed something recently. Firstly, the technical tradeoffs shift as you scale. But, the bigger impact recently has been AI, and to a lesser extent, regulation catching up with AI. I think that has changed how we should think about those tradeoffs in today’s ecosystem, and that’s what this post is about.

The case for point solutions

Let’s start with the advantages with point solutions – in part because I think that this can get dismissed by platform sellers.

A specialist vendor that does one thing well can can outperform a platform’s built-in equivalent. If you need a best-in-class WFM tool, a vendor who has spent ten years on nothing but workforce optimisation is probably going to have more sophisticated forecasting models than whatever a platform ships as a bundled feature. That’s can be a real advantage, if that’s what you need.

Point solutions are also faster to deploy for a single use case. You don’t need a platform migration to get a voice bot live. You sign a contract, integrate with your telephony, and you’re running in weeks. That speed matters when you’re under pressure to show results.

They’re also easier to get budget approval for, as it’s one subset of the overall cost. “We need £40k for a chatbot” is a simpler conversation than “we need to migrate our entire contact centre to a new platform.” Procurement teams understand discrete purchases.

Finally, I don’t want to dismiss the innovation that happens in niche vendors. A startup building nothing but conversational AI can iterate on their product faster than a platform team that’s also shipping telephony features, analytics, and WFM in parallel.

These are good advantages, they really are.

Where the tradeoff starts to shift

The problem is that these advantages are strongest at the point of purchase and weaken over time. Let me try and illustrate what I mean, using a scenario I’ve seen play out in different forms across multiple customers. The scenario is made up, but every element of it has shown up in real customers.

Picture a healthcare contact centre. Let’s call them Morgan Health. Private provider, around 200 seats, handling appointment bookings, prescription queries, and post-discharge follow-ups.

Over five years, Morgan has assembled what looks like a modern contact centre. Voice bot from Vendor A. Webchat bot from Vendor B. WFM from Vendor C. Analytics from Vendor D. Legacy PBX with SIP trunks underneath.

The dashboards are green. Leadership thinks the contact centre is modern because it has bots. On paper, everything works.

But the technical reality is different, and that bleeds into the experience. A patient calls about a prescription, the voice bot triages them, then transfers to an agent who has zero context about what the bot already asked. The patient repeats everything. This happens dozens of times a day.

The webchat bot resolves an FAQ, but that interaction never shows up in the analytics platform because the two systems don’t share data. Management underestimates chat volume. When things change, there’s a lag between the contact center getting the changes and the FAQ being updated. Agents spend additional time having to explain these discrepanices.

When something breaks across the voice bot and telephony boundary, Vendor A blames the SIP config. The telephony vendor blames the bot. The ticket takes three weeks to resolve because nobody owns the gap.

The WFM tool can’t see AI deflection rates because it only gets telephony-layer data. Staffing models are always slightly wrong. Not by loads, but just enough that the contact center is over or under-staffed every week.

Every quarter, IT spends two weeks pulling data from four vendor dashboards into a board report that nobody fully trusts.

This is what best-of-breed can look like when you actually live with it over time. Each tool still does its specific job well. But the spaces between them are where the problems live. And those problems compound.

Tradeoff 1: total cost of ownership over three years

Individually each point solution has a defensible price tag. The voice bot is £X per month, WFM is £Y per seat, analytics is £Z per dashboard.

What doesn’t appear in those business cases is the integration cost. I don’t mean the setup or configuration cost, or adding an API key from one solution to another. I mean building middleware so the WFM tool can consume events from the voice bot. Mapping data schemas between systems that were never designed to share data. Writing custom ETL jobs to get Vendor A’s call records into Vendor D’s reporting format. Then maintaining all of it every time a vendor ships an update that changes their data model or deprecates an endpoint.

In healthcare, every integration point is also a data governance question. Patient data flowing between systems means more data processing agreements, more DPIA assessments, more surface area where something can go wrong. Morgan Health’s IT team spends more time maintaining glue code between vendors than building anything that improves the actual service. This isn’t a problem unique to healthcare, it’s just that it’s taken more seriously there – arguably it gets the attention there that it ought to get in every industry (but that’s another blog post!)

Then the voice bot contract comes up for renewal and there’s a 30% price increase. Suddenly you’re calculating three years of integration costs, middleware maintenance, and vendor management overhead on top of the licence fees. The total cost looks nothing like the original business case.

A platform approach usually has a higher upfront cost, it’s true. Migration is more work than buying a single tool. But, once you’ve done it, you’re then not paying the integration tax every quarter, and you’re not at the mercy of four separate vendor pricing strategies.

There’s an obvious counter here – which is what stops the platform raising prices too? My experience is around Amazon Connect and how that’s built, and the answer is architectural. Your call recordings, transcripts, and contact trace records live in S3 buckets in your own AWS account, in standard formats. If Connect ever stopped making sense commercially, you could migrate your data out. That’s harder to do when a point solution vendor stores everything in their cloud, in their format, behind their API.

Tradeoff 2: regulatory readiness

I’ve written separately about the EU AI Act and what it means for contact centres. The short version: if you’re using AI to interact with customers, you need to demonstrate transparency, maintain audit trails, and prove human oversight. That means logging what the AI decided, why it decided it, and what happened next.

Point solution vendors will solve this for their own product. A good voice bot vendor will add compliance logging to their platform. That’s fine in isolation.

The problem is at the boundaries. Morgan Health’s voice bot logs decisions as JSON payloads pushed to the vendor’s analytics dashboard. Their webchat bot logs decisions as event streams into a separate data store. Neither system records what happened during the handoff between them.

When the compliance team needs a unified audit trail of every AI-driven patient interaction, someone has to write code to join two completely different log formats, reconcile timestamps across systems that may not even be in the same time zone, and fill in the gaps where one system handed off to another and nobody recorded the transition. In a healthcare setting, those gaps aren’t just a nuisance; they’re a liability.

A platform that shares a single data layer doesn’t have those boundaries. On Connect, contact trace records, call recordings, chat transcripts, and AI agent decision logs all live in the same AWS account, in consistent formats, queryable through the same tools. A compliance report comes from one data source. That’s an architectural difference that matters when a regulator asks you to explain what your AI did and why.

This is a grown-up, at scale problem, to be clear. If you’re only running AI on one channel then a point solution with good compliance tooling might be perfectly adequate. The tradeoff shifts when you’re running AI across multiple channels and the audit trail has to cross system boundaries.

Tradeoff 3: what a shared data layer makes possible

This is the one I find most interesting technically. I’ll use Amazon Connect as the example, because it’s what we build on at CloudInteract. But the principle applies to any platform with a genuine shared data layer.

In Connect, a contact trace record captures the entire lifecycle of an interaction: the queue it entered, the AI agent’s decisions, the human agent it was routed to, the outcome, the follow-up task. That record exists in one place. The AI agent, the analytics engine, and the WFM scheduler all read from the same data. Nobody had to build an integration to make that happen.

That changes what you can do. Your WFM tool can see real AI deflection rates, not a number you manually pulled from a bot dashboard and keyed into a spreadsheet. Your AI agents can be evaluated against actual outcomes, not just “did the caller hang up or get transferred.” When something goes wrong, you can trace the full journey in one system instead of correlating timestamps across four vendor dashboards.

None of this is impossible with point solutions. You can build integrations to pipe data between systems. People do it all the time. But you’re recreating something the platform gives you by default, and you’re maintaining that recreation forever. And, you have to do it.

Go back to Morgan Health and reimagine them on Connect. A patient calls. The AI agent triages using Bedrock, and it can see the patient’s recent chat transcript because chat and voice share the same contact history. It escalates to a human with full context attached. The human creates a follow-up task that shows up in the same system. WFM adjusts next week’s staffing based on actual deflection data. The compliance team queries one data source for the audit trail.

None of that required middleware or custom glue code. It works because the data was never split apart in the first place.

On the commercial side, Connect’s Unlimited AI pricing reinforces this. You’re not paying per AI feature or negotiating a new contract every time you want to use another capability. With point solutions, adding AI to another channel means another vendor, another contract, another integration project. On Connect, it’s just a configuration change.

So what should you do?

I don’t think point solutions are always wrong. If you need one specific capability, you’re not running AI across multiple channels, and you don’t have a compliance requirement that crosses system boundaries, a specialist tool might be exactly what you need. It’ll be faster to deploy and probably cheaper in year one.

But if you’re running a contact centre at any kind of scale, with AI on more than one channel, with regulation on the horizon, and with an IT team that’s already spending too much time on integration work, the tradeoffs tilt toward a platform. Not because platforms are perfect, but because the problems they avoid are the ones that get more expensive every year.

Not many of them have read Article 50. Fewer still have checked whether their AI agents are ready for it. And the deadline is 2 August 2026.

That’s less than four months away. So I want to lay out what it actually says, what it means for you, and what you should probably be doing about it right now.

I want to credit Tim Banting, whose LinkedIn post about this reminded me that although we are talking about this with our customers, that’s not true for lots of other people out there, and that this was a topic that warranted more general attention. That’s what this blog post hopes to achieve.

What does Article 50 actually say?

Article 50 is the transparency chapter of the EU AI Act. It applies to every AI system that interacts directly with people. Not just high-risk ones. Every chatbot, every voice bot, every virtual assistant.

The core requirement is simple to state: if someone is talking to an AI, you have to tell them. Not in the terms and conditions. Not on a FAQ page somewhere. At the point of first interaction, clearly and accessibly.

There’s a second part too. If your AI generates content (and it does, if it’s producing text or voice responses), those outputs need to be marked in a machine-readable format so they’re detectable as artificially generated. The technical standards for this are still being finalised through the EU’s Code of Practice, with the final version expected around June 2026.

The penalties for non-compliance are fines up to €20 million or 4% of global annual turnover. That’s the same scale as GDPR fines.

What’s the deadline?

This is where it gets a bit confusing, so bear with me.

The disclosure requirement, telling people they’re interacting with AI, comes into force on 2 August 2026. No delay. Even under the Digital Omnibus proposals that are currently working through the European Parliament, this date is not moving.

The machine-readable labelling requirement gets a short extension under the Omnibus. Systems already on the market before August 2026 would have until 2 February 2027 to comply with the labelling rules. But anything new deployed from August onward has to meet both requirements from day one.

You might also have seen headlines about the EU pushing AI Act deadlines back to 2027 or 2028. That’s real, but it only applies to the high-risk system rules, which are a completely different part of the Act. Article 50 transparency is not affected by those delays.

Transparency vs Human Oversight – they’re different

I keep seeing these two things mixed up, so it’s worth spelling out the difference.

Article 50 transparency is the requirement I’ve been describing: tell people they’re talking to AI, label AI-generated content. It applies to all AI systems that interact with people. It sits in Chapter IV of the Act.

Human-in-the-loop (HITL) oversight is a different obligation entirely. It lives in Chapter III, under the rules for high-risk AI systems. Article 14 says that if your AI is making or influencing decisions about things like access to essential services, healthcare triage, creditworthiness, or employment screening, a qualified human must be able to monitor the system, understand its outputs, and override or stop it.

Most contact centre AI falls under Article 50, not the high-risk rules. Your standard chatbot or voice assistant that answers questions and routes calls is limited-risk. But if your AI is triaging healthcare queries for an NHS trust, or screening job applicants, or making decisions about someone’s access to a service, you could be in high-risk territory without having thought about it.

The reason this distinction matters practically is that Article 50 requires a different set of technical responses to HITL oversight. If you’re planning for one when you should be planning for the other, you’ll waste time and money.

What is everyone else doing?

I went looking for what the major CCaaS vendors and partners are doing to help their customers with Article 50 compliance.

Genesys is probably furthest ahead. They achieved ISO/IEC 42001 certification late last year, which is the first international standard for AI management systems, and they publish AI model cards for their products. NICE has strong compliance tooling and audit trails, which seems to help them in regulated sectors.

The ISO 42001 cert is interesting. It’s an organisational certification. It certifies that Genesys the company has mature governance processes around AI. It does not certify that a specific customer’s deployment is Article 50 compliant. Those are two different problems. Your vendor having good governance is necessary but not sufficient. What matters is whether your specific setup, your actual AI touchpoints, your configuration, is doing the right things.

AWS, who provide Amazon Connect (the platform I’m most familiar with), have published guidance on their approach to the EU AI Act and were among the first signatories of the EU’s AI Pact. But they’re very clear about the shared responsibility model. AWS is responsible for security of the cloud. You are responsible for compliance in the cloud. There is no specific Amazon Connect + Article 50 guidance from AWS yet.

What this looks like in Amazon Connect

I can speak most specifically about Amazon Connect because that’s what we work with every day. And the good news is that Connect already has the building blocks for Article 50 compliance natively. They’re just not wired up for it by default.

Lex can declare that the caller is interacting with an AI system at the start of every conversation. That’s the requirement under Article 50(1). You can do this in the bot’s opening message, in the IVR flow, or both. It’s configuration, not custom development.

Contact Lens can capture and tag AI-generated responses, giving you a record of what was generated and when. Kinesis streams can feed that into an immutable audit log in S3. If you’re using Bedrock for generative AI responses, the invocation logging captures which model generated what, when, and with what parameters. If you’re using Connect’s built-in AI Agents then Contact Lens might well have everything you need, as long as you’ve made sure that long-term record storage is in place.

The architecture supports it. The individual services support it. It just needs someone who understands the requirements to look at your specific deployment, tell you where the gaps are, and get the right things turned on before August.

I’m in the UK or the US. I don’t have to worry, right?

If you’re a UK or US-based organisation, you might be thinking this doesn’t apply to you. The UK hasn’t adopted the EU AI Act and it doesn’t apply to the US either. The UK’s approach to AI regulation is principles-based, through existing regulators like the ICO and Ofcom, and a comprehensive AI Bill isn’t expected until late 2026 at the earliest. I’m less familiar with the US regulation but I’m pretty sure there isn’t anything federal, but a patchwork of state-level laws. The US situation actually sounds like it’s getting messier by the minute, so that’s probably for another blog post!

But here’s the catch. Article 50 applies based on who your AI interacts with, not where your company is based. If your contact centre AI handles queries from EU citizens, you’re in scope. And plenty of UK organisations fall into that category: financial services firms with European operations, NHS trusts that deal with EU nationals, universities, any business that serves customers across the Channel. We could also see global US firms implement these requirements across the board as it’s easier than trying to make sure you correctly segment by region, similar to the cookie consent stuff.

Even where the legal obligation is arguable, there’s a pragmatic case. UK organisations in regulated sectors, particularly healthcare and financial services, tend to align with the highest applicable standard. If you’re going through NHS procurement, or dealing with EU-headquartered clients, being able to demonstrate Article 50 compliance is going to start appearing in questionnaires and tender requirements. So, even though you might be sure you don’t need to, it might be better to get things in place anyway so that you’re ready if needed.

What should you do right now

If I were running a contact centre with AI agents serving any EU audience, here’s what I’d want to know before August:

Which of my AI touchpoints interact directly with people? Chatbots, voice bots, virtual assistants, automated email responses. Map them.

Which of those touchpoints could be interacting with EU citizens? Even if you’re UK-based, if the answer isn’t definitively “none,” you need to plan for Article 50.

Do any of those touchpoints clearly declare that the user is interacting with an AI? Not in the small print. In the conversation itself, at first contact.

Is there an audit trail? Can you show what AI-generated content was produced, when, and by what system? If someone from a compliance team asked to see that evidence tomorrow, could you produce it?

If the answer to any of those is “I’m not sure,” that’s the gap. Three months is enough time to close it, but not if you wait until July.

The MVP program has been a huge part of my life and I credit it with having the greatest impact on my career. It opened doors, it enabled conversations, it taught me so much, and it introduced me to some amazing people. It’s been an absolute blast, and I feel very lucky to have been a part of it.

But 10 years is a long time. Many things have changed and both the MVP program and me are different to what we were a decade ago. That’s not a bad thing or a good thing, but it is a truth.

Over the past 6 months or so, I’ve decided that I need a new challenge. I tend to thrive on the exploration, understanding and application of new ideas, new technologies, new ways of doing things. Sometimes, the comfy chair can become a little too comfy. It’s time for me to throw myself into something I don’t know as well.

I’m staying in the communications world but I’m broadening out from just Microsoft UC. It’s no secret that the company that I work for now – CloudInteract – are an AWS partner. I’ve been spending time understanding their CCaaS platform, Amazon Connect, and so that’s where you can expect me to be concentrating my efforts moving forward. 

I’ll still be blogging and I’ll still be on LinkedIn. My blog has never just been about Microsoft technology – very long time readers will recall it started off being about nANT and CruiseControl – instead it tends to follow my interests. All the existing content remains, for free, and will do for as long as I’m in charge of it.

There’s another reason that I feel comfortable making this jump. When I first started blogging and speaking about developing solutions on Microsoft UC (at the time it was Office Communicator, then Microsoft Lync), I was the ONLY developer at a conference of IT Pros. In fact, apart from my manager (shout out to Paul Nearney who got me started on my MVP journey) I only knew of one other person building UC-based solutions – Michael Greenlee who had, quite literally, written the book on the subject.

Today, the community is rich with developers, both low and pro code, bringing their talents and experiences to help people build solutions. With such great talent I don’t feel at all bad about stepping away, and it’s a testament to the community that I feel reassured that should I ever decide to return in the future I will find a kind and supportive environment waiting for me. I know this because I’ve seen first hand how the Microsoft 365 MVP community welcomes new members and treats everyone with respect and love. It really is one of the best communities in tech, and I feel very proud that I played my own small part in building that.

There are so many people I would like to say thank you to, and I’ve done my best over the past few weeks to do so in person where I can. I’m resisting trying to make a list, as invariably I will miss someone out. But I do want to reserve a special mention for my wife Emma, for the support you’ve given me over the last 11 years. Being an MVP means yielding to an over-achiever type desire to perform, which takes time away from other things, and I’m very grateful for the countless evenings and weekends you’ve given me as I’ve selfishly chosen to spend time blogging, filming or travelling. I can’t promise it’s going to end, but hey, it might at least be different! 😉 xx

It’s a classic cliche, often said when changing jobs, but it’s the people that I will miss the most. Realistically, I know that I will probably drift apart from many of you, but there are also some firm friendships that have developed over the years that I hope will continue. You know where I am, I’ll still be on LinkedIn – if you ever need anything from me, please ask.

I understand if you want to use this announcement as a reason to stop following my content, as it’s clearly going to be less Microsoft-focused going forward. But, if you’re in the UC or CCaaS world, if you’re into technology or are curious, sometimes considering alternative ways of doing things, alternative technologies and approaches, can make you a more rounded individual. The technology world is small and, particularly amongst the big firms, there is a lot of movement of talent. This is just another one of those – no biggie 🙂

I’ll be taking a social media break over Easter, and I’ll be back after that with a new focus. It’s a new chapter, and I’m excited. The way that AI is impacting contact centres right now is massive and I have a long list of things I want to talk about!

PS – I had been thinking about how to structure this post for a few days, and was killing time in an airport lounge procrastinating instead of writing a draft when I read something from Microsoft employee and ex-MVP Fabian Willians, someone that I really respect as a technology visionary, and it really resonated with me in that moment. “Qui non proficit deficit“ – thanks Fabs, that’s exactly what I needed to hear.

Handling Legacy User Settings in SharePoint Framework

M365 Copilot and the case of the broken license

Is the craft dead?

You can also listen to the audio-only version: Thoughtstuff Podcast – Tom Morgan on Teams Dev: Weekly Update 16 February 2026.

Find all my videos at thoughtstuff.co.uk/videos. You can also subscribe to the audio-only version of these videos, either via iTunes, Spotify or your own podcasting tool.

Transcript (AI-Generated)

Hello and welcome to another weekly update. I hope you’re doing well.

Okay, I take it back what I said a couple of weeks ago about the pace of change of news being back to normal for Microsoft 365. It has been another really quiet week and I think this is interesting – maybe even a little concerning. There’s really been very little posted to the usual places: developer blogs and other Microsoft 365 channels.

I don’t really know why this is. I can speculate – it’s probably a mixture of a few things. One: fewer people may be working at Microsoft now and that’s impacting marketing and developer advocacy. Two: those who remain may be busy working on exciting things, so they don’t have time to post blog updates. Or maybe there’s just genuinely less happening, possibly due to enhanced focus on Copilot core development, which might mean fewer changes on the extensibility layer – where I typically focus.

Whatever the reason, there’s definitely a noticeable change in the level of output. For lots of admins and devs, it may actually be welcome because the pace has been so fast recently.

Even with the slowdown, we’ve got a couple of things to talk about. Paolo Pialorsi, who I mentioned last week for his SharePoint Framework (SPFx) blog on user settings, has followed up with another one, this time discussing legacy user settings in SPFx. I’m not an expert in this area, but the post is really good. It goes through the legacy application model, the new model, and explains why the change matters. There are clear migration guidelines and well-written content – including sample code and a detailed table of contents.

To underscore the point about decreased activity, I checked the official Microsoft 365 Developer Blog – there’s been nothing posted since last week except Paolo’s article. This is unusual; a year ago we would easily have seen multiple posts weekly.

But this slowdown lets us feature other great community content. Loryan Strant, another Microsoft MVP, has a humorous piece titled “Copilot and the Case of the Broken License.” While I usually speak to developers, more developers are now being looked to as AI experts. Loryan’s post discusses edge cases in license management and Copilot behavior that can impact devs and admins alike. It’s worth reading simply because he’s already been through the pain and has useful insights to share.

Lastly, I want to highlight a short but potent blog from Scott Hanselman titled “Is the Craft Dead?” It dives into the existential debate about software development in the age of AI. Scott has been in development for over 35 years, and his thoughts are worth considering. His answer: No, development isn’t dead – but it’s also not unaffected.

If you want my opinion: if you’re a developer and haven’t used AI to make your dev work better or faster, that’s probably a missed opportunity. And if you think your job will vanish because AI can code – that’s not right either. If you don’t believe you bring additional value over what AI can generate, maybe it’s time to improve your skills. Most developers, I think, will find that they can combine their strengths with AI to be even more valuable – whether that’s enhancing AI-generated solutions, ensuring compliance with internal systems, or simply maintaining and improving codebases headed for production.

There’s more and more code, which means we need more and more people who truly understand it.

That’s it from me this week. Let’s see what next week brings. Keep an eye on the news cycle – it could be a temporary lull, or something deeper. I don’t want to overreact or guess at motives. All I can do is point out the change I’ve noticed in publication frequency.

Thanks for watching — have a great week!

Deprecation notice: Teams Live Events meeting creation via Microsoft Graph

Mastering User Settings in SharePoint Framework

Navigating Microsoft Teams Docs: A Developer Survival Guide

You can also listen to the audio-only podcast: Thoughtstuff Podcast – Tom Morgan on Teams Dev: Weekly Update 9 February 2026

Find all my videos at thoughtstuff.co.uk/videos. You can also subscribe to the audio-only version of these videos, either via iTunes, Spotify or your own podcasting tool.

Transcript (AI-Generated)

Hello and welcome to another weekly update. I hope you’re doing well and had a great week. A couple of things to talk through this time.

Microsoft Graph Deprecation: Live Events

I’m going to spend some time on this first item. It’s a deprecation notice about creating Microsoft Teams Live Events meetings via Microsoft Graph. This functionality has been around for a few years — enabling the creation of live meetings through the API. However, it’s changing because Live Events are being retired in favor of virtual events.

Specifically, the isBroadcast property used when creating an online meeting is being deprecated. Going forward, setting this property to true won’t be allowed. Instead, users should look to use webinars or town halls, both of which now have API support.

On the surface, this change seems manageable. But my concern is about the short window in which this update is occurring. Microsoft announced this change via a blog post on February 3rd. The beta endpoint will stop supporting the property at the end of March — which is fair given beta is inherently unstable. But more concerning is that the V1 endpoint will see the same change by the end of June — just five months later, and only three months after the beta cut-off.

This feels very short notice considering v1 APIs are supposed to be stable. There are clauses in the terms that mention a two-year window for changes — something we’ve not seen honored consistently. While Microsoft likely has the telemetry to understand usage patterns, from a developer perspective, this kind of short-notice change is disruptive, especially when running production services or software that depends on it.

Storing User Settings via Microsoft Graph

On a more positive note, Paolo Pialorsi — an ex-MVP now at Microsoft — has written an excellent blog post on mastering user settings in the SharePoint Framework (SPFX).

He proposes an approach that makes use of Microsoft Graph and OneDrive for Business to persist application-specific settings per user. This was new to me — I would typically have reached for my own data store or a configuration file. But for SPFX or Teams-based solutions, storing this in app-specific folders via Graph is elegant and scalable.

Every user gets an app-specific folder structure as part of their OneDrive, and app developers can use this space to write and retrieve settings. It also ensures per-application isolation, aligns well with Azure AD registered applications, and behaves much like managing settings on local drives.

Paolo’s post walks through the exact steps to implement this setup, how to handle permissions, and how to structure and retrieve settings. The approach is robust and applicable beyond SPFX — definitely worth a read if you’re building anything accessing Microsoft Graph.

Navigating Teams Documentation: A Developer’s Survival Guide

Lastly, a pick that made me smile — Andrew Connell’s blog post titled “Navigating Microsoft Teams Docs: A Developer Survival Guide.”

He discusses the various challenges developers face finding accurate information in Microsoft documentation. While everything is somewhere in the docs — finding it can feel like an archaeological dig. You almost need to know the age of the Teams feature to figure out where to start looking.

He highlights problems like outdated recommendations, overlapping SDKs, and fragmented documentation across platforms — with some hosted on Learn, others as GitHub entries or blog posts.

Andrew lays out the issues clearly and provides useful strategies for navigating the mess. It’s a good reminder that this struggle is shared and that there are ways to get better at coping with it — trial, error, and experience go a long way in building your own toolkit for success.

That’s it from me this week. Whatever you’re working on — have a great week, and I’ll speak to you again next time.

SharePoint Framework (SPFx) roadmap update – January 2026

Introducing the Microsoft Graph User Configuration API (preview)

Apps for shared and private channels

Dev Proxy v2.1 with configuration hot reload and stdio proxying

You can also listen to the audio-only podcast version: Thoughtstuff Podcast – Tom Morgan on Teams Dev: Weekly Update 2 February 2026.

Find all my videos at thoughtstuff.co.uk/videos. You can also subscribe to the audio-only version of these videos, either via iTunes, Spotify or your own podcasting tool.

Transcript (AI-Generated)

Hello and welcome to another weekly update. I hope you’re doing well. A couple more things to talk about this week.

It might be that the Microsoft engine is finally getting off the ground – just a slow start. It does seem a bit slower than usual, but we’re returning to a more normal cadence of posting. It’s nice to start seeing posts appear consistently in the places you’d expect them.

First up, on the Microsoft 365 Developer Blog, there’s an update to the SharePoint Framework (SPFx) courtesy of a blog post from Vesa Juvonen. It’s similar to last month’s update, but focused on January delivery. The standout for me is how the team actually delivered what they said they would. That consistency gives me confidence, not just in the team, but for everyone relying on SPFx. There’s evidence of ongoing investment and momentum behind the technology.

The main point of the January update is the new debug toolbar, which the December roadmap said would be delivered. It’s now part of the January blog post, confirming that work has been completed. The roadmap itself hasn’t significantly changed—so everything seems to be on track.

This kind of transparency isn’t for pointing fingers if delays happen, it’s really about communication. And Microsoft is showing they’re still committed to SPFx and haven’t moved on from it. The team is clearly funded and supported. Overall, that’s a really positive outcome.

Now, another interesting development – Microsoft Graph has new beta endpoints for user configuration, specifically focused on Exchange Online items. This effort is clearly part of the transition away from Exchange Web Access (EWA), which has been prolonged. Despite initial plans, Microsoft is now firm about deprecating it, even setting a hard stop date and warning tenants accordingly.

One difficulty with transitioning off EWA was that Graph didn’t previously offer comparable functionality. That gap made it impossible for developers to switch over. These new APIs aim to fix that. The Microsoft Graph userConfiguration API (in beta for now) allows storing configuration data per mail folder, which includes read, write, update, and delete operations.

It’s meant to do what it says: store metadata alongside mailbox context. I haven’t used it yet, but it looks like a straightforward CRUD interface. For those holding off migration due to missing features, this could be the green light you were waiting on. Yes, it’s in beta, but I expect a speedy general availability (GA) rollout to match the EWA deprecation deadline. If you try it and run into issues—report them. Microsoft wants feedback since this directly affects the deprecation timeline.

Moving on – another important update in Microsoft Teams: support for apps in shared and private channels. This has long been a pain point. For a while, apps were only supported in public and group scopes, but Microsoft has been closing those feature gaps. As of now, apps in shared channels are GA. Apps in private channels are in public developer preview—a big step forward!

There are still a few gotchas outlined in the updated blog post, so take the time to read through the capability matrix. Pay special attention to any highlighted limitations, especially if you’re building complex scenarios.

Lastly, Dev Proxy is reaching new heights with version 2.1.0. Quality-of-life improvements like configuration hot reload are great, but the headliner is STDIO proxying—that’s standard input/output. This means Dev Proxy can be used with MCP servers too, not just web traffic. It greatly expands its usefulness, especially as many developers shift towards MCP-based infrastructure.

The release includes the ability to wrap executables with the proxy and surface traffic in the network tab. You can also run multiple Dev Proxy instances and configure different ports. These updates demonstrate that the Dev Proxy team is being proactive, keeping the tool relevant and highly useful for developers. High marks all around.

That’s all from me this week. Have a great week ahead, and I’ll catch you next time!