In the rush towards an agentic world, those who are excited about the potential seem to see everything as an agent. Some of our earliest use cases didn’t need to be, but we wanted to build them just to get the experience of creating an agent.
For example: employee booking their PTO. It was a well-established process that worked, supported by a Flow, so it was an easy agent use case. What was interesting was when we revisited the process, it showed us the existing Flow we’d built had flaws. And whilst the process could work as a revised Flow, it is much nicer as an agent. Also, building the agent was far easier than coding it.
Agents include automation
An agent delivers a business outcome by following a process. It may be fairly simple, like HR FAQ or, complex, like a sales coaching and training agent. Every agent needs to call actions that are going to be delivered by a workflow. Or, an action could also be an AI capability like a prompt template. So, every agent is going to be a combination.
Agents often use AI to bookend workflows, improving the user experience or enabling capabilities that are hard to code.
Criteria for “Is it an agent?”
Do you want to shield/isolate the user from your terminology / notation / process? In the vacation 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 AE coaching based on a customer call transcript
Do you need to perform complex reasoning that would be complex to code? In the vacation example: we don’t want employees to book a vacation that is on a weekend or public holiday. A simple prompt template that has access to weekend and public holidays in UK and US, and the agent works around 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 vacation example requires you to provide a start date and number of days, which are not a weekend/public holiday, not spanning a calendar year, and you need enough vacation left in your balance for the year based on the policies for your country. This is just a few boxes. 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 – Customer wants x licenses, but has a maximum budget of $Y but is prepared to do a 1, 2 or 3 year deal, so what is the best way to structure it?
It is 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.
Pricing should not be a barrier
As we get more patterns for agents, and the pricing is more transparent and realistic, then many automations could easily be replaced by agents. Some current use cases do not seem to be cost-effective at the moment, but as costs drop, they will become viable. Currently, there are a number of different models for agent pricing being proposed by the agent platform vendors. Mobile phones providers in the early days all had different talk plans, and then they all optimized to a single proce structure. I see agent platform pricing following a similar path. The only difference is choosing a mobile phone based on the pricing structure is a small commitment compared with selecting an agent platform.
I wrote a more detailed article on agent pricing considerations.
Process-led approach to designing agents
It doesn’t matter if you are building pure agents, agents with workflow, or just workflow, you need to design the agent from a process perspective. That means drawing a process diagram. There are a number of benefits of this approach:
- engage business users and agree on scope
- streamline and improve the process
- make architectural decisions: agent vs workflow
- make agent decision: actions vs instructions vs guardrails
- generate unambiguous instructions
- debug instructions during test
- explain behavior & get signoff
- demonstrate compliance
Here is an article on Governance.
Below is an example of an agent built using this approach, and it took less than a week. Elements.cloud – Sales Coach Agent – 5 days
The final word
Whilst not everything is a good candidate for an agent, taking the use case and mapping it out as a business process diagram will have significant benefits, even if it doesn’t result in building an agent.
Photo by Eric Krull on Unsplash
