In my quest to learn about Agents progressively, I’m currently taking the Google Cloud Agentic Summer course, powered by Gemini Enterprise Agent Ready (GEAR).
I’ll be making frequent posts to share and re-enforce my learning around agents and ai-native documentation here. So, if this is something you’re interested in, please feel free to work with me.
PS: The posts for this challenge will be an incorporation of my notes from the GEAR course and practical case studies of agentic documentation projects I try myself.
So, let’s get into it:
An AI agent is a software system that uses Artficial Intelligence, usually Large language model (LLM) to achieve a specific goal on behalf of the user.
Think of it as an assistant who can carry out a task on your behalf and has all the right tools needed to execute this task.
An agent at a basic level is made up of 3 major components:
LLMs are the thinking models of an agent. This means that the model has the ability to self-reflect built into it. These models are good for agents where tasks may be complex and the model needs to consider a set of ideas or responses before it makes the final response to the user or another agent.
Many agents use a protocol called Model context protocol (MCP) to access and use tools. MCPs are like an API except they provides an additional instructions about how an API is actually used and what the meaning of the inputs and outputs are. This gives the agent knowledge about when and where to use a specific MCP tool or an API in specific situations.
Memory in its simplest form is the context window for an agent. It enables the agent to act as a smart assistant that can keep track of continous threads of instructions.
There are other forms of memory like short term or long term memory that you can also put with an agent architecture.
Agent patterns are ways in which you can create an agent or how you can create a team of agents that work together for your goal.
The most basic agent pattern is an agent with no loops or other agents. In this example, the agents has a set of instructions, maybe some tools, and it’s connected to a model.
This pattern is useful for when we want to get started with an agent, or an agent where the object and directive is very clear. It’s also a great starting point for us to learn about agentic behaviour and then apply this to more complex use-cases down the road.
In the sub-agent pattern, the main agent handles most task. But will offer more specific or specialized task to another agent that it has access to.
In the sub-agent pattern, we typically hand-off a task for completion, but we are selective about the context that is applied.
We might do this for something like processing an invoice. Where the agents that actually gets invoice information from a document is a highly specialized agent and the overall agent is a general worker who can move the work from step-to-step to get it through the entire processing pipeline.
In this pattern, the starting agent starts as a router, the router agent then sends request along to the next agent that it has determined can best answer a request that a user or another agent has.
While the router may seem simple, identifying the intent that a user or another agent has, can actually be very difficult to do right. It has to be fast at doing this and to get the user to the right agent for the next level of intent, to answer a question for example. You can think of this like an overall agent that handles a store-front for questions related to ordering, orders or support, and has a handoff that intent to the next available agent in it.
These are only a few agent patterns, there are other agent patterns out there.