Blueprints for AI-Driven Automation: Mining a SaaS Dependency Network for Agent Toolkits and Workflow Scenarios

2.1 Automation Within the SaaS Ecosystem

SaaS has redefined the organizational technological landscape by providing scalable, cloud-based applications delivered via subscription models. In the realm of workflow automation, platforms such as Zapier, IFTTT and Make orchestrate cross-application processes through trigger-action primitives and public APIs. These platforms generate high-resolution operational logs, which serve as a critical resource for understanding digital transformation at the process level. Current literature on automation powered by SaaS generally converges into three research streams.

First, a significant body of work focuses on user behavior and business analytics. Oliveira et al. (2019) utilized SaaS automation logs to characterize usage patterns and identify drivers of productivity, while others have leveraged such data to predict customer churn (Ge et al., 2017) or analyze decision-making dynamics (Jiao et al., 2020). Second, research has concentrated on the technical evaluation of automation platforms, examining the functional limitations of services like Zapier (Coronado et al., 2015) and establishing typologies for comparative analysis (Abdou et al., 2021; Rahmati et al., 2017). Third, studies have explored the practical implications of automation on operational efficiency, particularly through process mining in IoT (Kim et al., 2022) and robotic process automation (RPA) (Aguirre and Rodriguez, 2017).

Despite these advancements, a notable theoretical gap remains. Existing research largely overlooks the latent structural interdependencies within end-to-end processes. Most studies treat SaaS applications as isolated entities rather than integrated nodes within a complex network, necessitating a more rigorous approach to recover the underlying execution structures hidden within automation logs.

2.2 Transitioning to AI-driven Automation: Agents and Intelligent Workflows

The automation landscape is undergoing a paradigm shift from static, rule-based mechanisms to intelligent, autonomous systems. The integration of large language models (LLMs) is transforming workflows from rigid script execution to dynamic, cognitive decision making (Hosseini and Seilani, 2025; Schwartz et al., 2023). This transition allows organizations to manage non-deterministic tasks that transcend simple trigger-action logic (Birr et al., 2024).

AI-driven automation can be bifurcated into two complementary paradigms: AI agents as autonomous actors and AI automation as intelligent workflows (Li, 2025). The agent-centric paradigm emphasizes autonomous actors capable of orchestrating tasks using a Toolkit, a collection of external APIs that extend the functional reach of the agent (Paranjape et al., 2023). However, most current frameworks rely on manually defined or retrieval-based tool selection (Lumer et al., 2024), failing to reflect the empirical co-usage ecosystems of SaaS applications (Mishra et al., 2024).

Conversely, the workflow-centric paradigm focuses on systems that learn from event logs to recommend or optimize process sequences (Maisenbacher and Weidlich, 2017). While advanced methods like graph neural networks (GNNs) and sequential models have been employed (Xiong et al., 2025), there is a persistent disconnect between granular data analytics and actual system design. Current research rarely utilizes the higher-order structures of SaaS dependency networks to inform the construction of toolkits derived from communities or reusable workflow components (Legallois and Koch, 2020).

This gap indicates the need to move beyond adoption-oriented or performance-oriented analyses of SaaS systems toward a design-oriented view of AI automation. In such a view, workflow data are not only retrospective records of system use but also empirical design resources that reveal which applications tend to work together and in what order they are connected. This perspective is particularly relevant for AI agents and intelligent workflows because their performance depends not only on model capability but also on the configuration of external tools, task sequences, and operational contexts. Therefore, a network-based analysis of SaaS dependencies can provide a structural foundation for translating observed usage patterns into agent Toolkits and reusable workflow components.

2.3 Motif Analysis as a Structural Framework

To bridge the gap between empirical data and AI system design, this study adopts motif analysis. A network motif is defined as a subgraph that appears in an empirical network significantly more frequently than in randomized networks (Milo et al., 2002). Motifs function as the fundamental building blocks of complex systems, much like logic gates in electronic circuits (Alon, 2007).

<Figure 1> illustrates fundamental motif structures identified across different complex systems, ranging from biological gene regulation to the World Wide Web. Specific topologies, such as the ‘Feed-forward loop’, act as functional units for signal processing or noise filtering (Mangan et al., 2003), while ‘Bi-fan’ and ‘Feedback’ structures represent distinct coordination patterns. While motif analysis originated in the natural sciences for disease pathway prediction (Agrawal et al., 2018) and molecular substructure identification (Zhang et al., 2021), it has increasingly been applied to social and online networks to reveal organizational fingerprints and community structures (Li et al., 2017; Topirceanu et al., 2016).

Figure 1.

Example of Network Motifs (Milo et al., 2002)

Methodologically, the field has evolved from exact counting algorithms like FANMOD (Wernicke, 2006) to deep learning-based approaches such as DotMotif (Matelsky et al., 2021). This study specifically utilized SPMiner (Ying et al., 2024), a GNN-based framework that autonomously discovers frequent motifs without prior knowledge. By identifying these recurring higher-order patterns, we can derive structurally grounded toolkits and workflow recommendations that faithfully mirror real-world SaaS automation ecosystems, providing a meso-scale representation that facilitates evidence-based AI design (Jazayeri and Yang, 2020). In this study, motif analysis is therefore used not as an end in itself, but as a structural bridge between empirical SaaS dependencies and actionable automation design.

3.1 Data Collection and Domain Selection

To implement the proposed framework, this study collected empirical workflow data from Zapier, an integration platform that facilitates automation consisting of SaaS applications. The data collection, conducted in April 2025, targeted the HR domain. HR was selected as the empirical domain for three reasons. First, HR processes are highly repetitive and process-oriented, including recruitment, onboarding, training, assessment, scheduling, and employee communication. These characteristics make HR suitable for observing sequential automation patterns. Second, HR work frequently requires cross-functional interactions across multiple SaaS applications, such as applicant tracking systems, learning management platforms, calendars, email services, document tools, and communication platforms. This makes the domain appropriate for analyzing SaaS-to-SaaS dependencies. Third, as organizations undergo digital transformation, HR has increasingly adopted automation to reduce manual coordination and improve responsiveness, making it a relevant setting for studying AI-driven workflow configuration (Sestino and De Mauro, 2022). Therefore, the HR domain provides both practical relevance and sufficient structural complexity for examining how empirical SaaS workflow data can be transformed into AI automation design resources.

A custom web crawler developed in Python was employed for the collection process. We collected data on all SaaS applications categorized under HR and their associated Zap templates. In this context, a Zap represents a sequential workflow where a Trigger from one application initiates Action in others. A total of 249 SaaS applications were collected. However, applications with no associated Zaps were excluded, resulting in a subset of 190 target SaaS applications. The final dataset comprised 5,602 valid Zap templates. The distribution of these templates by length is summarized in <Table 1>.

Table 1.

Distribution of Human Resources Zap lengths in Zapier

3.2 SaaS Dependency Network Construction

The network construction process involves projecting the bipartite structure of Zap-SaaS incidence onto a homogeneous directed graph, G=(V,E), where V denotes the set of SaaS applications and E represents the functional dependencies between them. Unlike traditional process mining that focuses on individual execution instances, this study aggregated immediate adjacencies across thousands of templates to capture pattern-level sequential dependencies. The overall process of SaaS dependency network construction from Zap data is explained in <Figure 3>.

Figure 3.

Network Construction Process

An ordered pair (a,b) is assigned to a directed edge if SaaS a(the source) is immediately followed by SaaS b (the target) within a Zap template. A Zap template with a sequence [a→b→c→d→e] therefore contributes one count to each of the ordered pairs (a,b), (b,c), (c,d) and (d,e). Let C_ab denote the number of Zaps in which a is followed by b (immediate adjacency). To ensure the network reflects substantively significant ties rather than idiosyncratic user preferences, we applied a directed variant of association strength (Eck and Waltman, 2009) for normalization:

Here, $$ W_a^{out}$$ is the total number of immediate sequential connections that originate from a to any SaaS, and $$ W_b^{in}$$ is the total number of immediate sequential connections that terminated at b from any SaaS. S_ab represents the normalized strength of a directed connection from a to b. This normalization accounts for the differing popularity of applications, allowing us to identify latent design opportunities that are structurally significant within the SaaS ecosystem.

To enhance interpretability and focus on the backbone of the SaaS ecosystem, the normalized matrix was dichotomized using a threshold τ. Following a sensitivity analysis across values 0.001, 0.005 and 0.01 (Borgatti et al., 2024), we selected τ=0.005. This threshold was found to effectively filter out weak, idiosyncratic ties while preserving the essential connectivity required for downstream motif analysis and community detection.

The resulting SaaS dependency network consists of 678 nodes and 938 edges, with a density of 0.002. This sparse yet structured graph, visualized in <Figure 4>, represents the empirical foundation upon which our AI agent Toolkits and workflow recommendations are constructed. By transforming ad-hoc automation logs into this structured representation, we provide the evidence-based methodology necessary for next generation AI-driven system design.

Figure 4.

SaaS Dependency Network

4.1 Motif Extraction

SPMiner (Ying et al., 2024) consists of an encoder-decoder pipeline. The encoder learns graph-level and subgraph sensitive representations that preserve relations among substructures. The decoder then infers highly frequent subgraphs over a collection of graphs, which can be interpreted as the discovery of motifs suitable for downstream analysis. In its original formulation, SPMiner assumes an undirected graph setting. Therefore, additional care is required when the application depends on the order of interaction, as is the case in workflow automations where execution proceeds from an upstream component to a downstream component. In addition, motif extraction in this study operates on an aggregated SaaS dependency network, not on individual Zap instances. As a result, a mined linear motif should not be interpreted as a verbatim reconstruction of a single end-to-end template. Instead, motifs represent reusable sequential design patterns that emerge from repeatedly observed adjacent dependencies and can suggest compositional workflow candidates beyond explicitly authored sequences.

For subgraph matching, the encoder of SPMiner is instantiated with GraphSAGE and trained while explicitly preserving the direction of edges in the Zap workflow graph. Training is conducted on the complete HR SaaS network so that the learned embeddings reflect global structural regularities as well as local ordering. And then, for subgraph mining, the decoder of SPMiner performs motif discovery under a directed assumption using the post cut-off HR SaaS network as input to remove extremely weak ties prior to search. Following the experimental protocol of the original study, the search procedure is implemented with Monte Carlo Tree Search, which effectively explores the subgraph space by balancing the expansion of promising candidates with continued exploration of alternatives.

Formally, SPMiner maps graphs into an order embedding space where the subgraph relationship is preserved geometrically. Let $$ \mathrm{\varphi }:G\to {\mathbb{R}}^d$$ be the embedding function. The order embedding constraint asserts that if a graph A is a subgraph of (denoted as A ⊆ B), then their embeddings must satisfy the inequality ϕ(A) ≤ ϕ(B) element-wise. To enforce this property during the training of the encoder, the model minimizes a margin-based ranking loss involving a penalty term E(A,B), which is defined as:

Here, a penalty of zero (E(A,B) = 0) indicates that the subgraph order constraint is satisfied, implying the model is confident that A is a subgraph of B.

In the motif discovery phase, the decoder aims to identify a subgraph pattern G of size k that appears frequently in the target graph G_T. Instead of computationally expensive exact counting, SPMiner utilizes a soft frequency objective m (G). This objective aggregates the order embedding violations against the set of all node-anchored neighborhoods N extracted from the target graph:

The estimated frequent motif G_freq is obtained by finding the subgraph that minimizes this total penalty m (G). This formulation allows the search procedure to effectively navigate the embedding space via a monotonic walk. As established in the methodology, iteratively adding nodes to a candidate subgraph results in a monotonic increase in its embedding coordinates.

To align motif discovery with the objective of recommending executable workflows, the end-to-end pipeline is modified to impose strict structural constraints on the search procedure. The restriction to directed linear paths is an intentional design boundary rather than an assumption that all business processes are linear. The objective of this study is not to reconstruct a complete process model such as a business process model and notation (BPMN) diagram, but to extract sequential workflow fragments that can be directly transformed into AI automation templates. Unlike the original formulation where the walk allows for expansion into any arbitrary connected subgraph, this study introduces a sequential constraint that restricts the valid transition steps in the embedding space. Specifically, the expansion mechanism is constrained to only permit the addition of nodes that extend the current subgraph into a linear sequence, that is, a path graph, thereby explicitly prohibiting branching operations and cycles. This constraint effectively prunes the search space during the walk, ensuring that the optimization of m (G) is performed solely over the set of directed linear paths. Consequently, the pipeline operates on fully directed structures, preserving edge orientation throughout both representation learning in the encoder and the constrained enumeration in the decoder. This design supports interpretability, preserves execution order, and helps keep downstream scenario generation aligned with sequential workflow fragments rather than unsupported branches, conditions, or loops. Even if a complete end-to-end Zap sequence is not present in any individual Zap, a directed path-like motif remains a potential candidate for authoring so long as each adjacent dependency along the path is strongly supported in the aggregated network.

Under this sequential constraint, motifs are defined as path-like subgraphs. No global upper bound is imposed on their length. This approach allows the procedure to capture the short, medium, and long routines encountered in practice. In addition, size-specific searches are conducted on fixed path lengths. These searches serve two purposes. First, they enable comparative analyses across different levels of procedural complexity. And second, they facilitate template selection for recommendations. This combination of directed learning, sequential filtering, and flexible yet size-aware extraction yields motifs that directly mirror how users compose workflow automations. As a result, this method improves the fidelity of subsequent automation recommendations. As illustrated in <Figure 5> and <Figure 6>, the comprehensive set of motifs has been extracted from the SaaS dependency network.

Figure 5.

Extracted motifs (length three to five)

Figure 6.

Extracted motifs (length six to eight)

4.2 Workflow Scenario Generation

To translate the motifs extracted from the network into actionable workflows, this research utilizes a scenario generation procedure based on an LLM configured for few-shot learning. Although motifs encode validated SaaS sequences as directed path-like structures, they remain structural artifacts that specify connectivity and execution order but do not fully articulate the operational semantics required for implementation, such as trigger-action intent, data artifacts exchanged across steps, and the business objective that the sequence fulfills in an HR process. This gap is especially consequential for AI automation, which is pre-defined and non-autonomous. Unlike an AI agent that can plan and disambiguate underspecified steps at runtime, a pre-defined workflow must be explicitly specified before execution begins. Accordingly, the LLM is used as a prompt-based generator that instantiates the semantics of each motif while preserving its topology, producing human-readable scenarios that can serve as initial candidates for AI automation template design.

This research uses the GPT-5 model to translate the extracted SaaS motifs into actionable workflow scenarios. The role of the model is limited to bounded structure-to-text generation rather than unrestricted workflow ideation. In other words, GPT-5 is not used to freely invent new automation processes, but to convert network-derived motif structures into natural language scenarios while preserving the sequence, node composition, and domain context of the original motifs.

For each motif, GPT-5 is provided with structured input consisting of the ordered list of SaaS applications, brief functional explanations of each application, and the community information to which the applications belong. The prompt was designed around six constraints. First, the model must preserve the execution order encoded by the directed motif. Second, it must include all SaaS applications in the motif without skipping any node. Third, it must not add SaaS applications or external tools that are not included in the motif. Fourth, it must describe how data or events flow from one SaaS application to the next. Fifth, it must identify a clear trigger and final outcome for the automation. Sixth, it must interpret the motif within the HR workflow automation domain. These constraints were introduced to reduce unsupported generation and to ensure that the generated scenarios remain grounded in the motif structure. The concrete instructions used in the prompt are explained in Appendix A.

The generated scenarios were subsequently reviewed for structural consistency with the motifs from which they were generated, rather than treated as independently validated business process models. This step is not a quantitative conformance evaluation in the sense of process mining, where a process model is compared against an external event log. Instead, it is a prompt-grounded review that verifies whether the constraints specified in the prompt are reflected in the LLM output. The review drew on the general logic of conformance and process quality in process mining and process modeling research, which emphasizes preserving relevant activity order, avoiding unsupported behavior, and maintaining a coherent process description (Rozinat and van der Aalst, 2008; Buijs et al., 2014; Mendling et al., 2010). In this study, the check focused on whether each scenario preserved the directed order of the motif, included all SaaS applications in the motif, avoided adding unsupported SaaS applications or external tools, described a plausible data or event flow, and remained consistent with the HR workflow context. Therefore, the purpose of this step was not to claim field-level validation of the generated workflow, but to ensure that the LLM output remained a structurally grounded interpretation of the network-derived motif.

<Figure 7> presents one of the example motifs (5-5) and its corresponding workflow scenario. The goal of this automation is connecting assessment results to improvement tasks, performance tracking, and recruitment opportunities in a single HR workflow. The scenario is as follows:

Figure 7.

Extracted motif 5-5

When an evaluation is completed in “Cloud Assess” (online assessment and training solution for corporates, training providers, and government entities), scores and competency recommendations for each employee are generated and passed into the automation. These results flow to “monday.com” (work management platform for projects and task coordination), where concrete improvement tasks are automatically created with clear owners, deadlines, and priorities aligned to the identified skill gaps. As employees complete these tasks, “AssessTEAM” (cloud-based performance and productivity analysis software) logs outcomes, updates performance profiles, and, when appropriate, triggers new review cycles. “Gmail” (email service) then delivers targeted follow-up messages to employees and managers, such as sharing assessment results, notifying them of new development plans, or recognizing progress. For individuals identified as high-potential talent, “100Hires ATS” (recruitment software with applicant tracking) creates or updates candidate records in a talent pool, so they can be considered for internal promotions or future openings. This scenario ties assessment, development actions, performance monitoring, and talent pipeline building into one coherent, sequential workflow.

Reviewing the scenario in <Figure 7> against the criteria above indicates that the directed order of the motif is preserved, all five SaaS applications are included, no external tool is introduced, the data flow from assessment completion (trigger) to talent-pool registration (outcome) is articulated, and the description remains consistent with the HR assessment-to-recruitment context. This example illustrates how a network-derived motif can be translated into a human-readable workflow recommendation while preserving the sequence of SaaS applications. Rather than validating the workflow as an operationally deployed process, the scenario demonstrates how motif-based logic can provide an empirically grounded starting point for further specification, evaluation, and implementation.

5.1 Community Detection

Community detection provides a principled way to reduce the complexity of large co-usage networks, while preserving their meso-scale organization (Lancichinetti and Fortunato, 2009). In contrast to centroid-based methods such as k-means, commonly used network approaches do not require predefining the number of clusters and can better respect inherent topology of the graph (Blondel et al., 2008). Moreover, community methods can expose multi-level structure when combined with hierarchical or aggregation strategies, thereby supporting both overview and drill-down analysis (Bonald et al., 2018; Lancichinetti and Fortunato, 2009). These properties improve interpretability, scalability, and robustness for empirical studies of complex networks.

This study employs the Leiden algorithm (Traag et al., 2019) to identify communities in the HR SaaS network. This method addresses well known limitations of the conventional Louvain algorithm (Blondel et al., 2008) and is suitable for large-scale networks. Leiden iteratively relocates nodes to neighboring communities to improve the chosen quality function and modularity. It refines each community into connected subparts to guarantee the internal connectivity of all communities and then aggregates the updated communities into super-nodes. By repeating this refinement aggregation cycle, Leiden typically yields more suitable partitions and better connected communities.

The Leiden algorithm is particularly appropriate for the objective of this study because the resulting communities are used not merely as descriptive clusters but as candidate Toolkits for AI agents. A Toolkit should consist of applications that are not only similar in function but also structurally connected within actual workflow configurations. The connectivity guarantee of Leiden therefore supports the interpretation of each community as a coherent set of tools that can be jointly considered by an agent. In addition, Leiden does not require the number of communities to be specified in advance, which is useful when the natural grouping of SaaS applications is unknown. The resolution parameter also enables the analysis to control the granularity of communities so that the resulting Toolkits are neither too broad for practical agent planning nor too narrow to support meaningful workflow composition.

The community detection procedure in this study proceeds as follows. First, partition the graph into very small initial communities. The algorithm then merges communities with high similarity, where similarity is defined as the inter-community connection strength, measured as the sum of edge weights between two communities. After obtaining an initial partition, search over the resolution parameter and the random seed to satisfy community size constraints, targeting communities with a minimum of 10 nodes and a maximum of 20 nodes. The resulting medium sized communities capture groups of SaaS applications that organizations frequently use together when implementing HR workflow automations. Each community can be interpreted as a candidate Toolkit for an AI agent, that is, a coherent set of tools that can support related HR tasks.

Community names, descriptions and all the SaaS applications of each community are listed in Appendix B. The names and the descriptions of each community were written in consideration of the information of the SaaS applications belonging to that community and their purpose in automating HR tasks. <Figure 8> visualizes their placement in the SaaS dependency network. These labeled communities constitute the Toolkit from which the AI agent can later select appropriate tools when constructing HR automation workflows.

Figure 8.

Human Resources SaaS Communities

5.2 Toolkit Suggestion from Community

The communities derived from the SaaS network constitute an agent-facing Toolkit for composing business automation in the HR domain. In this study, Toolkit is defined as a context specific repository of SaaS applications that share a common usage purpose and operational context within HR workflows. For an AI agent to construct valid HR automations, it must select tools that are not only functionally capable but also contextually appropriate. Without a predefined structure, an agent faces a global search problem across the entire SaaS catalog, leading to combinatorial complexity and the risk of contextual hallucination, such as combining incompatible tools simply because they share a generic API feature. By conceptualizing the detected communities as Toolkits, this study furnishes the AI agent with a detailed repository of resources. When a specific HR task is requested, the agent first identifies the relevant Toolkit, constraining the subsequent planning process to a safe, empirically validated set of tools known to work together for that specific domain.

The following scenario illustrates how an AI agent can leverage specific communities as Toolkits, thereby demonstrating the practical utility of this approach. First, consider a recruitment scenario where a user requests a workflow to send updated emails to candidates who passed an interview and automatically schedule a follow-up call. The agent analyzes the semantic intent and maps the request to Community 19 (Candidate Communication). Instead of searching the entire catalog, the agent activates this specific Toolkit and constructs a pipeline using only its member applications. For instance, it configures a trigger based on candidate status changes in “ATS Anywhere”, chains this to a personalized notification via “Email by Zapier” and generates a meeting link using the scheduling features within “Bullhorn CRM” or “Palm.hr”. This constraint ensures the agent builds a coherent recruiting workflow without accidentally invoking internal messaging tools or unrelated marketing platforms. A detailed explanation of this case is provided in <Figure 9>.

Figure 9.

Overview of how AI Agent uses the Candidate Communication (19) as a Toolkit