Not Everything Is An Agent

featured-image

Here is the criteria to determine whether to build an agent or simply create a workflow linked to a button.

Ian Gotts, founder and CEO at Elements.cloud . It is easy to be caught up in the excitement of this new, exciting, agentic world.

Everything you look at could be an agent, replacing boring form-based workflows. Recently, Microsoft CEO Satya Nadella, talking to Bill Gurley and Brad Gerstner on their BG2 podcast , suggested that business applications could “collapse” in the agentic AI era. His view was SaaS would be CRUD database with agents on top.



But not everything is an agent. Some of the earliest agents we built didn't necessarily need to be, but we wanted to deploy them just to get the experience of building an agent. For example, an employee booking their PTO .

What was interesting was thinking about the process showed us the existing workflow we'd built had flaws. And while it would work as a workflow, it is much nicer as an agent. We also discovered that building the agent was far easier than coding it and that it could be built, tested and deployed by a junior business analyst.

This got us thinking about the criteria to determine whether to build an agent or simply create a workflow linked to a button: • Do you want to shield/isolate the user from your terminology/notation/process? In our PTO example, an employee can say, "I want to take time off / I need to book PTO / I need to schedule vacation / I was off last week," and the agent understands. • Is the input unstructured data? Agents are great at making sense of this. An example would be pulling information from a call transcript and suggesting updates to the related opportunity.

Another example is our agent that provides coaching roleplay to our sales teams based on a customer call transcript. • Do you need to perform complex reasoning that would be complex to code? In our PTO example, we don't want employees to book time on a weekend or public holiday. We used a simple prompt template that has access to weekends and public holidays in the UK and U.

S., and the agent understands them. • Do you have complex validation rules where a rule is based on multiple field values? Again, an agent handles these if you give it the target output and think through the process.

The PTO example requires you to provide a start date and length of PTO that is not on a weekend/public holiday and does not span a calendar year, and you need enough left in your balance for the year based on the policies for your country and seniority. And you cannot book PTO in less than 1/2 increments. This is complex logic, but it's just a few agent instructions.

Easy to write, review, test and debug. • Do you need some form of planning that cannot be coded? For example, constructing a quote based on criteria: A customer wants X licenses and has a maximum budget of $Y but is prepared to do a one-, two- or three-year deal, so what is the best way to structure it? • Is it critical that the data is correct? Form filling can be overridden by users selecting the first dropdown or putting "..

." in a mandatory field. The agent can guide them to the correct answer but also reduce the effort because it can use context to pre-fill information.

As we get more patterns for agents, and the pricing is more transparent and realistic, then many automations could cost-effectively be replaced with agents. But at the moment, ROI and cost shouldn't be the gating factor. This is a major disruption, and you need to start building agents to ensure you have the right foundations in place: well-understood business processes, strong data governance and data quality, documented systems metadata.

And all this must be underpinned by a rapid but governed implementation lifecycle because agents will iterate fast at the beginning. Every organization will find use cases for agents that will provide a huge competitive advantage. But this is only going to happen if you start experimenting.

It's only when you get started that you will be able to uncover even more valuable use cases. Let's look at process configuration mining, for example. We've built an agent that can take a system's metadata and document how it works as a process diagram.

Not how you think it works. Not how you remembered it working. Not how the consultants said it worked.

Not how the design document said it should work. How it actually works. The process configuration mining agent is a combination of code and agent actions.

It wouldn't have been possible without the AI capabilities, which are an enabler. So not everything is an agent. But unless you start using simpler use cases, you may never discover a step change example.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?.