What does this mean? Not for businesses, but for business users. These days, the main tool in the quiver of every business user in an enterprise is … the web browser. Initially web interfaces to business software and then SaaS software has seen to this.
The result? Employees needed to build their workflows around a plethora of different web applications, having open a corresponding number of tabs at any given time. I just counted the ones that I have open: fifty-three. And that doesn’t even count the web browsers that I do not even recognize as such. For example, Apple Calendar, or Microsoft Outlook. Maybe even MS Word … one never knows where there’s a browser these days …
Now, with agentic AI moving into the business, these workflows will need to change. How, that heavily depends on the vendors one works with and, of course, the size of the own business.
One of the main considerations when moving towards agentic workflows or agent-supported workflows is the orchestration of agents. This becomes especially important when working with different software packages and this is also a core reason for the emergence of protocols like MCP (model context protocol) and A2A (agent to agent) or ACP (Agent Communication Protocol) that are currently developed. Plus, there are a few “agentic” browsers emerging that allow for the orchestration of different agents on the user level.
But what is best, what to use – and when?
After all, many of the vendors that are already in house, have their own strategies. And many of the buyers, too, plus some limitations, like budgets, or time.
Vendor strategies
Vendor strategies for placing the orchestration layer depend on their value proposition and positioning. These strategies can largely be put into four buckets, the browser and frontend, application, application platform, and infrastructure, although this can be detailed out. Also, some of the larger vendors pursue more than on strategy. These are particularly the ones that offer an application suite. It can be expected that some of the mid-tier business application vendors will follow a multi-layer agentic orchestration strategy, too.
Browser and front-end layer
This layer is the one closest to the user and embeds agent and agent orchestration capabilities directly into the browser. AI agents to interact with the user interface (UI) of any web application, simulating human actions like clicking buttons, filling forms, and navigating menus. Its power lies in its universality; it does not require the target application to expose APIs, thereby making the entire web a programmable surface for automation. This strategy is essentially an extension of RPA. It is easy and convenient for the users who can automate pretty much every task with very limited technical skills. From a technical perspective, it doesn’t require API access. For browser makers or RPA vendors, this is the entrance into businesses via agentic automation. On the flip side, there is a considerable security risk as the agents may autonomously act in logged-in user sessions. Technically, they are somewhat unstable, as any change in a web applications layout or document object model has the potential to break the automation flow.
Still, this will probably become an important agentic automation strategy, especially on the consumer side, not in the least because also Google and Microsoft with their massive reach are pursuing this avenue.
Application layer
An application layer strategy focuses on domain (application) specific AI agents that are built into SaaS applications. These agents are regularly pre-trained on the domain data models, workflows and core business logic. Their integration into each other theoretically allows the execution of complex and context aware tasks within the boundary of the domain. Theoretically, as research has shown that the complexity that can get covered still has significant constraints. From a user perspective, this strategy offers a very fast time to value as agents are pre-trained, pre-integrated and work in an application that they already know. From a technical perspective, they are easy to train or fine-tune as they are already grounded in the data that the application itself works on. Further, it is pretty easy to provide guardrails and authorizations to prevent unauthorized data access. Disadvantages include their confinement into the hosting application. Using them to orchestrate cross-application workflows regularly requires implementation and integration work.
This strategy delivers high short-term value as the agents are likely to do a very good job. However, it is not very likely that vendors that follow this strategy become a top choice as an agent orchestration platform, unless they also play in the application platform layer.
Application platform layer
Vendors in this category make their technology platform the orchestration hub, supporting enterprise workflows that stretch across applications of different vendors, including vendors outside their own ecosystem. They leverage their access to data, knowledge graphs, metadata, as well as their range of business applications to provide a central environment or building, deploying, managing, and governing autonomous agents. Successful execution of this strategy makes them a kind of an operating system for autonomous agents. Businesses that have decided for an ecosystem can gain a single source of truth for data and processes, including unification of governance, security, and compliance. This enables the automation of the most complex and impactful business workflows. This and pre-built integrations across the vendor's own application suite reduce development complexity for intra-ecosystem workflows, freeing the IT team for other tasks. On the negative side, following this strategy causes a vendor lock-in, which makes it hard to move into another ecosystem. If it isn’t already implemented, the platform implementation itself can become costly and complex. While standards are emerging, the technical integration with agents in non-ecosystem applications may be cumbersome. Also, the platform itself often evolves slower than other orchestration architectures.
In spite of the disadvantages, this is probably one of the most viable strategies, because digital agents, as part of technology, are a platform game. There is a good chance that these platforms become the “system of record” for agent orchestration, given that they embrace the evolving open standards for agent collaboration.
Infrastructure layer
Vendors that focus on this strategy do not deliver end-user agents but on delivering the underlying frameworks, tools, protocols, i.e., the "plumbing" that is required to build, connect, and orchestrate multi-agent systems. They focus on offering the foundational components that enable developers and citizen developers to construct agentic applications by enabling them to compose capabilities from various applications. It is a platform strategy. In that sense, it is a subset of the application platform strategy.
The primary advantage of this strategy is that it allows users to have maximum flexibility and control. It is (mostly) application vendor independent and avoids a lock-in to any application vendor. From a technical perspective, this strategy enables an open, extensible, and composable architecture. It aligns with software development practices like microservices, that build complex systems from smaller, independent, yet interoperable components. From a user perspective, this comes with the disadvantage of requiring significant in-house development expertise and capacities as the complexity of building, managing, and governing a heterogeneous multi-agent system is substantially higher than using an integrated platform. Technically, the full responsibility for ensuring security, scalability, reliability, and observability of the entire system lies with the implementing organization.
The viability of an integration layer strategy is pretty high. Many (enterprise) customers will have multi-ecosystem infrastructures and pursue a best-of-breed strategy. These will find themselves attracted by an infrastructure-based orchestration layer.
What does this mean for businesses?
Agentic AI has gained significant traction, if not (yet?) in results but certainly in share of mind. Consequently, it is foreseeable that more and more businesses will, or will need to, implement and deploy digital agents, that in turn need to cooperate with each other. E.g., a sales agent in a sales system and a support agent in a service desk are of limited value if they cannot collaborate to provide a unified user- and customer experience. This simple reality is driving the market away from monolithic, connected systems toward collaborative, multi-agent architectures. This makes agent interoperability not just an option but a must. Expect all major vendors to embrace open standards like MCP, A2A or ACP to strengthen their own competitive position by avoiding the need for another vendor’s agent integration platform. Second, this way they can protect their own revenues in times of reduced importance of seat-based pricing. Welcome back to indirect access charges.
To make an implementation of an agent orchestration platform a success, businesses of all sizes need to have criteria of what constitutes good or desired outcomes, against which vendors and then the implementation can get measured. At the very basis, the chosen toolset needs to accomplish the job, i.e., orchestrate agents across applications fast and reliably. To accomplish this, it is likely that orchestration needs to happen on different layers, in-app, on a platform layer and/or on the front-end layer to support cross-app orchestration. It needs to provide guardrails, especially authentications and rules for escalating decisions or actions to humans and provide the observability that is necessary for its monitoring and an audit trail. A lock-in should be avoided as much as possible, so the technology stack should be open’ish instead of highly proprietary. I know that this is quite hard to achieve and that nearly every vendor attempts to create barriers to change.
The priorities of these criteria differs between sizes of businesses and even from business to business. E.g., a very small business is less likely to orchestrate agents on an application platform level than an enterprise. Likewise, enterprises that pursue a best-of-breed strategy are more likely to use infrastructure layer orchestration than application platform based orchestration. Of course, process complexities play a role, too.
So, let’s break this down in four categories, looking at enterprises with 1,000 or more employees, midmarket companies with 100 – 999 employees, small businesses with 3 – 99 employees and “solopreneurs” with one or two system users.
Enterprises
Enterprises target at achieving autonomous yet strictly governed cross-vendor operations at scale. They require strong audit, risk and change control built into the agent orchestration system.
These companies typically operate very complex, global, and heterogeneous IT environments that often include multiple CRMs and ERPs, deeply entrenched legacy systems, and hundreds of cloud applications. These companies have mature yet often understaffed IT, architecture, and development teams.
The goal is not only automation but achieving or retaining the ability to transform the business with the help of the agentic orchestration architecture.
Recommended strategy
Enterprises should architect and build out a composable, multi-layer “agentic mesh”. They should not seek to buy a single, all-encompassing solution. Instead, the strategy is to architect a resilient and adaptable agentic mesh that leverages a central platform, neutral integration layers, and open standards to enable interoperability and avoid vendor lock-in.
How to get there
Depending on what is already available in the company, a three-step roadmap should be employed.
Migration of ad-hoc agents to a central agent fabric and establishment of agent and action registries.
Implementation of least-privilege authorizations for the agents and actions and ensuring observability as well as approval workflows that cover development/deployment as well as runtimes.
Introduction of multi-agent patterns, e.g. planner/worker/validator, etc., to reduce risk and definition and measurement of service level objectives. The system needs to be increasingly self-healing and have roll-back possibilities.
Midmarket companies
Midmarket companies target at having a scalable, governed, cross-domain automation with clear ownership that over time can grow into an agentic mesh. These companies typically have multiple departments, each with established processes. The tech stack is already moderately complex and heterogeneous. It mostly includes a central ERP and a CRM alongside many departmental apps. There is a dedicated internal IT team.
The primary goal is to break silos and to move from departmental efficiency to end-to-end, cross-functional process automation and improvement.
Recommended strategy
Midmarket companies should build out a primary platform for agent orchestration while maintaining their flexibility. To select this platform, they should start at evaluating the application platform offerings of their core business application vendors. The focus of this evaluation are its capabilities to orchestrate agents outside of its vendor’s ecosystem.
How to get there
Depending on what is already available in the company, a four-step roadmap should be employed.
Selection of a small number, e.g. two to three, meaningful end-to-end processes for agentic automation.
Modeling of these processes in the agentic fabric and their instrumentation with relevant KPIs.
Use of agents only where they can get measured.
Increasing autonomy of agents with growing confidence, starting with safeguarding the agents behind human approval steps.
Small businesses
Small businesses typically want to reduce the number of manual hand-offs between a set of core applications while keeping governance simple. These businesses typically have small teams and growing process complexity, in combination with a collection of function-specific SaaS applications like a dedicated sales system, different marketing apps, a helpdesk tool, an accounting package, etc. IT support is often limited and/or outsourced.
The primary goal is to streamline core business functions and improve efficiency within departments.
Recommended strategy
Small businesses should build out in-app agentic capabilities and high-volume integrations. The focus should be on solving specific, high-impact business problems with the use of agents, e.g., within sales, marketing, and service, and then automating processes that span across the chosen core systems.
How to get there
Depending on what is already available in the company, a three-step roadmap should be employed. Two core objectives are speed of resolution and the avoidance of a vendor lock-in.
Selection of a number of high-volume flows, starting with automation via in-app agents, then connecting them across apps.
Definition of service level objectives with corresponding KPIs and measure, initially keeping human-in-the-loop steps which get removed with growing confidence.
Replacing of frontend-based integrations with API-based integrations
Solopreneurs
Solopreneurs are typically plagued by the need for entering the same data multiple times while operating on limited budgets. There is no dedicated IT staff, and a reliance on a handful of disconnected, low-cost SaaS applications.
Their goal is to automate time-consuming “swivel chair” processes to increase their personal productivity without creating administrative overhead and bigger expenses.
Recommended strategy
Solopreneurs should automate their time-consuming repetitive processes, focusing on personal productivity and simple connectors. This is best achieved using no-code tools that can deliver immediate time savings while not requiring technical expertise of significant investments.
How to get there
The immediate focus should lie on quick wins.
Definition of a small number of systems as sources of truth.
Identification and listing of swivel-chair tasks.
Automation using a lightweight no-code IPaaS tool in combination with browser agents, starting from easy, going towards difficult.
Summary
As you can see, these strategies and tactics form a graduation from simple to complex. The start is improving personal productivity via single tasks, followed by moving towards in-app agents and then an agent fabric with formalized guardrails and increased measurement of outcomes. From there, the orchestration system becomes a platform that ultimately offers a catalog of agents and their actions, credentials that support a tiered, trust-based autonomy model, supported by full observability.
If you need some help on this road, contact me.
Comments
Post a Comment