How to Build a customer support Agent Using CrewAI in Python for banking

A banking customer support agent handles account questions, transaction disputes, fee explanations, and status updates without exposing sensitive data or making unauthorized decisions. The point is not to replace your support team; it is to reduce handle time, keep responses consistent, and enforce compliance rules before anything reaches a customer.

Architecture

• •

  User intake layer

  • •Receives the customer message from chat, email, or internal ticketing.
  • •Normalizes the request into a structured format: intent, account context, urgency, and risk flags.
• •

  Policy and compliance guardrail

  • •Blocks requests involving password resets, card activation, wire transfers, and other high-risk actions.
  • •Enforces banking rules like no PII leakage, no speculative answers, and no advice outside policy.
• •

  Support retrieval tool

  • •Pulls answers from approved sources: product FAQ, fee schedules, dispute policy, KYC guidance, and service SLAs.
  • •Keeps the agent grounded in bank-approved content.
• •

  Response drafting agent

  • •Generates a customer-ready answer in the bank’s tone.
  • •Escalates when confidence is low or when the issue requires a human banker.
• •

  Audit logging layer

  • •Stores prompts, retrieved sources, tool calls, and final responses.
  • •Needed for compliance review, incident analysis, and model governance.

Implementation

1) Install CrewAI and define your support tools

For banking use cases, keep tools narrow. Don’t give the agent broad database access; expose only approved lookups.

from crewai import Agent, Task, Crew
from crewai.tools import BaseTool
from pydantic import BaseModel
from typing import Type


class FeeLookupInput(BaseModel):
    product: str


class FeeLookupTool(BaseTool):
    name: str = "fee_lookup"
    description: str = "Look up approved banking fee information by product."
    args_schema: Type[BaseModel] = FeeLookupInput

    def _run(self, product: str) -> str:
        fees = {
            "checking": "Monthly maintenance fee: $0 with direct deposit; otherwise $12.",
            "savings": "Monthly maintenance fee: $5 unless minimum balance is maintained.",
        }
        return fees.get(product.lower(), "No fee information found for this product.")


class PolicyCheckInput(BaseModel):
    message: str


class PolicyCheckTool(BaseTool):
    name: str = "policy_check"
    description: str = "Check whether a customer request violates banking support policy."
    args_schema: Type[BaseModel] = PolicyCheckInput

    def _run(self, message: str) -> str:
        blocked_terms = ["password", "pin", "wire", "transfer funds", "card number"]
        if any(term in message.lower() for term in blocked_terms):
            return "BLOCKED: Requires human review."
        return "ALLOWED"

2) Create the agent with strict instructions

Use one agent for customer-facing support. Make it conservative by default and force escalation on uncertainty.

support_agent = Agent(
    role="Banking Customer Support Agent",
    goal="Answer routine banking support questions using approved sources and escalate risky requests.",
    backstory=(
        "You are a bank support specialist. You never request full card numbers, passwords,"
        " PINs, or OTP codes. You only answer from approved policy and fee data."
    ),
    tools=[FeeLookupTool(), PolicyCheckTool()],
    verbose=True,
)

3) Define tasks that separate policy checks from response drafting

This pattern keeps compliance explicit. First check whether the request is allowed; then draft a response only if it passes.

policy_task = Task(
    description=(
        "Review the customer message for restricted banking actions or sensitive data requests. "
        "Return only 'ALLOWED' or 'BLOCKED: Requires human review.'"
    ),
    expected_output="A short policy decision string.",
    agent=support_agent,
)

response_task = Task(
    description=(
        "If policy_check returns ALLOWED, answer the customer's question using fee_lookup "
        "and keep the response concise, accurate, and compliant. If blocked, ask them to contact "
        "a human banker."
    ),
    expected_output="A customer-ready banking support response.",
    agent=support_agent,
)

4) Run the crew with an explicit banking prompt

In production you would pass structured input from your ticketing layer. For now this shows the actual CrewAI execution pattern.

crew = Crew(
    agents=[support_agent],
    tasks=[policy_task, response_task],
    verbose=True,
)

customer_message = (
    "Hi, what is the monthly fee for my checking account? "
    "Also can you reset my password?"
)

result = crew.kickoff(inputs={"customer_message": customer_message})
print(result)

The important part here is not just that it works. It’s that you have an auditable path from request to policy decision to final answer. In banking that matters more than model cleverness.

Production Considerations

• •

  Deploy inside your controlled environment

  • •Keep inference in-region if you have data residency requirements.
  • •Do not send raw PII to external endpoints unless your legal/compliance team has signed off.
• •

  Log everything needed for audit

  • •Store user input hashes or redacted text, tool outputs, task results, timestamps, and model version.
  • •Make sure audit logs are immutable and searchable by case ID.
• •

  Add hard guardrails before generation

  • •Block requests involving authentication credentials, payment initiation, or account takeover.
  • •Route those cases directly to a human queue instead of trying to “explain” them away.
• •

  Monitor quality by intent class

  • •Track containment rate for fee questions vs dispute questions vs fraud-related queries.
  • •Review false positives where benign requests were escalated and false negatives where risky requests passed through.

Common Pitfalls

• •

  Giving the agent too much access

  • •Don’t connect it directly to core banking systems or unrestricted databases.
  • •Use read-only tools with narrow scopes and explicit allowlists.
• •

  Skipping policy classification

  • •If you let generation happen before compliance checks, you will eventually leak sensitive guidance.
  • •Always classify first; respond second.
• •

  Ignoring source grounding

  • •Banking answers change often: fees, limits, SLAs, dispute windows.
  • •Tie responses to approved documents or lookup tables instead of free-form memory.
• •

  Not designing for escalation

  • •Some issues should never be automated: fraud claims with urgency signals, legal complaints, chargeback disputes beyond standard flow.
  • •Build a clean handoff path with full context so humans don’t start from scratch.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.