Integration in an AI world
Dan Toomey, joining from the Gold Coast in Australia and a 10-year Integrate speaker, delivered a structured, three-act talk on what happens when APIs stop being consumed by humans and start being consumed by AI agents – and why integration becomes the execution layer of everything. The three acts: the shift in API consumers from humans to agents, integration as the execution layer (the largest act), and a set of practical design tips for making APIs and integrations more agent-friendly.
Act One: The Shift from Humans to Agents
Dan opened with a thought experiment: most organisations’ API documentation is optimised for humans reading it in a browser – but few would bet that humans remain the primary consumers in two years. For 20 years APIs were written by developers and consumed by developers, so human-readable docs and developer portals were design priorities; the mobile era added bandwidth and offline concerns, but the consumers stayed human. Now agents consume APIs at runtime, dynamically, chaining calls and creating autonomous workflows – which means capabilities must be machine-discoverable. Agents don’t read documentation, they read specs; they select tools based on descriptions, schemas, and prior success rates. The consequence is stark: if your API isn’t discoverable, understandable, or reliable, it won’t be selected – not deprecated, just ignored, routed around even when it’s the best technical fit. For an API-first organisation, that could mean half your carefully built functionality goes unused by AI.
What Agents Look For
Dan walked through the qualities agents need, with good-and-bad examples for each:
- Clear, concise semantic descriptions – a good one states what the API returns, the data shape, deterministic behaviour, and error semantics; a bad one reads like marketing copy (“flexible,” “lots of different details,” “sometimes partial data”), making validation impossible.
- Well-defined request/response schemas – descriptive, consistently-cased, strongly-typed fields with enumerations and explicit date-time formats; not just an example message the agent has to reverse-engineer.
- Machine-navigable auth – service-to-service OAuth with client credentials, clear token lifetimes, and deterministic structured errors; not anything requiring MFA, browser redirects, CAPTCHAs, or human consent (e.g. Google’s three-legged OAuth).
- Deterministic, structured error handling – consistent error shapes across endpoints, proper use of HTTP status codes, and a clear signal of whether the agent should retry.
- Prior success rates – agents track reliability and start ignoring APIs that fail regularly.
Act Two: Integration as the Execution Layer
AI systems have no hands or eyes – their only way to interact is through APIs, to access data and perform actions. So integration becomes the execution layer where AI intent becomes real-world action. AI is no longer just helping build applications (generating code, specs, tests); it’s a participant that runs them – calling APIs autonomously, choosing which to call at runtime, orchestrating multi-step workflows, and driving observability. The implication: if your integrations are brittle, your AI is brittle, because it leans so heavily on the integration platform. AI-generated integration brings its own challenges – hidden assumptions embedded through implicit context, opaque rationale for why an API was chosen, no static codebase to step through (you’re debugging emergent behaviour), and non-determinism where the same prompt yields different responses. All of this raises the bar: integrations must now be observable, governable, trustworthy, and machine-readable. Those first qualities aren’t new to enterprise integration, but in an AI world they’re essential, because flaws get compounded and amplified when an integration is called thousands of times a minute and outputs chain into the next call.
The Cascade Scenario
Dan illustrated with a retail “smart replenishment” agent relying on three integrations – an internal inventory API, an internal ML sales-forecast API, and an external supplier ordering API. A developer makes an undocumented rename of the critical “quantity on hand” field, with no versioning, deprecation notice, or contract testing. The agent calls the API, gets nothing back for that field, and interprets it as zero inventory. The forecast API simultaneously predicts high demand, so the agent marks the situation critical and auto-creates a rush order for 8,000 units – all within seconds. The next day 8,000 units arrive by accelerated shipping into a full warehouse, costing roughly a quarter of a million dollars in returns, restocking, or storage. The root cause wasn’t a model hallucination – it was a single uncovered integration change: a broken contract and process.
Three Considerations: Reach, Protocols, and Context
Dan added three considerations. First, an agent’s value is proportional to what it can reach – API-first organisations have a structural advantage, while everyone else pays a “wrapping tax” to re-engineer or wrap legacy systems without APIs (citing Gartner: no APIs, no AI). Second, the protocol landscape: MCP lets agents discover tools via servers publishing capability descriptions, schemas, and return types – a toolbox for agents – but it has pitfalls. Tool-selection reliability degrades with large catalogs (models can pick the wrong tool nearly half the time); authorisation often relies on non-scalable terminal-dependent flows; and security is frequently poor, with the OWASP MCP Top Ten finding many servers lacking authentication or using hard-coded secrets and weak tokens, exposing them to tool poisoning. Mitigations include backends-for-agents (each agent gets its own MCP server with only the tools it needs), strong unambiguous metadata, and permission-aware tool filtering. The newer A2A and ACP protocols are promising but immature – keep using MCP and watch them. Third, context is a rate limiter: agents work within finite context windows, so every tool description and schema consumes budget; connect an agent to 50 MCP servers and it can burn most of its context on descriptions alone – “context saturation,” where agents look capable but reason poorly. Verbose descriptions literally cost agents reasoning capacity.
Act Three: Design Principles for Agent-Ready APIs
Dan closed with practical design principles:
- Structured, machine-readable descriptions – precise about what each endpoint does, when to use it, and any side effects (“get employee by ID” tells you almost everything; a vague “lookup” invites hallucination through overlap).
- Error handling that guides agents – use HTTP status codes properly (no error buried in a 200 body), consistent structured error formats with a code, message, detail, and crucially a retry flag telling the agent whether retrying is worthwhile.
- Least privilege – every callable tool is an attack surface; design scopes assuming an autonomous caller, with fine-grained scopes, time-guaranteed tokens, and per-agent identity, optionally a zero-permissions-start pattern where the agent requests permissions explicitly at runtime.
- Mechanical rate enforcement – agents don’t read “please be nice” rate-limit docs; enforce per-agent rate limits, circuit breakers, and back-pressure signals like HTTP 429 with a retry-after directive.
- Design for composition, not isolation – small, predictable, composable building blocks with consistent data formats and stable identifiers, rather than an opaque monolithic “onboard employee” mega-endpoint.
Applying It in Azure, and the Finale
Dan mapped the principles to Azure services: API Management as the front door exposing agent-ready APIs with machine-readable specs and enforcing governance; Logic Apps for orchestration with its 1,400+ connectors and new agent-loop features; Functions for custom logic and heavy transformations (kept idempotent and fast); Azure OpenAI as the engine for generating client code, translating natural language to API calls, summarising traces, and creating synthetic tests – with guardrails for versioning, output validation, and human review; API Center as the often-underutilised but valuable system of record for API discovery, cataloging, versioning, and deprecation; and Azure Monitor plus Application Insights for distributed tracing, correlation IDs, dependency maps, and AI-driven anomaly detection. His finale: for 20 years APIs were the plumbing behind the product, but in an agentic world the integration layer is the product. Every API now has two consumer classes – humans who read docs and agents who read schemas – and designing only for the first means building for a shrinking audience. Key takeaways: integration is the execution layer for AI, AI amplifies both the good and bad of your integration, and agent-ready APIs (discoverable, governable, observable) will win.
Q&A
A poll found roughly two-thirds of the audience already documenting their APIs, with another fifth planning to. On non-deterministic systems and the feedback loops they need to stay stable: Dan acknowledged it as a deep question – you’re debugging behaviour rather than static code, and over time you learn whether the AI is reliable; the host added that the integration platform itself provides much of the value here (centralised logging, security, cost management), and that the tooling shown across the event seems to be addressing these problems rather than leaving them as an afterthought. On whether a silently renamed field could still let a model be trained or operate effectively: yes, in principle, but the scenario’s real failure was poor integration practice (undocumented, unversioned change) – and the brittle agent could have been programmed to look for a similarly-named field rather than assuming zero. Dan’s closing reflection on the event: governance and security stand out most, given how casually some teams secure things like MCP servers, not realising an autonomous agent won’t apply the good sense a human would unless you’ve built the guardrails around it.
Why Azure Logic Apps are Better for Integration Workloads
Bill Chesnut, a cloud, platform, and API evangelist at Six Pivot and a long-time MVP – BizTalk MVP since 2004, now an Azure MVP – gave a session built on hard-won experience and a clear point of view: integration workloads belong in Logic Apps, primarily because of supportability. Battling a cold throughout, he made the case that the visual design paradigm he’s carried from BizTalk through to Logic Apps isn’t just a preference, it’s what makes production integrations maintainable by the people who have to support them.
What Makes Integration Workloads Different
Bill’s definition of an integration workload: one where you only control one side. A message arrives from a third party – a customer, a supplier, or a SaaS application – and you process it into your own system. Because you don’t control what the other side sends, the data can change without warning: a SaaS vendor upgrades, or someone in your own organisation customises the SaaS and alters how data is presented. On top of that, you depend on third-party systems and networks that go down for maintenance or time out. So integration failures come from a mix of sources, and you only ever control half the connection. His recurring theme: test data is the hardest thing to get right – most organisations have production systems and test systems, but not the same quality of data, because test data is often hand-filled by testers and doesn’t match what production actually sends.
Supportability – the Core Argument
Having spent years on the support side himself, Bill argued that consultants and developers too often hand over integrations without considering how supportable they are – a problem he’s seen worsen with AI trends, as people reach for the neatest, cleverest techniques that turn out to be hard to support. His illustrative pain point: the dreaded “object reference not set to an instance of an object” error. In a function app, the only way he could diagnose it was to take the inbound message into a development environment and step-debug through the code. The cause turned out to be an edge case – a new employee with no shifts where the spec said there would be an empty array, but the field simply wasn’t there. The point: live data hit an edge the test data never covered, and the function app gave almost nothing to go on.
Restartability
A second supportability theme was how you restart a failed process. Bill works extensively with EDI: an AS2 message arrives, you decode it and reply with an MDN confirming receipt, then process the X12 or EDIFACT payload. If the X12 processing fails and you need to restart, you really don’t want to resend the MDN – the partner may reject it because they’ve already received a valid one. Logic Apps lets you restart at a particular action, so you can resume after the MDN was sent but before the X12 processing, even after deploying a fix. A function app would force you to start from the top, likely needing special restart flags and conditions. A common pattern for both is queuing messages (e.g. Service Bus) and reprocessing failures off the dead-letter queue – but the per-action restart is a Logic Apps advantage, and especially important when, say, charging credit cards, where you must never double-charge.
The Options – and Why Logic Apps Wins
Bill framed the choice as Logic Apps Standard (his focus, with custom code) versus code-based options like function apps and web APIs, setting aside Data Factory and third-party tools as out of scope for message-based integration. Logic Apps brings 1,400+ connectors – great for quickly starting a POC with the extra discovery built into managed connectors (pulling back tables from ServiceNow or Salesforce) – though he’s had cases where high activity drove managed-connector costs up and the team switched to plain HTTP. But the single biggest feature for integration, in his view, is the visual run history: you can see exactly what happened, where it got to, and what broke. You can do similar in function apps and web APIs, but only by wrapping everything in try/catch. The visual run history is a far easier debugging and code-consistency tool, and combined with Application Insights gives extensive logging with almost nothing added to the code. For EDI he adds external logging (e.g. Cosmos DB) to confirm that MDNs and 997s come back, since App Insights can be too verbose for support staff.
Testing – a Candid Take
Bill was deliberately a little controversial on testing. Unit tests – now mostly AI-generated from a pile of classes – catch initial typos but offer little value in an integration workload, because they’re based on the test data and specs you were given and don’t react when the live data changes; they also don’t help much with testing maps, which are the heart of integration. Integration testing is far more valuable but hard: you need all the systems present or mocked, and the more you mock, the less value the test has. Repeatable integration tests against SaaS systems are tricky (duplicate keys, new records each run), though AI helps by automating some data generation, and the recent testing work in Logic Apps helps too. But it always comes back to test-data quality – and AI may help by anonymising production data to make better test data.
The Demo and Summary
After a brief screen-share hiccup, Bill demoed a simple Logic App and its function-app equivalent processing the same shift data. In the Logic App, an initialize-variable step succeeded but returned no value – because Logic Apps had “helpfully” inserted null-coalescing question marks in the code view that suppress errors when a field is null. He removed them so missing data would surface as a proper failure, then showed how the run history exposes all the incoming request and header data and lets you click straight to the exact code line that executed. The function app, by contrast, gave little beyond a generic execution-failed entry, forcing a developer to load the message and step-debug. His support pattern: wrap the Logic App in a large error-handling scope, emit the run ID and workflow name to Teams, and let a support person paste the run ID to pull up the failed run, diagnose a timeout or missing field, and restart at an action. His summary: developers forget someone has to support their integrations; Logic Apps gives support people the best chance to do so, freeing developers to develop rather than balance support and dev.
Q&A
On helping a support team that spans infra and integration: Logic Apps’ visual nature makes the flow easy to walk through, and AI tools can generate architecture diagrams of how Logic Apps call each other. On the new Logic Apps .NET SDK: Bill hadn’t used it yet but is keen, expecting it to help move the hundreds of BizTalk applications his customers keep deferring (BizTalk end of support is looming), and to assist AI-driven generation and templating. On the risks of relying entirely on AI to fix broken workflows: cost is the big one – you don’t want the AI scanning the whole project on every question, so you save state/context for the agents and use better (more expensive) models like Claude Code judiciously. On the recommended number of actions per workflow: there’s no fixed number – break sub-components into separate workflows around your restart points (his EDI solution splits send/receive and per-format workflows, with one generalised logging workflow), use the 202 polling pattern for sub-workflows so the caller knows when work truly finished rather than fire-and-forget, and size workflows around what you can realistically manage and support.
Lessons from the Trenches: Agentic Integration for Modernising MuleSoft and Accelerating Greenfield Delivery
Dave Phelps, a UK-based cloud solution architect at Microsoft, and Gil Perry, co-founder of Quokka – a boutique consultancy specialising in APIs, integration ecosystems, and Azure – teamed up for one of the most practical sessions of the event. For the past year and a half they’ve been using agentic AI to accelerate enterprise integration projects, particularly migrations from MuleSoft and other middleware. Their framing was sharp from the start: AI delivers integrations faster, but it’s a single process with two halves – generation and validation – that have to move together. Accelerate the build without changing how you validate, and you just create a downstream bottleneck, or worse, rubber-stamp work nobody really checked.
Why These Programs Exist
Gil set the scene: customers don’t modernise because they’re bored. The pressures are real – rising platform licensing and renewal costs, shifting middleware economics, platforms approaching end of life or extended support, and the growing difficulty of finding or retaining engineers with deep niche skills. At the same time, organisations want to consolidate, reduce platform sprawl, and standardise on a single ecosystem – all while existing operations keep running, because you can’t pause the business to modernise. That combination of cost, skills, platform pressure, and the need for zero disruption is what makes these programs both urgent and hard.
The Textbook vs. The Reality
Across customers the tech stacks vary – lots of MuleSoft, but also Boomi and TIBCO – yet the challenges are the same: hundreds of integrations and dependencies, documentation that’s sketchy or entirely absent, and knowledge concentrated in a handful of engineers who may have already left. The textbook view is a clean three-layer API-led architecture that maps neatly onto Azure (flex gateway to API Management, flows to Logic Apps, message brokers to Service Bus). The reality is messier: a mix of API-led and point-to-point connections bypassing the API layers, embedded undocumented Java business logic, batch processes talking straight to downstream systems, and event routing that grew organically over years. You can’t modernise what you can’t see – and so understanding, not migration, was the real bottleneck.
From Prompts to a Maturity Model
AI doesn’t shorten the two-week sprint – it multiplies what the sprint produces, turning three stories into twelve, and therefore four times the output to validate. Crucially, AI made code generation faster but did not make business validation faster, because the business never reads code; they validate behaviour. The first experiments with curated prompts were encouraging but inconsistent – different engineers got different answers from the same codebase, and prompts improved productivity without creating a repeatable delivery capability. The key realisation: traditional software is deterministic, generative AI is probabilistic, and the two complement each other. The best results come from wrapping probabilistic generation in deterministic scaffolding – templates and structures that generate the boilerplate, with the AI filling in the blanks rather than starting from scratch. Where outputs are probabilistic, governance and validation aren’t optional; they’re essential.
The Biggest Shift: Generate Understanding, Not Code
The turning point came when the team stopped focusing on code generation and started focusing on requirements generation. The real challenge was never generating code – it was understanding what needed to be built. So they began producing structured knowledge artifacts (integration summaries, API inventories, mapping and process documentation), saving customers months of analysis that would otherwise take teams of business and technical analysts. The next breakthrough removed source-platform dependency entirely: instead of MuleSoft- or Boomi-specific documentation, they produced technology-agnostic requirements – API specifications, mapping specs, business rules – that looked identical regardless of the source middleware. Requirements, not code, became the product and the contract between analysis and implementation.
Specialisation, Discovery, and Orchestration
Packaging curated prompts into specialist agents – each with a defined responsibility, structured inputs, and governed outputs – made consistency a property of the system rather than the individual, and the agents outperformed hand-written prompts. Once specialists existed, a discovery agent could run shallow-and-wide across an entire sprawling estate, scanning every integration to produce pattern classification (API proxy, event-driven, batch, orchestration), dependency mapping, complexity and risk categorisation, and a prioritised migration backlog. The output was an estate catalog – a structured view of what existed, how it connected, and where to start – revealing clusters of integrations that share patterns and can be modernised together, replacing gut-feel sequencing with data. A solution-generation orchestrator agent then takes a requirements package and coordinates specialists to emit API Management definitions, Logic Apps, Functions, tests, and Service Bus configuration – multiple coordinated outputs from one input, the same requirements flowing into different technology targets.
Agents in the Delivery Process – and the Two Loops
The next evolution moved agents out of the IDE and into the delivery process itself. The session showed two tracks: a developer track (an engineer working with an agent in VS Code, where everything starts) and an automated track (a GitHub event triggers an Action that invokes a specialist agent with no developer in the loop). This was rolled out progressively, never advancing until the previous stage was trusted – governance wasn’t removed, it was automated, with pull requests, approvals, and validation all remaining. Delivery moved from human-in-the-loop (every action approved before the next runs) to human-on-the-loop (oversight by exception), with autonomy earned through demonstrated reliability rather than assumed. A key insight borrowed from ThoughtWorks: there are two loops. The inner loop is fast and individual (a developer iterating with Copilot), but the outer loop must be durable and shared – promote each fix back into the skills and agents so the next developer starts where the last one finished. Fix the harness, not just the artifact: a fix in a branch helps one developer once; a fix in the skill helps every developer forever.
What It Actually Delivered – and the Demo
The biggest gains weren’t where expected. The headline wins were faster estate understanding, better documentation, reduced repeated engineering effort, stronger knowledge transfer, and more repeatable delivery – engineers spending less time on repetitive work and more applying judgment. But the real surprise was strategic: they set out to build a migration workflow and ended up building a requirements-driven delivery platform. Once requirements became the product, legacy modernisation and greenfield delivery became the same workflow – the only difference is where the requirements come from (reverse-engineered from an existing app, or written fresh from business needs). Dave’s live demo drove this home with a fictitious Contoso retail integration: starting from a business process document, an orchestrator agent generated an Azure-targeted, human-readable business requirements document (with diagrams, schemas, sample messages, business rules, and process flows), then triggered sub-agents to build the artifacts – an Open API definition and policy, a Bicep-deployed Logic App with workflows and unit tests, and a Service Bus queue – all deployed and confirmed working in a live run.
The Q&A
A poll mid-session found about half the audience already generating requirements with AI, and another 31% planning to start after the talk. On managing requirements verbosity – AI tends to capture every possible scenario – the answer was to focus agents on what an integration does from a business perspective (the systems it touches, the transformations it performs) rather than the platform-specific internal implementation, distilling away the noise; and to involve subject-matter experts early with a light-touch gating review, applying a target-technology lens (e.g. for Logic Apps, removing retry mechanisms that the platform handles natively). On human-in-the-loop: start there, assess risk, build confidence with guardrails and testing, and only then move to human-on-the-loop – but don’t go full autopilot into production yet. On error handling, logging, and monitoring: the answer is repeatable templates pulled from a GitHub repo of guidance, so the agent produces the same error handling every time rather than hallucinating action types, with each new issue folded back into the template.
Common BizTalk to Azure Problems and how to fix them
At Integrate 2026, Sandro Pereira – a 20-year enterprise integration veteran and Microsoft MVP – delivered a frank, experience-driven session on the most common pitfalls teams encounter when migrating from BizTalk to Azure Integration Services.
Her first and firmest message: a lift-and-shift migration simply does not work. While business requirements can be carried across, the underlying technology stacks are fundamentally different and solutions must be redesigned – not transplanted. Teams that overlook this face costly rework and failed expectations.
Sandro also cautioned against over-reliance on AI migration agents, noting they are only as good as the original BizTalk solution – and many legacy solutions are far from clean. She highlighted cost awareness as a critical mindset shift: BizTalk developers unaccustomed to cloud billing can inadvertently build technically sound but financially unsustainable solutions. Visual Data Mapper was recommended as a practical, accessible alternative to traditional BizTalk mapping for Logic Apps.
What Went Wrong? (And Why You Can’t Tell): Exception Handling and Logging in AIS
At Integrate 2026, Daniel Probert of Afitness delivered a compelling session on one of integration’s most overlooked disciplines – exception handling and logging. Using a vivid scenario of a 3 a.m. support call about a failed batch process with 47,000 items and a useless error message reading “See an exception,” Daniel illustrated how poor logging can turn a five-minute fix into a five-hour ordeal.
Daniel argued that every integration will break eventually – the real question is whether your team will know why. He outlined five critical questions that good logging must answer: which run failed, what was it processing, where in the flow did it break, why did it fail, and what is the impact. Without these answers, developers are left debugging from memory and guesswork.
The session also tackled the business case for investing in robust error handling, emphasising that while it may seem costly upfront, poor exception handling is far more expensive in the long run. Daniel recommended making it a non-negotiable architectural standard – regardless of whether code is written by developers, contractors, or AI models.
Who Owns the Architecture When AI Writes the Code?
At Integrate 2026, Mattias Lögdberg, founder of DevOps Solutions and Microsoft MVP, tackled one of the most pressing questions in modern software development: when AI generates code at unprecedented speed, who is responsible for the architecture? Using the fascinating story of the Winchester Mystery House – a 500-room mansion built without an architect, resulting in doors to nowhere and staircases that lead into ceilings – Mattias drew a powerful parallel to today’s AI-assisted development landscape.
His core message: the real challenge is not ownership, but maintaining architectural understanding when implementation velocity becomes effectively unlimited. With GitHub public activity surging three to four times since late 2025, local, room-by-room decisions are being made faster than holistic governance can keep pace.
Mattias introduced a continuous verification governance framework – embodied in his team’s Helium tool – that scans Azure environments for compliance, dependency analysis, and architecture visibility. The session emphasised that governance must evolve to be AI-friendly: visual, prompt-driven, and fast to review rather than lengthy documentation no one reads.
Unlock big savings by migrating MuleSoft to Azure
At Integrate 2026, Andrew Rivers of 345 Technology made a compelling financial case for migrating from MuleSoft to Azure Integration Services. Using a fictional but representative retailer – Contoso Inc. – he illustrated how a MuleSoft estate of 1,000 interfaces can cost $2.5 million per year in licensing alone, driven by a peak-capacity billing model that charges for maximum load 365 days a year, regardless of actual usage.
By migrating to Azure’s consumption-based model, organisations typically achieve 70–90% cost savings – often enough at first licence renewal to fully fund the migration project itself. Andrew noted that similar cost pressures are driving migrations from BizTalk, IBM, and Boomi, making platform modernisation a question of when, not if.
The session also highlighted how AI – specifically GitHub Copilot – has transformed migration speed and accuracy. By automating reverse engineering and documentation of legacy interfaces, teams can dramatically cut what once took months of manual analysis, making large-scale migrations faster and far less risky than ever before.
The last integration developer
At Integrate 2026, Rob Hofman of Delaware explored how AI is transforming every phase of the integration development lifecycle – not by replacing developers, but by making them dramatically more effective. Drawing on Delaware’s Smart Link framework, Rob walked through how his team systematically embedded AI tooling across five delivery phases: prepare, explore, execute, deploy, and observe.
Rather than ad hoc AI experimentation, Delaware took a structured approach – reviewing each phase to identify where AI adds genuine value. In requirements gathering, AI-assisted “grill me” sessions help teams generate sharper functional and technical design documents in collaboration with clients. In the build phase, GitHub Copilot accelerates development against a consistent, opinionated framework of templates and accelerators built on Azure Integration Services.
Rob’s central message: AI works best when paired with strong methodology, clear design documents, and well-governed architecture. Unstructured AI use yields inconsistent results – but embedded into a mature integration framework, it becomes a powerful force multiplier for delivery teams.
Designing Resilient Integrations with Azure Logic Apps
At Integrate 2026, Andrew Wilson of Black Marble delivered a thought-provoking deep dive into resilience engineering for Azure Logic Apps. His central thesis: the ease with which Logic Apps lets you build workflows is precisely what makes disciplined engineering so critical. A workflow that succeeds on the happy path is not production-ready – it is simply optimistic.
Andrew argued that integrations rarely fail because workflows are too complex – they fail because the assumptions behind them are too optimistic. APIs throttle, tokens expire, payloads drift, and latency spikes. These are not edge cases; they are the normal behaviour of distributed systems. Resilience, therefore, cannot be bolted on later. It must be the default design posture from day one.
He distilled this into three guiding principles: expect failure as a realistic default, constrain the blast radius so one failure does not cascade, and make recovery intentional by design. The workflow diagram only shows the successful path – the real architecture lives in how the system behaves when conditions stop being ideal.
Azure Integration Services Development with GitHub Copilot
At Integrate 2026, Cameron McKay of MMP Digital demonstrated how GitHub Copilot can be embedded across the entire Software Development Lifecycle for Azure Integration Services – not just as a code completion tool, but as a full AI harness spanning requirements, planning, development, testing, and PR reviews.
Cameron walked through a practical end-to-end integration scenario, showcasing how Copilot’s skills, instructions, prompts, and agents can be chained together to handle orchestration workflows with memory and scalability. His key message: it is not enough to know how to add Copilot to your workflow – teams must also understand the failure modes and how to resolve them to get consistent, trustworthy results.
The session also addressed GitHub Copilot’s shift to usage-based billing, advising teams to set organisation and user-level budgets. Cameron predicted a hybrid future – cloud-based LLMs for collaborative team tasks, and local models for iterative architecture design and documentation work – keeping AI development both effective and cost-controlled.
Whats new in Turbo360 for AIS customers
At Integrate 2026, Turbo360 CTO Michael Stephenson presented a focused session on how Turbo360 has been evolving to better serve Azure Integration Services customers. A central theme was the BizTalk-to-Azure accelerator programme, which gives existing BizTalk 360 customers access to Turbo360 as part of their migration journey – a benefit also extended to integration partners such as Integration Team and Athenas.
The headline capability update was Turbo360’s enhanced cost management module, built around FinOps principles of unit economics. Michael demonstrated how teams can move beyond tracking total platform cost to understanding cost per integration run – enabling IT to demonstrate tangible return on investment to the business. New cost allocation features allow shared resources like App Service Plans to be split by metrics such as request count.
Michael’s closing message: cost should never be an afterthought in integration design. Teams that model cost visibility from the start are far better positioned to optimise, justify, and scale their integration platforms with confidence.
Managing AI Token Costs with Azure API Management
At Integrate 2026, Microsoft Azure Global Black Belt Alex Vieira delivered a practical session on one of the fastest-growing challenges in enterprise AI adoption: understanding and controlling token costs. As organisations scale from AI pilots to production, costs that once seemed negligible quickly become significant – and without proper governance, they become unpredictable.
Alex outlined six core cost challenges: differentiating prompt versus completion tokens, GPU scarcity driving price volatility, cross-departmental cost allocation, production forecasting, model selection trade-offs, and shadow AI spend from non-IT teams. He demonstrated how Azure API Management, acting as an AI gateway, solves the allocation problem by mediating all model traffic – enabling per-application, per-department token tracking with fine-grained visibility.
Anchoring the approach in the FinOps Foundation’s AI framework, Alex emphasised that AI cost governance is not a separate discipline – it is an extension of mature cloud FinOps practice, now with reasoning tokens and caching tokens also surfaced as distinct metrics within Azure Monitor.
Networking in Azure Messaging: Secure and Connect at Scale
At Integrate 2026, Microsoft’s Christina Compy delivered a focused, fast-paced session on securing Azure messaging services – specifically Service Bus and Event Hubs – at the network level. A key architectural distinction set the scene: unlike App Service or Azure Functions, Service Bus and Event Hubs are purely inbound services. All connections are made to them; they make no outbound calls. This fundamentally shapes how network security must be designed.
Christina walked through the three core network security controls available: IP firewalls for managing known public addresses, service endpoints for allowing access from specific Azure VNet subnets, and private endpoints for fully isolating resources within a VNet. Each serves a distinct purpose – the right choice depends on your topology, not a one-size-fits-all approach. She also clarified common confusion between service endpoints and service tags, which govern different layers of network access.
Notable announcements included IPv6 support coming to Azure messaging, an improved Service Bus Premium SLA now at 99.99% across all partitioned namespaces, and a forthcoming mid-tier SKU to bring networking features to Service Bus Standard customers.
Event-Driven Apps with Azure Functions, Connector Namespace, and MCP
At Integrate 2026, Microsoft Azure Functions Principal PM Thiago Almeida unveiled a significant architectural shift: Connector Namespace – a new first-party Azure service that decouples the Logic Apps connector runtime from Logic Apps itself. For the first time, the vast library of managed connectors can be used directly from Azure Functions, Container Apps, and any service that can host a web endpoint, without adopting Logic Apps end to end.
The integration with Azure Functions – announced at Microsoft Build and previewed at Integrate – introduces a new connector trigger type. Developers configure connections centrally in Connector Namespace, which handles token refreshes, retries, and webhook management, while Functions receive clean, strongly typed events via SDKs available for .NET, Python, and Node.js. This dramatically reduces the boilerplate code traditionally required to integrate Functions with SaaS systems like Salesforce, SharePoint, and Microsoft 365.
Thiago also introduced MCP connector tools for AI agents, enabling agents to invoke connector actions directly – extending integration capabilities into the agentic AI layer and opening a new frontier for event-driven, AI-powered workflows.
API Center – Your enterprise catalog for AI assets and APIs
At Integrate 2026, Microsoft’s Sreekanth Thirthala Venkata Manne presented Azure API Center as the answer to a growing enterprise challenge: as AI proliferates, so does asset sprawl. By 2028, AI is projected to be embedded in 95% of enterprise APIs – and without a centralised governance layer, organisations face fragmented inventories, compliance risks, and duplicated effort across teams.
API Center addresses this as a single enterprise catalog for all API and AI assets – REST APIs, skills, MCP tools, agents, plugins, and models. Sreekanth demonstrated how skills can be registered manually or automatically synchronised from a Git repository, keeping the catalog continuously current without manual updates. AI-powered quality assessments evaluate assets for completeness, clarity, discoverability, and safe usage, ensuring governance standards are met at scale.
A key announcement was the API Center MCP server, enabling developers to discover and consume catalog assets directly from GitHub Copilot, CLI, and VS Code – making governed AI assets as easy to find and use as a marketplace, from within the tools developers already work in.
What’s New in Azure Event Grid: Scalable, Flexible, and IoT-Ready
At Integrate 2026, Azure Event Grid Senior Product Manager Seth Shanmugam delivered an update on the platform’s evolution into a fully enterprise-grade, IoT-ready messaging backbone. Built on its MQTT capability launched two years ago, Event Grid now supports MQTT 3.1 and 5.0, HTTP publish, push and pull delivery models, and native integration with Microsoft Fabric – making it a unified platform for both real-time IoT workloads and cloud-native eventing.
Key capabilities highlighted include four-nines reliability, end-to-end message encryption, Sparkplug B compliance for industrial IoT, and a flexible authentication framework supporting custom webhooks – including native integration with Azure Functions for secure ingress and egress filtering. These features directly address the scale, reliability, and compliance gaps that organisations migrating from brokers like Mosquitto and HiveMQ frequently encounter.
Seth confirmed PCI DSS compliance support for financial workloads and outlined a roadmap focused on deeper connector namespace integration, expanded analytical pipeline visibility, and continued scaling to support billions of connected device events – bridging shop floor operations all the way to enterprise back-office systems.
Build Your Own Agent Platform in Minutes: Azure Container Apps Sandboxes for Multi-Tenant, AI-Native Workloads
At Integrate 2026, the Azure Container Apps team introduced Azure Container App Sandboxes – a new compute primitive announced at Microsoft Build, designed specifically for building multi-tenant, AI-native platforms. With Gartner predicting 40% of AI agent projects will be cancelled by 2027, the team argued that the bottleneck is no longer the model – it is the runtime underneath it.
Sandboxes tackle five recurring runtime failures: runaway budget burn, untrusted code execution risks, slow cold-start times, lost workspace state on restart, and manual tool stitching. Each sandbox runs in its own micro-VM with sub-100-millisecond startup, enterprise-grade isolation from host and other tenants, and stateful suspension – snapshotting full memory and disk state so long-running agents can resume in seconds rather than rebuild from scratch.
Built on the same primitives Microsoft uses internally for GitHub and Microsoft Foundry, Sandboxes support egress policy controls, VNet integration, and MCP tool calling – giving platform builders a production-ready, secure foundation for multi-tenant AI workloads without months of infrastructure assembly.
Introducing Logic Apps Automation for Agentic Business Process Automation
At Integrate 2026, Azure Logic Apps Product Manager Divya Swarnkar closed the event with a major announcement: Logic Apps Automation – a new skill tier designed to lower the barrier to entry for an emerging generation of AI builders. With Logic Apps already serving more than 100,000 customers executing trillions of connector calls monthly, the platform is now extending its reach beyond pro developers to those closest to the business problem.
The new Automation skill removes traditional friction points – complex infrastructure provisioning, lengthy procurement processes, and expert-level configuration – by adopting a hosted-on-behalf-of model. The platform manages underlying infrastructure automatically while retaining the full governance, security, and RBAC controls of Azure. Scale-to-zero economics replace the always-on cost model of Logic Apps Standard, significantly reducing the barrier to entry for new workloads.
Automation integrates natively with AI agents, knowledge sources, MCP tools, and human-in-the-loop capabilities – enabling builders to go from prototype to production-ready AI workflow on the same enterprise-proven platform, without the complexity that has historically slowed adoption.
