At 4:17 p.m. on Friday, a customer calls because an installation crew never arrived.
She has already taken a day off work and has no interest in another apology. She wants another appointment, preferably Thursday morning, and she would also like to know what the company intends to do about the day it has just wasted.
The support agent verifies her identity, opens the installation order and checks the field-service record. The visit is marked as a provider no-show. It asks the scheduling system for availability and offers three slots. She chooses Thursday at 10 a.m. The appointment moves.
Then the conversation gets more interesting.
The compensation rules allow AED 100 automatically for this incident. The system offers it. She accepts. Billing is updated and the CRM records the reason, policy and transaction.
She asks for AED 300.
The agent cannot approve it, so a supervisor receives a Teams approval containing the verified customer, failed appointment, standard compensation band and requested amount. The customer gets a case number and leaves the call. Twenty minutes later, the supervisor approves AED 150. The workflow checks the account again, posts the credit and sends the customer an SMS.
By the end of the afternoon, three systems agree about what happened. Scheduling says Thursday at 10. Billing shows AED 150. CRM contains the history.
Sounds simple enough?
But instead if it ends with a clever answer in a chat window from an “agentic assistant”, the week has gone badly.
I like this particular use case because it is small enough to ship and unpleasant enough to expose almost everything an enterprise needs to get right: identity, models, APIs, financial authority, memory, bilingual interactions, human approval, security, observability, evaluation and cost.
For a UAE company there is another consideration from the first morning. “Sovereign” cannot simply mean that Azure appears somewhere on the architecture diagram. Microsoft Foundry Agent Service is currently supported in UAE North, and Azure has UAE regions in Dubai and Abu Dhabi, but model and tool availability still varies by service and deployment type. If a workload is promised to remain in-country, every model endpoint, partner service, log store and tool path has to satisfy that promise.
So let us rewind to Monday.
Monday, 9:00 a.m.: draw one line on the whiteboard
The temptation on Monday morning is to start comparing models.
Resist it.
Draw this instead:
customer → gateway → agent → business tools → systems of record
Everything useful we add during the week will sit around that line.
The customer already reaches the company through an API-capable contact-centre platform. It might be Genesys, NICE, Five9 or Dynamics. Leave it alone. It already knows how to handle calls, chat, WhatsApp, transcription, recording, routing and human handoff.
The first new component is Azure API Management.
APIM becomes the front door to the agent platform. The contact-centre application authenticates before it enters. APIM knows which application is calling, what endpoints it is allowed to reach and how much capacity it may consume. Its AI-gateway policies can impose token-per-minute limits and quotas over longer periods such as a day or a month, which becomes useful surprisingly quickly once several departments discover the shared model estate.
Behind the gateway, deploy a very small service in Azure Container Apps.
The job is deliberately dull: translate whatever the contact-centre vendor sends into the company’s own interaction format.
A voice platform may call the identifier contactId. Another calls it conversationId. WhatsApp has its payload. The mobile app has another. None of that should leak into the rest of the platform.
Use a simple canonical event built on CloudEvents 1.0. Every interaction then carries the same essentials: event ID, conversation ID, source channel, customer reference, authentication state, language, data classification and trace ID.
The architecture has already bought something strategic. If the company changes its CCaaS provider two years from now, the adapter changes. The agent does not. The business APIs do not. The model platform does not.
The adapter also becomes the first place to throw data away.
For our customer journey, we need a customer reference, verification state, language, sensitivity class and current utterance. There is no reason to pass an Emirates ID image, full billing history and eighty miscellaneous CRM fields into the agent because an upstream API happened to return them.
This has an immediate cost benefit as well as a security one. Less unnecessary data means less model context, fewer tokens and smaller traces.
By Monday afternoon, the cleaned request needs somewhere to run. Deploy one Microsoft Foundry Hosted Agent. Hosted Agents are generally available and run custom agent code in Microsoft-managed infrastructure with a dedicated Entra identity, managed endpoints, session handling, scaling and OpenTelemetry-based observability.
For the workflow itself, use Microsoft Agent Framework if this is an Azure-first engineering organisation. If the company already has good LangGraph engineers and production graphs, keep LangGraph. Foundry can host a compiled LangGraph application while continuing to provide the runtime, sessions, identity and platform integration.
Foundry is the operating environment. Agent Framework or LangGraph is a piece of application engineering inside it.
Monday should finish with one deliberately unimpressive success: a sandbox contact-centre request enters APIM, passes through the adapter, reaches the hosted agent and reads one customer record from a test API.
One trace should connect the whole journey.
No one has selected an LLM yet.
That is fine.
Tuesday: build the hands before buying the brain
Tuesday is the day that decides whether Friday will be a product launch or another demo.
The team builds the APIs that the agent will eventually be allowed to call.
Do not expose “Salesforce”, “SAP” or “billing” to the model. Take the messy enterprise interfaces underneath them and wrap them in a handful of business actions.
For this journey, the list is compact: VerifyCustomer, GetInstallation, FindAppointments, RescheduleVisit, EvaluateCredit, PostCredit, CompleteCase and SendConfirmation.
Implement those wrappers as Azure Functions or small Container Apps services. Describe them in OpenAPI 3.1 and publish them through a Foundry Toolbox.
Toolboxes have become an important part of Foundry because they separate the agent from the mechanics of tool integration. A toolbox is versioned, exposes a single MCP-compatible endpoint, can contain OpenAPI APIs and MCP tools, and centralises credentials, access control and observability. Tool implementations can be changed without changing the agent code that consumes them.
That becomes valuable when the enterprise moves beyond its first agent. Customer support may use eight tools today. Procurement will have another set. IT operations another. The platform team can manage those capabilities centrally rather than embedding API credentials and schemas into every new project.
The wrappers themselves are where the architecture starts to look serious.
Take RescheduleVisit. It accepts a verified customer context, order ID, one appointment slot previously returned by the scheduling system and an idempotency key. Before writing, it reloads the order and verifies that the appointment is still available.
If another process has already changed the booking, it returns a conflict and the agent asks for fresh inventory.
The idempotency key handles a less glamorous problem. Suppose scheduling changes the appointment successfully, but the HTTP response dies on the way back. The agent retries. Without idempotency, the automation can execute the same action twice. With it, the API recognises the operation and returns the original result.
The compensation path is even more important.
EvaluateCredit contains the actual business rules. It checks the reason for the failed appointment, account state, previous compensation, customer tier and whatever other rules finance has approved. It returns an amount, decision ID and authority level.
PostCredit accepts the decision ID, not an amount invented during the conversation.
A customer can ask for AED 300. The model can understand the request perfectly. Billing still receives only what the policy engine has authorised.
That line between judgement and authority should be obvious across the platform.
The identity chain is built at the same time rather than postponed until “security hardening”. The CCaaS application receives an Entra identity that may call only the ingress endpoint. The adapter gets a managed identity that may call only the hosted agent. The hosted agent gets its own identity and may call only its approved toolbox. The backend service authenticates separately to CRM, scheduling or billing. Any unavoidable legacy credential stays in Key Vault and is exposed only to the one service that needs it.
By Tuesday evening, run the entire missed-installation transaction from an integration harness without a language model anywhere in the path.
Move the appointment. Calculate the credit. Post it. Update CRM. Send the message.
Then execute the same request again.
There should still be one appointment and one credit.
If Tuesday does not work, Wednesday does not get an LLM.
Wednesday: now we can talk about models
At this point, the workflow has hands but very little judgement.
Now it needs models.
The mistake here is buying one very capable model and using it for everything. A five-minute support interaction contains jobs of radically different difficulty.
Cleaning a noisy transcript is easy. Extracting an order number is easy. Preparing the CRM note is easy. Choosing among eight tools while preserving the customer’s objective is harder. Reconciling contradictory records or an old contract is harder still.
Build three internal capabilities rather than one corporate model:
utility, planner and frontier.
Those names remain stable. The models underneath them can change without forcing every application to change with them.
The utility lane lives close to the data
Use a small open model for the repetitive work: transcript normalisation, Arabic-English cleanup, structured extraction, classification, PII detection, conversation compression and CRM summaries.
A Qwen3.5-9B-class model is a useful reference.
The hardware maths is simple enough to make the architecture tangible. Unsloth estimates Qwen3.5-9B at roughly 6.5 GB total memory at 4-bit, 13 GB at 8-bit and 19 GB at BF16.
Think of VRAM as desk space. The model itself occupies part of the desk. The current customer context occupies more. Active conversations also consume KV-cache memory so the model can keep track of what it has already processed.
Qwen3.5 may support a 262K maximum context, but giving every customer that much room would be an expensive form of generosity. Run the support utility lane at perhaps 8K or 16K. Every few turns, compress the interaction into a structured state containing the customer objective, verification status, facts confirmed by systems, completed actions and unresolved issue.
The model now carries the information it needs without rereading the call from the beginning on every turn.
For UAE-sensitive workloads, this utility lane is a good candidate for private vLLM or SGLang serving on Azure GPU capacity in the approved region. A quantised 9B model fits into a relatively modest GPU footprint, and the company gains a local lane for high-volume work that never needs to reach a third-party model endpoint.
There is a commercial reason to do this only when traffic justifies it. The API price of small models is often tiny. Private inference introduces GPU capacity, utilisation, patching and on-call responsibility. Sovereignty can justify that premium. Low utilisation generally cannot.
The planner gets the ordinary customer journey
The planner needs to follow the conversation, choose the right tool, fill its arguments properly, interpret the response and recover when an API says no.
Benchmark this role instead of appointing a model by reputation.
A current Qwen3.8-27B is a sensible open candidate. Fireworks lists it at 27.3 billion parameters with function calling and a 262K context window. It is available for on-demand deployment and fine-tuning rather than Fireworks serverless today.
The size illustrates the next infrastructure jump. Unsloth estimates a Qwen3.8-27B 4-bit build at roughly 17 to 19 GB.
It can technically squeeze into a 24 GB GPU, but production serving needs more than model weights. Context, KV cache, batching and simultaneous customers all want memory too. A larger GPU gives much healthier operating headroom.
Enter Fireworks AI.
Fireworks is an inference provider rather than an orchestration framework. It operates the model-serving layer: GPUs, batching, caching, throughput and scaling. Its on-demand H100 and H200 capacity is listed at $7 per GPU-hour through August 31, rising to $8 from September 1.
One continuously occupied H100 at the August rate is roughly $5,100 a month before the rest of the platform. That immediately gives the CTO a useful break-even question: is this planner busy enough, sensitive enough or specialised enough to justify dedicated capacity?
If the answer is no, use managed per-token inference. Fireworks’ serverless Qwen3.7 Plus, for example, is currently $0.50 per million input tokens and $3 per million output tokens with a 262K context window.
If one customer interaction used four planner calls averaging 10,000 input and 1,000 output tokens each, that would be roughly 3.2 cents of planner inference per interaction at those list rates. At 25,000 monthly interactions, about $800.
That is a very different economic proposition from a dedicated H100.
The model architecture has become a business decision rather than a benchmark argument.
The frontier lane stays quiet
Some cases will still be unpleasant.
Scheduling says the technician attended. The customer says nobody came. Billing and CRM disagree. An old contract changes the compensation terms.
Those interactions move into a Microsoft Foundry Model Router endpoint containing only models approved for that purpose.
The current router includes GPT-5.6 Luna, Terra and Sol among its supported pool and can also consider eligible open and Anthropic models for agentic requests. The enterprise can restrict the router to a custom subset.
For this workflow, I would keep the frontier subset small. Luna is designed for fast, high-volume work. Terra provides stronger balanced reasoning. Sol can remain outside the support route unless an evaluation proves it changes enough outcomes to justify its cost.
Microsoft currently lists Global Standard short-context pricing at $0.20/$1.20 per million input/output tokens for Luna and $2/$12 for Terra.
Suppose only 10% of the 25,000 monthly interactions reach the frontier lane, with four calls per case and a 90/10 Luna/Terra mix. The inference bill is likely to be measured in tens or low hundreds of dollars rather than in the millions the word “frontier” tends to conjure up.
Integration and operations will cost more.
Thursday: make it survive contact with the company
By Wednesday evening the demo is already impressive.
That is dangerous.
Thursday turns it into something an operations team might actually accept.
The first issue is memory.
There should not be one giant database labelled “Agent Memory”.
The live conversation belongs in Foundry Conversations. The structured working state belongs with the workflow. Use Cosmos DB for operation state, idempotency references, pending approval, workflow ID and expiry.
The actual customer truth remains exactly where it was before the AI programme began. Appointments stay in scheduling. Money stays in billing. Customer state stays in CRM.
Foundry has managed long-term Memory in preview and it can be useful later for benign preferences such as language or communication channel.
It is not where I would store financial promises.
If the customer says, “somebody promised me AED 500 last month”, the conversation has captured a claim. Billing and CRM get to decide whether it is true.
The next problem is durability.
Our customer asks for AED 300. The automatic authority ends at AED 100.
The conversation should not remain alive for twenty minutes while a manager thinks about it. Start an Azure Durable Functions orchestration, send the approval into Teams and let the customer leave with a case number.
When the supervisor responds, the workflow resumes, reloads the customer state, posts the approved amount and sends the notification.
The model works on a seconds clock. Procurement, finance, claims and government approvals often work on a days clock. An enterprise agent platform needs to speak both.
Security is threaded through this same journey.
Apply a Foundry guardrail to the hosted agent for content safety. Foundry’s current guardrail architecture supports checks at user input and output, with tool-call and tool-response intervention points in preview. Hosted agents also have preview network-egress controls that can restrict outbound destinations.
Keep deterministic controls underneath those platform features. The tool schema limits what can be requested. The service reloads the current state before it writes. The policy engine owns financial limits. Identity scopes access. Idempotency handles retries.
Preview safety features should add defence, not become the only thing standing between a model and billing.
Then turn on the operational trail.
Hosted Agents emit OpenTelemetry traces into Application Insights when the supported protocol libraries are used. The platform can show the model request, tool calls, timing and exceptions alongside the surrounding application trace.
Carry the original contact-centre trace ID all the way into the CRM and billing write.
A production incident should be answerable from one trace.
Which model ran?
Which tool did it call?
Which customer was verified?
Which policy decision was returned?
Who approved the exception?
What changed?
Thursday evening is also when the release harness becomes useful.
Put the agent code, infrastructure definitions, toolbox configuration, OpenAPI specifications, model routes, system instructions and policy settings into source control. Create the first 200 replay cases from real support history.
The expected result for each case should contain the expected tool sequence and system outcome, not simply the ideal sentence the model should produce.
Now changes have somewhere to prove themselves.
A new planner comes along. Replay the journeys.
Someone edits a tool description. Replay them.
An engineer wants to replace Agent Framework with LangGraph. Fine. Replay them.
The agent is becoming a versioned software product rather than a prompt somebody is afraid to touch.
Friday morning: production starts teaching you things
By Friday, the team has already built most of the MLOps machinery it will need later.
That matters because the utility model will start producing a large volume of structured work as soon as customers arrive.
Some summaries will be excellent. Some will be corrected by human agents. Some service categories will repeatedly be confused. Arabic-English interactions may expose terminology the generic model never saw in training.
Keep the reviewed examples.
A month later, they become the obvious dataset for Unsloth.
Unsloth’s current fine-tuning guidance estimates about 22 GB of VRAM for BF16 LoRA on Qwen3.5-9B, while its general minimum table puts 9B QLoRA at roughly 6.5 GB and 16-bit LoRA at 24 GB. Unsloth specifically cautions that 4-bit QLoRA is not its preferred route for Qwen3.5 because of quantisation behaviour, which is exactly the sort of detail worth discovering before purchasing hardware.
Fine-tune the small model on narrow tasks where the company has good labels: service categories, summary format, terminology, bilingual notes.
Then treat the new model like any other code change.
Run the replay suite.
If it wins, deploy it beside the current model.
One current wrinkle is worth knowing: Foundry Hosted Agent endpoints do not themselves split traffic between versions. An endpoint serves one version at a time. If you want a 5% canary between agent versions, do the traffic split in APIM or run separate endpoints behind the gateway.
That is a small implementation detail, but it captures the spirit of the entire architecture. MLOps is no longer a separate ML department handing a model artifact to an application team. The released unit includes the model, workflow, tools, policy and agent version.
Production traces create new tests.
Human corrections create training examples.
Unsloth can create a specialised small model.
Fireworks or vLLM can serve it.
The gateway controls traffic.
The evaluation set decides whether it gets promoted.
That loop is already present before the first customer sees the agent.
Friday afternoon: open the gate five percent
Before releasing anything, spend a few hours being deliberately unpleasant.
Disable the planner endpoint. The workflow should degrade cleanly.
Take scheduling offline. The customer should reach a person, not receive a fictional appointment.
Send the same credit twice. Billing should still contain one transaction.
Put a prompt injection in the customer message.
Put another inside a policy document returned to the agent.
Use an account in collections.
Use a customer who changes her mind after confirming Thursday.
Run the replay suite and then run the system in shadow mode on live contacts, where the agent proposes the action while the employee still performs it.
When the system is reliably boring, open one suitable digital queue to a 5% canary.
Now commercial measurement becomes part of the release rather than a separate finance slide.
Suppose this journey represents 25,000 customer contacts per month and eventually resolves 60% without a person. That is 15,000 completed transactions. At an assisted cost of $5.50 each, the gross capacity value is $82,500 a month.
No sensible CFO books all of that as savings. If only 40% converts into reduced outsourcing, avoided recruitment, lower overtime or additional volume handled without new people, the realised value is about $33,000 a month.
Against that, record every operating cost: CCaaS AI features, Fireworks inference or Azure GPUs, frontier tokens, APIM, monitoring and the platform team.
The steering metric becomes:
total cost per successfully completed customer transaction.
The number will tell you whether the next 5% of traffic is worth releasing.
It also settles many model debates quickly.
If a more expensive planner lifts completion enough to reduce the total cost per completed transaction, buy the better model.
If the private GPU lane is sitting at 8% utilisation while a managed endpoint would cost $700 a month, sovereignty had better be the reason you are keeping it.
If the frontier route is receiving half the conversations, fix the planner or the workflow.
By Friday evening, somebody should inspect the first fifty live cases in the systems of record.
Scheduling.
Billing.
CRM.
Trace.
If all four tell the same story, increase traffic.
The interesting meeting happens the following Monday
Procurement has seen the Friday demo.
A manager wants 30 rugged laptops for the field-service team, delivered before September 15 and below AED 180,000.
The interface is different. Almost everything underneath is familiar.
Create a procurement toolbox containing SearchApprovedSuppliers, ExtractQuote, CheckBudget, CheckPolicy, CreateRequisition, RequestApproval and CreatePurchaseOrder.
The small private model extracts quote lines and normalises supplier documents.
The planner compares specifications, warranties and delivery dates.
Sensitive bids stay on the private model lane.
A frontier model handles genuinely unusual contractual language.
Durable Functions or Temporal waits for procurement and finance.
The ERP remains the source of truth.
The same APIM gateway controls access and model budgets. The same Entra pattern identifies the agent. The same observability stack records the journey. The same replay harness determines whether a model or tool change is safe.
This is when the support project stops looking like a support project.
The first week has created a reusable operating pattern for adding judgement and action to business processes.
For a large GCC enterprise, that is the more interesting prize. The region has plenty of workflow-heavy organisations, from telecoms and airlines to banks, utilities, government entities and large conglomerates. Many already have the APIs, cloud estates and approval processes. What has been missing is a controlled layer that can reason across them and act without bypassing the operating model.
The first agent fixes a missed appointment.
The architecture underneath it is capable of considerably more.
Friday, 4:20 p.m.
The appointment says Thursday at 10.
AED 150 is in billing.
The CRM case contains the history.
The customer has the SMS.
Operations can follow the transaction from the contact-centre event, through identity, the agent, models and tools, to the final writes.
The CTO has also learned something useful about the economics. The cheap models can absorb the repetitive work. Managed inference can beat an underutilised GPU estate. Private models can be reserved for workloads that genuinely need sovereignty. Frontier reasoning can remain an exception rather than the default. Tool design and integration usually matter more than token price.
The second agent creates a purchase order.
The third might handle an IT incident.
By the tenth, the organisation is no longer debating whether it should “do agents”. The argument has moved on to which process deserves to be connected next.
That is a much better argument to have.
Until next time 🙂
Join the conversation