What, why and how of Agentic AI – A journey to mastering Agents

Yes, you have heard it right, AI agents are on a sprawl!

Everybody is talking about agents and building agents, but the main question is that is still pondering in everybody’s mind is – Can Agents do everything? Is it the magic recipe to solve the flood of AI projects I have in my backlog? Should I throw all my existing AI projects – Chat, RAG out of window? Let’s discuss it here.

When mostly discussing Agents in my day to day, there are mostly three main questions that are frequently revisited.

1. Why should I be using Agents?

2. What Agents are ? And what should I validate? – a must read

3. How do I effectively build Agents?

In this blog, we will look the first two in detail, which is the reason and fundamentals of building Agents. In upcoming blogs, I will got deep into some technical know and steps to build them.

So why should we be using Agents?

For some of teams or organisations the answer is ridiculously simple – Because everyone is building one and I want to be left out. Yes!!

Cool, that is great but should be the only reason? Let’s break it down below.

So if you are like me, who started building solutions using Generative AI when the first versions of GPT AI Completion came out, then you know the feeling of building an AI solution with House of Cards solution. It can crash at any time is the flow of context is not right or is lost or not properly referenced in history. The pains are ongoing and also combining all of the flow was a pain with multiple calls and back and forth.

So, yes, Agents to the rescue. In simple sense, below is my definition of AI Agents.

AI Agents are autonomous AI apps (obviously with bells and whistles) that work in scope of context provided to them either through the knowledge bases (vectorised) or through Tools (MCP or Function calling) or directly, in order to produce outcomes that can either referenced or acted upon.

In other words, Agentic AI provides a great framework to tie all the pieces together i.e. Prompts, Context and Outcomes. Oh my life is so easy now but wait there is one more.. Agents can call each other based on the Agent action context user questions or requirements. This is done through an orchestration flow or workflow of sorts that connects the agents and chains the flow together. Let’s look at some sample scenarios and examples.

Scenarios for an Agent

Agents can work in various scenarios starting from searching a Knowledge Source with basic RAG and Vector Database to complex workflows as shown in our below example. So the best aspect of an Agent is to use with scenarios where the solution can be:

• Searching or Summarising Information
• Connecting to a Structured or Propiertary Data source which can provide analytical data for the Agent
• Acting on a response based on User preference (via Agentic tool)
• Or something cool ..

Even just considering the above sample scenarios, the use of Agents is astronomical. To understand how, let’s for e.g. consider an example customer support scenario, I could have agents that can be chained and provide a seamless flow end to end flow. Below is an example flow for the Support Agent.

Example: Customer Support Agentic flow

Below are few Agents we could consider while building the Support Agent:

• Chat agent
• Triaging agent
• Research agent
• Ticketing agent
• Resolution agent
• Ticket summary agent
• Support Orchestration flow

In the above list of agents, each agent is tasked to perform a certain activity, the Support Orchestration flow connects and maintains the connection between the various task agents in a function calling scope. The flow logic can be driven with parameters between agents and passing context.

Below is a high level flow graph showing the interrelation of agents and calling parameters.

So as shown in the above flow, the agents share information and execute on the customer support flow. Each agent works on the context shared with it, calls tools, uses history and business logic to action on the tasks it is designed for. The major benefit of the Agentic flow is that we don’t need to build additional logic to indicate flow and share parameters.

Also, the other benefit is that it can be used across other scenarios or on its own for specific scenarios that allow better flexibility of reusing the same concept across organisations

So what are Agents?

One of main challenges, I have seen is that there is a growing confusion on what Agents are and an overlap with Agents, Tooling and automation flows. Let me try to call out some golden rules of what Agents are and how we should identify them.

1. The first main characteristic of the Agent is that they are Autonomous AI contextual flows. They can depend on information provided by tools and context through knowledge bases but can work on their own for their business purpose
2. Agents have a single purpose flow they are meant to execute on. Don’t make the agent context too broad as it could lead to issues such as Hallucinations, context switching, evaluation gaps
3. Agents are not APIs, or schedulers or jobs or react flows. They integrate with services and can be triggered through actions but are not meant to be logic flows or jobs. If they are just that we can excute them as Completion or chat endpoints, they still exist 🙂

So in a nutshell, Agents and Agentic flow provides the flexibility, interoperability, and scalability to scale requirements.

To evaluate the use of an Agent, we have to look at three clear goals as below:

1. Purpose:
   • Is there a need of a Smart logic (not programmable) that can assist in the process? This should be a Yes
   • Is there a need to have AI or just a simple automation process logic can suffix? This shouldn’t be doable through Automation
   • Is there Fuzziness in the requirement? This should be a Yes
2. Data (Tools):
   • Is there additional data required? This should be a Yes
   • How is the data fed into the Agentic flow? This should be on demand
   • Does data need clean-up? This should be a Big No
3. Output:
   • Is it a simple Yes or No? This should be a No
   • Does it need more massaging? This could be optional but should provide enough
   • Is it correct for use? This is important and even though we all believe AI, this should be validated (will write another blog on it)

How do I build Agents?

Building agents takes mulitple considerations around data, hosting and AI capabilities that are relevant for the Agent. It is not a direct answer to build an agent just because there is a prospective AI need or demand. We need to look at the scope of an AI Agent and the problem/value the Agentic flow is going to provide.

To build an agents, we have got Agent builders those can assist in managing some of the lifecycles of Agents. Some common ones are Vertex AI Agent builder, AI Foundry Agent Builder, Autogen, Open AI Agent builder, Langflow etc. Also, there are purposeful Agent builders such as Agentforce (Salesforce), Moveworks (ServiceNow), Copilot Studio and Agent Builder (Microsoft 365) and many more..

However, you could also code through an Agent (we will look at in the next blog..). In a brief, there is still a great demand of in-house Agent requirements because of protecting IP, data privacy and/or business requirements which requires Agents to be built from the code. Let’s discuss more in upcoming blog.

Conclusion

This is end of this blog but not to the discussion. If you recall my topic says – it is a Journey, so we are in a Journey to understand Agents and we have taken the first steps. In upcoming blogs, we will deep dive into some sample flows, tools, developer intensity elements and lot more ..

So stay tuned..