Agentic AI: Step-by-Step Examples for Business Use Cases

Now that we’ve covered the foundations and tools, let’s bring it all together with real-world business use case examples. In this final article of the series, we’ll walk through three detailed examples of agentic AI applied to common business scenarios: (1) a Customer Service AI Agent, (2) a Task Automation Assistant, and (3) an Internal Knowledge Base Assistant. For each example, we’ll discuss the design, show the Python code (using the frameworks introduced), include a visual diagram of the agent’s architecture, and explain the reasoning behind the tool and framework choices. These step-by-step examples will demonstrate how to go from a problem description to a working agentic solution.

Moving from demo to deployed agent is where most teams fail; we walk through that transition in Cohorte's Building Accountable AI Agents course (E3).

Example 1: Customer Service Virtual Agent

Use Case: A company wants an AI agent to handle customer support queries. This agent should be able to answer frequently asked questions by retrieving information from a knowledge base, perform simple account actions (like checking order status or opening a support ticket), and escalate complex issues to a human if needed. We’ll design a Customer Service Virtual Agent that can do the following:

• Greet the user and understand their question.
• Use a knowledge base tool to find answers for informational queries (e.g., “What is your return policy?”).
• Use an order API tool for questions like “Where is my order #12345?”.
• If the query is beyond its capability, politely inform the user that a human rep will follow up (and perhaps log the query for human review).

Framework choice: We’ll use LangChain for this example because it allows easy integration of a Q&A knowledge base and custom tools. LangChain’s agent can handle the decision-making of whether to use the knowledge base or the order API. We’ll assume we have:

• A small FAQ document or vector store for general questions.
• A dummy order database or API function to get order status.

Architecture Diagram: The agent here is a single LLM-based agent with two tools: a KnowledgeBase (a retrieval QA tool that returns an answer from documentation) and an OrderStatus tool (function that looks up an order). The flow is: User query -> Agent -> (optional tool usage) -> Agent answer to user. Below is a conceptual diagram:

Step-by-Step Implementation:

1. Setup knowledge base: Let’s create a simple knowledge base. In a real scenario, this could be a vector database containing embeddings of FAQ answers. For our example, we’ll simulate with a dictionary of Q&A.
2. Define tools: We will have faq_search(question) that returns a relevant FAQ answer (if any), and get_order_status(order_id) that returns a fake order status.
3. Initialize agent: Use LangChain’s initialize_agent with these tools.
4. Run agent with example queries.

from langchain.agents import initialize_agent, Tool
from langchain.llms import OpenAI

# 1. Knowledge base setup (simple dict for demo)
FAQ_DB = {
    "return policy": "You can return any item within 30 days of purchase with a receipt for a full refund.",
    "shipping time": "Orders typically arrive within 5-7 business days via standard shipping.",
}
def search_faq(query: str) -> str:
    """Very basic FAQ search: returns an answer if query matches a known FAQ."""
    for key, answer in FAQ_DB.items():
        if key in query.lower():
            return answer
    return ""  # empty string if no match found

# 2. Define the tools
def get_order_status(order_id: str) -> str:
    """Dummy order status lookup."""
    # In real life, call database or API
    return f"Order {order_id} is currently being processed and will ship in 2 days."

tools = [
    Tool(name="KnowledgeBase", func=search_faq, 
         description="useful for answering common questions from FAQs or policy documents"),
    Tool(name="OrderStatus", func=get_order_status,
         description="useful for checking the status of an order by order number")
]

# 3. Initialize the LLM and agent
llm = OpenAI(model="gpt-3.5-turbo", temperature=0, openai_api_key="YOUR_OPENAI_API_KEY")
agent = initialize_agent(tools, llm, agent="zero-shot-react-description", verbose=True)

# 4. Simulate user queries
queries = [
    "Hi, what's your return policy?",
    "Where is my order 12345? It was supposed to be here by now.",
    "Do you ship internationally?",
]
for q in queries:
    print(f"User: {q}")
    response = agent.run(q)
    print(f"Agent: {response}\n")

Let’s go through what happens for each query:

• Query 1: “What’s your return policy?” The agent should identify this as a FAQ-type query. The KnowledgeBase tool likely gets triggered. The agent might think: “This sounds like a common question. Use KnowledgeBase.” It calls search_faq, which finds “return policy” key and returns the answer. The agent then replies with that answer. The output could be: “Our return policy is: You can return any item within 30 days of purchase with a receipt for a full refund.” (Given we put verbose=True, you would see the chain of thoughts and the tool invocation in the console logs – confirming it used the KnowledgeBase tool.)
• Query 2: “Where is my order 12345?” The agent will parse this, likely noticing the pattern “order [number]” and decide to use the OrderStatus tool. It calls get_order_status("12345"), gets back the dummy status, and responds: “Your order 12345 is currently being processed and will ship in 2 days.” If this question also contained something like “... it was supposed to be here by now”, the agent might combine an apology or explanation along with the tool result. The agent’s LLM can merge tool outputs with a conversational tone.
• Query 3: “Do you ship internationally?” Suppose our simple FAQ search doesn’t have a direct match for “ship internationally”. search_faq might return "". The agent gets no useful info from that tool (it might try it and see no answer). Now, since we didn’t explicitly code this info, the agent might either A) know from training data (GPT-3.5 might guess a generic answer), or B) say it’s not sure. Ideally, in a real system, we’d have this in our knowledge base. But let’s say it isn’t. The agent might reply, “I’m sorry, I don’t have that information. Let me connect you with a human representative for further assistance.” This would be the fallback behavior. We didn’t explicitly code escalation, but we could: one approach is to have a threshold that if no tool gives an answer and LLM isn’t confident, it says it will escalate. LangChain doesn’t do this automatically, but we can incorporate it via prompt engineering (e.g., in the system message we instruct: “If you are unsure or it’s outside knowledge, respond with a deferral to human.”). For brevity, assume the model handles it gracefully on its own.

Design Decisions: We chose LangChain because it made integrating an information retrieval step straightforward. We used a Zero-shot ReAct agent which decides on its own which tool to use for each query – this dynamic decision-making is crucial in support scenarios (the agent must distinguish informational vs account-specific queries). We kept the tools simple; in production, search_faq could be replaced by a vector search using LlamaIndex or LangChain’s vector store, for more robust semantic matching. The get_order_status tool in real life would query a database. Security-wise, we’d ensure the agent only calls OrderStatus for properly formatted order IDs, etc. The agent’s prompt (handled by LangChain internally for this agent type) includes descriptions of each tool, so it knows when to use them.

This example shows an agent that can automate tier-1 support: answering common questions and handling simple tasks. This frees up human agents to deal with more complex issues. It also shows how combining retrieval (knowledge base) with action (API calls) allows the agent to be both informative and performative.

Example 2: Task Automation Assistant (Email Scheduler Agent)

Use Case: Many professionals spend time on small repetitive tasks, such as scheduling meetings or sending follow-up emails. We’ll create a Task Automation Assistant that can understand a natural language request to schedule a meeting and then perform the steps to actually schedule it (in a simplified manner). Specifically, the agent should:

• Parse a request like “Schedule a meeting with John next week about the Q3 budget.”
• Check the calendars (we’ll simulate calendar availability).
• Propose a time, possibly by consulting both parties’ free times (we’ll simplify with dummy data).
• Draft an email invitation to John with the details.

This is a multi-step workflow: understanding the intent, retrieving data (calendars), making a decision on time, and producing an output (email). It’s a good candidate for a code-centric agent because it involves procedural logic (finding a common free slot). We will use SmolAgents for this, letting the agent write some code to handle the scheduling logic.

Framework choice: SmolAgents allows the agent to use Python tools. We’ll provide:

• A get_free_slots(person, week) tool that returns free time slots for that person (dummy data).
• A send_email(to, subject, body) tool that doesn’t actually send an email but simulates that action (printing or storing the output).
• The agent’s job is to use these to achieve the goal.

Architecture Diagram: Here, we have one agent that will likely utilize multiple tools in sequence. The architecture is simpler (it’s a single agent with tools, like before), but the internal logic is more complex (the agent essentially writes a mini program). We can depict it like: User instruction -> Agent (LLM) -> [calls Calendar Tool for Person A] + [calls Calendar Tool for Person B] -> Agent computes common time -> [calls Email Tool] -> outputs confirmation to user.

We can draw a flow diagram:

1. Input: “Schedule meeting with John next week re: Q3 budget.”
2. Agent uses Calendar tool for “me” and for “John”.
3. Agent finds a matching free slot.
4. Agent uses Email tool to draft invite.
5. Agent outputs, e.g., “I have scheduled a meeting on [date time] and sent an invite to John.”

We’ll assume it’s okay for the agent to finalize without human confirmation for this demo (though in practice, one might want a confirmation step).

Now, implementing this:

from smolagents import tool, CodeAgent, OpenAIServerModel

# Dummy data: free slots for each person (just simple dict of person -> slots)
FREE_SLOTS = {
    "me": ["Mon 10am", "Tue 2pm", "Wed 1pm", "Fri 4pm"],
    "john": ["Tue 2pm", "Wed 1pm", "Thu 9am"]
}

@tool
def get_free_slots(person: str, week: str = "next") -> list:
    """Return a list of free time slots for the given person for the next week."""
    # Ignoring 'week' in this dummy implementation
    person_key = person.lower()
    if person_key in FREE_SLOTS:
        return FREE_SLOTS[person_key]
    else:
        return []

@tool
def send_email(to: str, subject: str, body: str) -> str:
    """Simulate sending an email by returning a confirmation string."""
    print(f"--- Email to {to} ---\nSubject: {subject}\nBody:\n{body}\n--- End Email ---")
    return f"Email sent to {to}"

# Initialize the agent's LLM model (using GPT-3.5 for cost, but GPT-4 might be better for complex tasks)
model = OpenAIServerModel(model_id="gpt-3.5-turbo", api_key="YOUR_OPENAI_API_KEY")
agent = CodeAgent(tools=[get_free_slots, send_email], model=model)

# User request to the agent
request = "Schedule a meeting with John next week about the Q3 budget review."
result = agent.run(request)
print("Agent final response:", result)

When we run agent.run(request), behind the scenes, the agent (GPT-3.5) will receive a prompt listing the tools get_free_slots and send_email with their docstrings, plus the user request. It will ideally output a plan in Python code. The code might look like:

slots_me = get_free_slots("me")
slots_john = get_free_slots("john")
# find a common slot
common = None
for slot in slots_me:
    if slot in slots_john:
        common = slot
        break
if common is None:
    print("No common free slot found next week.")
else:
    subject = "Meeting invite: Q3 Budget Review"
    body = f"Hi John,\n\nCan we meet on {common} next week to discuss the Q3 budget? Let me know if that works for you.\n\nThanks!"
    send_email("[email protected]", subject, body)
    print(f"Scheduled a meeting on {common}. An invite has been sent to John.")

This is a plausible piece of code the LLM could generate given the task. Let’s analyze it:

• It calls get_free_slots("me") and get_free_slots("john"). Our dummy functions will return lists of free times.
• It then finds the first common slot.
• If found, it prepares an email subject and body, then calls send_email with John’s email, subject, and body.
• It prints a confirmation message.

SmolAgents will execute this code. The get_free_slots calls return data from FREE_SLOTS. Suppose "Tue 2pm" is common (from our dummy data, both have Tue 2pm and Wed 1pm as common). It picks "Tue 2pm". Then it calls send_email, which will print the email content:

--- Email to [email protected] ---
Subject: Meeting invite: Q3 Budget Review
Body:
Hi John,

Can we meet on Tue 2pm next week to discuss the Q3 budget? Let me know if that works for you.

Thanks!
--- End Email ---

And send_email returns "Email sent to [email protected]". Finally, it prints the confirmation: "Scheduled a meeting on Tue 2pm. An invite has been sent to John." SmolAgents captures that print output as the agent’s final answer.

The final result printed would be:

Agent final response: Scheduled a meeting on Tue 2pm. An invite has been sent to John.

This demonstrates the agent effectively performed the scheduling task autonomously.

Why this design: We used SmolAgents because the problem required a bit of logic (finding common time) that is easier to express in code than in pure natural language prompts. By giving the agent get_free_slots and send_email tools, we allow it to gather info and take action. The agent’s LLM filled in the logic of finding the common slot. If we tried this with a pure LangChain approach, we’d have to rely on the LLM to reason about lists of times without error, which is harder to guarantee. Here, by writing a little loop in code, the LLM can leverage the deterministic nature of Python to get it right.

Extending this: In a real system, get_free_slots would connect to actual calendar APIs, and send_email would actually send an email or create a calendar invite. You might also have more error handling (if no common time, maybe the agent suggests some alternatives or asks for a new time). You might incorporate a human approval – for instance, after the agent finds a time, it could ask “Should I send an invite for Tue 2pm?” (perhaps via a different channel), then proceed. But as a fully automated assistant, the above approach saves you from doing these repetitive checks manually.

This example shows how agentic AI can automate an end-to-end task: from intent to execution. It combined natural language understanding (parsing the request for “with John next week” etc.) with programmatic action. It’s easy to imagine many similar office assistant tasks: booking travel (search flights, pick best option, hold a reservation), preparing a report (gather data, compile into doc), etc. By using frameworks like SmolAgents, we ensure the agent’s steps are auditable and reliable.

Example 3: Internal Knowledge Base Assistant (IT Helpdesk Agent)

Use Case: Large organizations have internal knowledge bases (wikis, SharePoint, documentation) for policies, how-to guides, etc. An internal IT Helpdesk Agent could answer employees’ tech support questions by retrieving relevant info from documentation and even perform simple troubleshooting tasks. For example, an employee asks: “I can’t connect to the VPN, how do I fix it?” The agent should:

• Search the internal docs for “VPN connection issues”.
• Provide the solution steps to the user.
• Possibly open a ticket or suggest escalation if the problem persists.

We’ll build an Internal Knowledge Assistant that uses LlamaIndex to index some mock documents and answer a query. This agent will primarily demonstrate retrieval augmented Q&A, possibly with a chain-of-thought if multiple docs are involved.

Framework choice: LlamaIndex is well-suited as it can handle the indexing of documents and provide a simple agent interface to query them. We will:

• Create two small text “documents”: one with VPN troubleshooting steps, another with general IT policy.
• Index them with LlamaIndex.
• Use an agent or query interface to ask a question and get an answer citing the docs.

Architecture Diagram: This agent’s architecture has an LLM agent that uses a Retrieval Tool (the index) to get info. It’s essentially a context-augmented QA: user query -> agent -> retrieves docs -> agent composes answer. We can illustrate:

• Data: internal docs (like a vector store).
• Agent (LLM) with a retriever tool.
• The agent might not need other tools, or perhaps a ticket logging tool as well. For simplicity, we’ll focus on retrieval and answer.

Diagram: [User query] -> [Agent] -> [LlamaIndex QueryEngine] -> [Relevant doc snippet] -> [Agent answer]. It’s a single-step tool usage in this case.

Step-by-Step Implementation:

from llama_index import GPTVectorStoreIndex, SimpleDirectoryReader, ServiceContext, LLMPredictor
from langchain.chat_models import ChatOpenAI

# 1. Prepare documents (simulate reading from files or sources)
doc1_text = """VPN Troubleshooting Guide:
If you cannot connect to the VPN, follow these steps:
1. Check your internet connection.
2. Restart the VPN client application.
3. Ensure your account has VPN access by contacting IT if unsure.
4. If the issue persists, create a support ticket with the IT helpdesk.
"""
doc2_text = """IT Policy - Network Access:
Company VPN is required for accessing internal resources from outside the office.
All employees must use their assigned credentials. If you forget your VPN password, you can reset it via the IT portal or contact support.
"""
# Instead of reading from files, we use in-memory text
docs = [
    ("vpn_guide.txt", doc1_text),
    ("it_policy.txt", doc2_text)
]
# In a real scenario, you might have actual text files and use SimpleDirectoryReader or similar.

# 2. Build the index
from llama_index import Document
documents = [Document(text=t, doc_id=name) for name, t in docs]
index = GPTVectorStoreIndex.from_documents(documents)

# 3. Set up LLM for answering
llm_predictor = LLMPredictor(llm=ChatOpenAI(model="gpt-3.5-turbo", temperature=0))
service_context = ServiceContext.from_defaults(llm_predictor=llm_predictor)
query_engine = index.as_query_engine(service_context=service_context, similarity_top_k=2)

# 4. Ask a question via the query engine
question = "I can't connect to the VPN. What should I do?"
response = query_engine.query(question)
answer = str(response)
print("Agent answer:", answer)

Let’s break it down:

• We created two Document objects containing our text. GPTVectorStoreIndex builds an index (embedding-based). Under the hood, it will chunk text, create embeddings (requires an OpenAI key or default embed model).
• We then turn the index into a query_engine which we can query in natural language. We set similarity_top_k=2 to retrieve possibly both docs if relevant.
• We ask the question. The LLM (GPT-3.5) will get the relevant text from the VPN guide (and maybe the policy doc if it deems it relevant) and will formulate an answer.

The expected behavior: It should find the VPN Troubleshooting Guide document which directly addresses the question. Likely it will output an answer like:“According to the VPN Troubleshooting Guide, you should:

1. Check your internet connection.
2. Restart the VPN client.
3. Make sure your account has VPN access (contact IT to verify).If the issue persists after these steps, you should open a support ticket with IT helpdesk.”

The query_engine.query already returns a response object that LlamaIndex’s default QueryEngine might format with sources. If response is a Response object, str(response) gives the answer text, and possibly it might include citations if enabled. (We didn’t explicitly enable source citation formatting, but LlamaIndex can provide source text).

We could also use LlamaIndex’s Graph or Workflow to create a tool-using agent, but here the direct query engine suffices.

Considerations: We used similarity_top_k=2 in case the policy doc had something useful (like about credentials). The agent (LLM) might combine info if relevant. For example, if the question was “I can’t connect to VPN and I forgot my password,” the agent might fetch both docs: one for troubleshooting, one for password reset info, and weave them into the answer. LlamaIndex’s Response synthesizer would handle that.

In terms of framework, this showcases a more data-centric approach: rather than a fancy multi-step plan, the agent’s power comes from having access to the right information. For an internal helpdesk, this is crucial – often answers are somewhere in the docs, and the agent’s job is to fetch and relay them, maybe performing minor actions like creating a ticket which could be another tool if we extended it.

For completeness, if we wanted the agent to also create a ticket for the user as a follow-up, we could integrate a create_ticket(issue) tool. The agent after giving the advice could decide if a ticket is needed and call that tool. In LlamaIndex, that would involve using the Tool abstraction and possibly the Workflow to allow a function call. But given the question, we stick to Q&A.

Why LlamaIndex: It simplified indexing data and retrieving it, so we didn’t have to manually manage embeddings or vector stores. It’s designed exactly for this pattern of augmenting LLMs with private data​. We could have done similar with LangChain’s RetrievalQA chain, which is also fine; but LlamaIndex might handle more complex documents or retrieval better out-of-the-box (plus it has nice features like combining multiple sources or following query plans if needed).

This example demonstrates how an agent can serve as an on-demand expert by pulling from a knowledge base. Businesses can deploy such agents internally to reduce the load on IT staff or HR (answering policy questions, etc.). It’s like a smarter search engine that gives you a concise answer rather than a bunch of documents to read.

‍

Wrap up of the Agentic AI series: Through these examples – a customer service bot, an automation assistant, and an internal knowledge agent – we’ve seen how Agentic AI can be applied to real business needs. Each required slightly different capabilities:

• The Customer Service Agent required multi-modal action (answer vs perform lookup), so we used tools and an agent that can decide between them, showing the benefit of an LLM agent orchestrating functions.
• The Automation Assistant involved executing a procedure on behalf of a user, highlighting how an agent can offload tedious tasks and even write code to handle logic.
• The Knowledge Base Assistant emphasized information retrieval, illustrating how an agent can leverage organizational knowledge to provide immediate answers.

When designing your own agentic solutions, think about the problem in these terms: What knowledge does the agent need? What actions should it be able to take? Then choose a framework that makes it easy to provide that knowledge (documents, APIs) and implement those actions (tools, code execution). By following the patterns in these examples, you can create agents that are not just chatbots, but proactive assistants that truly act on the user’s behalf, bringing substantial efficiency and value to business operations.

Until the next one,

Tega AdeyemiMarch 25, 2025