top of page

Which Automation Tools I Use for Operation-Heavy Environments and Hedge Funds

22 hours ago
6 min read

Updated: 14 hours ago

"What I am talking about when I am talking about automation and why it has less to do with AI agents than you might think." 


Introduction


When I talk about automation, I mean designing a process so that routine work such as moving information, applying rules, routing tasks or coordinating steps can happen with less manual effort. That can be done with software workflows, scripts, business rules, optimization methods  or decision-support systems (DSS). None of these requires an AI agent.


AI agents are one possible way to automate certain tasks, but they are not the origin of automation nor are they necessary for every automation project. A process can be automated without AI. For instance, a system can route an application according to fixed criteria, flag an exception or assign a task to the right team. The most difficult  part is often understanding the process, its exceptions, its decision points and the people and systems involved, not choosing the newest technology.


This distinction matters because starting with “Where can we use an AI agent?” or “All competitors are using it” can lead us to overlook simpler and more reliable solutions. A better starting point is: What work is being done, what problem are we trying to solve and which steps can be improved or automated? Once we understand the process, we can decide whether rules, workflow tools, optimization, AI or a combination of them is appropriate.


So when I discuss automation in this post and in general, I’m talking about the broader practice of analyzing and improving processes, not specifically about AI agents. AI may be part of the solution, but it is just one solution in a much longer history of process automation.


That said, automation did not enter our lives with AI agents. For years, people have studied processes by shadowing workers, applying industrial engineering methods, observing how work gets done and finding ways to streamline it. Operations research has also long addressed problems such as vehicle routing using heuristics, genetic algorithms and methods inspired by ant colonies. These approaches have supported decision-support systems (DSS) and other forms of intelligent automation well before today’s AI-agent boom. Ant colony optimization, for example, has been applied to vehicle-routing problems (VRP)s for decades. [1]


Why should we learn "old school" automation tools? Because:


  1. An AI agent may be able to automate a simple task, but designing an “automation project manager” agent for an entire department is much more challenging. Especially in operation heavy environments  work often spans multiple people/departments, processes and systems. AI can help, but it can also be costly and its output depends on how it is “instructed”  and “the systems” it can access. Coordinating and designing these projects still requires substantial human judgment.

  2. Tools help make work visible for us such as who is involved, what happens at each stage, where decisions are made and how one process depends on another. We wouldn't want to have black boxes in the systems design causing unprecented behavior.

  3. Implementing agent-based systems can also involve substantial work beyond the AI itself, including data preparation, coordination with stakeholders, governance and integration into existing workflows. [2]


During my PhD at the University of St Andrews, I particularly enjoyed working with the tools I will introduce below. They’re free to use, so you can explore them design actors/processes and try freely without turning to commercial alternatives. I’ll discuss their background, what they are used for, share useful learning resources and explain how they can help you design and understand interconnected processes without needing a subject matter/domain expert in a specific area.


The i* framework


i* models the people, teams and organizations involved in a process along with their goals and dependencies. Its two common views which serve different purposes: the Strategic Dependency (SD) view shows how “actors” depend on one another, while the Strategic Rationale (SR) view explores each “actor’s” goals, tasks, resources and their reasoning. [3] [4]


Why use it?

i* is useful early in requirements analysis especially when you need to understand the organizational context before deciding how to design or automate a solution. It can reveal handoffs, dependencies and competing goals that may be missed by looking only at a list of tasks.


What would it do for automation projects?

For automation projects, i* can help teams understand how work connects across people and organizations and where changes might affect others. i* helps clarify the problem and its context.


Example of i* framework for mobile banking illustrating SD and SR.


Infographic titled i* Model: Mobile Banking showing customer-bank transfer tasks, identity provider, payment network, and fraud monitoring.


KAOS

KAOS is a goal-oriented requirements method. It starts with the goals an organization or system needs to achieve, then helps refine them into more specific goals and requirements. It can also represent obstacles that could prevent those goals from being achieved. [5]


Why use it?

Use KAOS when a broad objective or task you are given needs to be translated into clear requirements and responsibilities. It helps keep the design connected to the original objective, rather than jumping straight to a proposed solution. Its goal-and-obstacle modeling can also help surface risks early.


What would it do for automation projects?

KAOS can help clarify what outcome a process change should achieve, what requirements follow from that goal, and what could block success. It doesn’t decide whether AI is the right solution; it helps define the problem and requirements first.


An example of Kaos goal modelling below [5]


NFR Framework

The NFR Framework focuses on non-functional requirements: qualities a system or process should have, such as usability, reliability, security, performance or flexibility. It treats these qualities as goals that may need to be balanced against one another. [6]


Why use it?


Many process-design decisions are not just about whether a system performs a task. They’re also about how well it performs it and what trade-offs that involves. The NFR Framework can make those quality goals and trade-offs more visible during design.


What would it do for automation projects?


For automation, it can help teams ask questions such as: How fast should the process be? How much human oversight is needed? What level of error is acceptable? What security controls are required? These questions can shape the solution before implementation begins.


An example of NFR Framework [6]




UML

UML (Unified Modeling Language) is a general purpose visual language for describing software systems. It includes different diagram types and use-case diagrams show how users interact with a system while structural and behavioral diagrams describe its parts and how they work. [7]


Why use it?


UML helps teams communicate a system’s design. The diagram they choose depends on what they need to explain for instance sequence diagram shows interactions in order, while an activity diagram maps a workflow.


What would it do for automation projects?


In automation projects, UML can document workflows, show how software components "communicate", and describe how a "system responds" to events. It focuses on representing the system and goal oriented approaches such as i* and KAOS help explain stakeholder goals and the reasons behind requirements. The approaches can complement each other. [8]


An example of UML [9]


Why are all these models important?


Together, these models answer different questions: i* helps explore actors and who depends on who and why; KAOS helps refine goals into requirements; the NFR Framework help reason about goals and trade-offs and UML help describe system interactions and design. Using them together can provide a clearer picture of the system, the process, and the system before deciding what to automate. Lastly BPMN can help us about the process flow where exactly automate.


To wrap up, AI is just one tool in the ongoing evolution of automation. Automation has existed long before AI and AI is not the first technology to help us automate work. As new technologies emerge, there will be new ways to improve processes so AI won’t be the last tool in automation’s evolution either.


*PS The modeling approaches described here can be studied, learned and applied without purchasing a commercial tool.



Resources

[1] Ant Colony Optimization: A Component-Wise Overview https://link.springer.com/rwe/10.1007/978-3-319-07153-4_21-2

[2] Agentic AI, explained Massachusetts Institute of Technology

[3] i* an agent and goal oriented modelling framework https://www.cs.toronto.edu/km/istar/

[4] RE-Tools: A Multi-notational Requirements Modeling Toolkit https://personal.utdallas.edu/~chung/Sam_Supakkul/RE-Tools/i-star.html

[6] Automated Non-Functional Requirements Generation in Software Engineering with Large Language Models: A Comparative Study https://arxiv.org/html/2503.15248v1

[7] UML Unified Modeling Language https://www.omg.org/spec/UML/2.5.1/About-UML

[8] Why Goal-Oriented Requirements Engineering https://www.cs.toronto.edu/pub/eric/REFSQ98.html







 
 
 

Comments


bottom of page