Featured
How visual workflow automation can integrate with enterprise-scale agentic AI
Combining workflow automation with McKinsey’s open-source Agents@Scale, an agentic runtime for Kubernetes
It’s 2:00 a.m. Your fintech company’s customer support bot just told a frustrated enterprise client to “try turning off your firewall” to fix a login issue. The client escalated to your CEO. Once your team investigated, the AI engineers discovered an agent had hallucinated because it was running on a model never designed for troubleshooting workflows.
This isn’t a hypothetical; it’s the reality for teams deploying AI agents in production. Incidents like this usually point to something deeper, like gaps in ownership, disconnected tooling, or the absence of a shared architecture for business teams and AI engineers.
This article, by Sallah Kokaina, explores how visual workflow automation can integrate with enterprise agentic AI infrastructure. It outlines common challenges in scaling AI workflows and introduces a composable architecture for building optimized, reusable agents and evaluations. Through a practical example, it demonstrates how separating AI logic from business workflows can enable faster iteration, improved quality control, and scalable human–AI collaboration.
Introduction
Agentic workflows are reshaping business operations, such as automated ticket triage in software as a service (SaaS) help desks, dynamic contract review in legal ops, and automated invoice reconciliation. Done right, these workflows can unlock faster turnaround times, consistent quality, auditable decision-making, and scalable human–AI collaboration. They promise a future where automation is not just efficient, but intelligent, traceable, and self-improving.
Yet most organizations aren’t achieving this level of automation. Many are still learning how to structure cross-functional ownership between AI teams and other groups in the business who use different tools.
The problem with embedded AI logic
Workflow automation platforms, such as Zapier and n8n, enable you to call LLMs directly. You can add an OpenAI node to your workflow, pass it a prompt, and route it according to the response. This works for simple use cases. But as AI workflows scale across an organization, teams hit downstream challenges because embedded AI logic creates issues such as the following:
- Duplicated prompts and inconsistent logic scattered across multiple workflows, undermining reliability and traceability, and causing agents to behave inconsistently.
- Opaque evaluation processes, obscuring accountability and reducing the organization’s ability to audit or remediate AI-driven decisions, directly eroding confidence and compliance.
- Ad-hoc decision-making on model or prompt updates, introducing silent regressions, model drift, and divergent user experiences.
- Operational deadlocks, where one team owns the system, but another feels the impact, generating feedback loops and confusion over who should fix what. This is a known “efficiency-accountability” trade off in emerging AI operations models.
- Slow, fragile iteration, because any change to an agent’s reasoning, prompts, or behavior requires redeploying full workflows. This extends lead time, increases breakage risk, and renders rapid experimentation difficult.
- Versioning is “all-or-nothing”, since version control sits at the workflow level instead of at the agent or model component level. It becomes hard to track, compare, or roll back specific agent behavior changes independently of the full workflow.
To eliminate the tight coupling between AI configuration and business workflows, we extended an open-source workflow automation platform that comes with 400+ pre-built integrations. We added our own custom connectors to interface with models, agents, memory, and other components in our agentic runtime. We used McKinsey’s open-source Agents@Scale, and agentic runtime for Kubernetes (“ARK). It’s a highly scalable platform for managing AI agents, models, and evaluators as reusable infrastructure.
We made this decision because both platforms were designed for composability; the workflow automation platform exposes custom nodes for any API, while ARK exposes agentic artifacts like agents and evaluators through APIs.
The integration happened naturally because both systems embraced extensibility as a core design principle.
How it works in practice
Let’s walk through a customer support example. When Alice submits a ticket like this:
“I cannot access the API dashboard. When I try to log in, I get a 403 error.”
The workflow is as follows:
- Webhook receives ticket with customer context (Enterprise account, high priority).
- AI agent generates response using a reusable agent managed by the AI team.
- Quality evaluator scores the response across five dimensions: relevance, accuracy, clarity, usefulness, compliance
- Conditional routing: If score ≥ 0.8, auto-send to customer; otherwise, route to human review queue
Alice’s response scores 0.92 (high relevance, accurate steps, professional tone). The system auto-sends it within 7 seconds.
Bob submits a much vaguer ticket:
“Why is everything broken?”
This produces a generic response that scores 0.65. The workflow automatically routes it to a human reviewer with the evaluation reasoning attached, so the reviewer knows exactly what to improve.
Two structural layers
Ensuring agentic workflows function at scale requires two structural layers that work together: a platform-based operating model for teams and a composable-layered architecture for systems.
Platform-based operating model
Instead of embedding AI logic directly into every workflow, organizations can treat agentic capabilities as shared platform services.
- AI platform teams maintain reusable components such as agents, evaluators, and model policies.
- Operations teams use those components through visual tools, n8n, Power Automate, or OpenAI Agent Builder, without managing their lifecycle.
- APIs and standardized nodes connect both worlds, ensuring quality, observability, and control without introducing bottlenecks.
This model enables teams to innovate independently while staying aligned through governed interfaces rather than one-off coordination.
Composable-layered architecture
At the system level, the architecture separates concerns into three stack layers, each replaceable and evolvable without breaking the others. The composability ensures that when teams update a model, adjust a scoring rubric, or add a new evaluator, business workflows continue uninterrupted.
This showcases a broader pattern: composable AI infrastructure. When AI capabilities are managed as reusable infrastructure rather than workflow or product specific code, organizations gain:
- Resource reuse: One agent serves multiple workflows, APIs, Slackbots, and scheduled jobs. Update the agent’s instructions once; all consumers get the change automatically.
- Independent scaling: AI execution capacity scales separately from workflow execution. Add agent pods during peak hours without redeploying workflows.
- Role-based ownership: Technical teams own AI infrastructure; business teams own workflows. Clear boundaries reduce coordination overhead.
- Governance through architecture: Quality evaluation and model management happen at the infrastructure layer, enforced consistently across all workflows.
AI resources are exposed through APIs so they can be tool-agnostic and use any API gateway, Slackbot, scheduled job, or custom frontend.
Separation of concerns
The integration enables the two teams to work within a composable architecture, remaining aligned through shared workflows and governance. Business teams can iterate on workflows, while AI engineers deliver enterprise-ready agents and evaluators that the business can reuse confidently.
Get QuantumBlack, AI by McKinsey’s stories in your inbox
Join Medium for free to get updates from this writer.
Operations teams can iterate on workflows (in a low-code workflow editor), independently, with the capability to:
- Adjust quality thresholds based on score distributions
- Modify notification logic
- Add new business system integrations
- Change routing rules for different customer segments
- Deploy workflow changes instantly
AI teams manage infrastructure and agentic resources and deliver enterprise-ready agents and evaluators that the business can reuse confidently. They can:
- Tune agent’s prompts based on failure patterns
- Create evaluators with ring-fenced evaluation criteria
- Switch the agent’s underlying models for cost or performance
- Add new capabilities like memory or tool access
- Version and rollback changes through standard deployment practices
Potential impact: A fintech-scale example
Consider a hypothetical fintech company with 2 million active customers generating approximately 1500 support tickets daily, which are mostly account inquiries, transaction checks, and password resets.
Before a composable architecture
The company deploys an AI agent directly into production with no evaluations or quality gates. As a result:
- All AI-generated responses flow into a human review queue.
- The 15-person support team manually checks every message.
- The average review time is 3 minutes per ticket (checking accuracy, tone, compliance).
- Daily capacity: 15 reviewers × 8 hours × 20 tickets/hour = 2,400 tickets.
The backlog is manageable, but there’s no scalability because every new customer or channel increases the human workload linearly. And because the agent’s behavior isn’t evaluated or governed centrally, every workflow that uses it requires separate oversight.
After adopting a composable architecture
AI engineers now publish enterprise-ready agents and evaluators into a shared library, where business teams can assemble and modify workflows without touching the model logic.
For the support workflow, the team chooses an enterprise-grade troubleshooting agent and attaches a reusable evaluator with thresholds set at 0.8 across relevance, accuracy, clarity, and compliance. Based on the company’s historical patterns (65 percent straightforward vs. 35 percent complex questions), the quality-gated workflow behaves as follows:
- Auto-approval of ~975 tickets (65 percent of 1,500)
- Human review of ~525 tickets (35 percent of 1,500)
- Time saved: 975 tickets × 3 min/ticket = 2,925 minutes/day (48.75 hours)
The same team now has capacity to spare and can scale as needed.
This example highlights just one benefit of a composable AI infrastructure. Because the agent and evaluator are managed centrally, any update to the agent’s reasoning or scoring rubrics propagates instantly across all workflows and channels using it without changes to the workflows themselves.
We could worry that shared components might introduce unintended side effects or that simply reusing prompts as variables, though agents involve far more than prompts, could offer similar benefits. While it’s true that central components can amplify issues if changes are made without coordination, this is precisely where composability helps rather than harms. Versioned agents and evaluators create an intentional upgrade path, and the clear separation between business-owned workflows and engineer-owned agentic artifacts ensures dedicated oversight on each side. With coordinated processes and shared governance, improvements can scale across the organization while minimizing the risk of unexpected downstream impact.
The estimated business value is observed through an operational capacity increase, and speed and quality improvements. Many customers receive instant automated responses, and the human reviewers focus on genuinely complex cases requiring their judgment.
Get started with the architectural pattern
The complete example, including the workflow, agent definitions, and deployment instructions, is available on the following GitHub repository.
Start with one workflow. Prove that operations teams can compose AI capabilities without managing their lifecycle. Expand once you see the same agent serving multiple consumers without code changes.
The first step: separate AI infrastructure from business workflows. The rest follows naturally from composability.
Want to learn more or give us feedback? Join the discussion on GitHub about workflows with McKinsey’s team.
Thanks to the author of this article, Sallah Kokaina, and all those who contributed to it, including Dave Kerr, Jo Stichbury, Rory Walsh, and Joanna Sych.
