aixplain
Part 1 — Concepts, Architecture, & Agency Delivery
1 / 25
Part 1 of 3 — Concepts, architecture, and agency delivery

Agentic AI for Agencies

From Chatbots to Managed Agents: how to explain, scope, and recommend real client solutions

By Nur Hamdan, Head of Product at aiXplain
June 1st, 2026
San Jose
Why Now

Why agents matter now

Three signals say this is moving from AI feature to core business software category.

Signal 01

The market is scaling fast

$7.06B to $93.2B

One widely cited forecast projects agentic AI growing from $7.06 billion in 2025 to $93.2 billion by 2032, a 44.6% CAGR. Other forecasts point in the same direction: rapid growth and category formation.

Signal 02

Enterprises are formalizing the role

Architecture discipline

Microsoft now offers an Agentic AI Business Solutions Architect certification. That is a strong signal that agent design is being treated as enterprise architecture work, not just experimentation.

Signal 03

The products now execute real work

Bounded execution

Products such as Codex show what this looks like in practice: agents operating with sandboxing, approvals, and telemetry so they can complete bounded work instead of only answering questions.

Bottom line: The shift is from AI that answers questions to AI that can complete bounded work.
Production Readiness

What it really takes to deploy an agent in production

Deployment is only the start. Production means evaluation, monitoring, controls, and continuous improvement.

Production need
What it means
Deployment
Stable runtime, integrations, authentication, scalability.
Evaluation
Defined success metrics, datasets, regression tests, human calibration.
Monitoring
Traces, latency, cost, tool usage, failure patterns, drift detection.
Governance
Access controls, approvals, audit trails, policy boundaries.
Evolution
Prompt updates, model changes, dataset refresh, workflow tuning.
Production is an operating loop
Agent
Deploy
Evaluate
Monitor
Govern
Improve
If you cannot measure it, monitor it, and improve it, you have not really deployed it.
Production = deployment + evals + monitoring + governance + iteration.
Prototype = "it worked once." Production = "it keeps working safely at scale."
Audience & Learning Objectives

Who this course is for — and what you’ll be able to do

Built for agencies who need enough technical depth to advise clients without teaching model science or low-level infrastructure.

Agency Strategists
Solutions Leads
Account Directors
Pre-Sales Architects
Delivery Leaders
01

Explain the difference between a chatbot, an agent, a coding agent, and a managed agent in language a client can act on.

02

Identify when RAG is the right architecture choice versus when direct system access, memory, or workflow automation is more appropriate.

03

Distinguish MCP from direct API integrations, and explain when each is the better architecture choice.

04

Frame code-execution agents as software-building systems that can produce tools, front ends, back ends, and even other agents.

05

Convert agent concepts into use-case prioritization, architecture decisions, pilot plans, governance requirements, and pricing assumptions.

Course Agenda

Today’s agenda: from concepts to client-ready thinking

Six modules that mirror the actual flow of the course, from agent foundations to production thinking and platform next steps.

Topic
Outcome
1. Agent foundations and types
Define what an agent is, separate it from a chatbot, and classify the major agent patterns clients will ask about.
2. Building blocks and execution
Understand the LLM, harness, execution loop, and orchestration choices that make an agent actually run.
3. Knowledge, memory, and RAG
Identify when the problem is knowledge access, memory, or workflow reasoning, and where RAG fits inside the solution.
4. Tools, MCP, prompts, and guardrails
Explain how agents connect to systems, follow reusable instructions, and stay controlled enough for enterprise use.
5. Production and agency delivery
Translate agent concepts into production requirements and a concrete agency example.
6. aiXplain next steps
Prepare for the next session on the aiXplain platform, managed-agent deployment, Marketplace assets, and MCP-based building.
Agent Foundations

What is an AI agent?

A system that pursues a goal across multiple steps using context, tools, and feedback.

Definition

It can

Step 01

Take a goal.

Step 02

Plan steps.

Step 03

Use tools and systems.

Step 04

Review outcomes.

Step 05

Continue or escalate.

Boundary

What is not an AI agent?

Not an agent if it only

Answers and stops.

Not an agent if it only

Retrieves but does not act.

Not an agent if it only

Follows rules but cannot adapt.

Not an agent if it only

Breaks when exceptions appear.

Bottom line

Agent = goal-driven, adaptive, tool-using execution.

Best facilitation question: “Which client use cases in your world are really answer systems, and which are outcome systems?”
Best transition line: “So if that is what an agent is not, the next question is: what are the minimum ingredients that make a system actually agentic?”
Agent Types

Managed agents vs coding agents

Coding agents build software. Managed agents run business work.

CODING AGENT
A software-building agent that reads repositories, edits files, runs tests, and produces validated code artifacts.
Build dashboards and internal tools.
Refactor pipelines and APIs.
Generate tested code changes and automation components.
Examples: an internal dashboard builder a repo refactoring agent
Best framed as a builder of software systems.
MANAGED AGENT
A deployed operational agent that wakes up on triggers, works through recurring tasks, and completes business workflows safely.
Knowledge agents using RAG over manuals and policies.
Database and records agents that read or update live systems.
Workflow agents that triage work, route approvals, and produce recurring outputs.
Examples: a policy Q&A agent a CRM update agent a ticket triage agent
This course focuses on managed agents.
Course Focus: We will focus on managed agents and how to explain, scope, and recommend them for real client operations.
Agent Building Blocks

The building blocks

The model is only one part. The rest of the system decides whether the agent is useful, safe, and affordable.

LLM

The reasoning engine that interprets goals, chooses actions, and generates outputs.

Knowledge & Memory

What the model can see right now, what it can retrieve, and what state it can store across steps.

Tools

The read and write capabilities that let the agent inspect systems and take action, including reusable MCP tool surfaces when multiple agents need the same access.

Prompts

Focused instructions that shape how the agent works, plus skills that package reusable workflows and modular context for specific tasks.

Guardrails

Approvals, sandboxing, escalation rules, validation checks, and logging.

Harness: The harness is the runtime that wires these building blocks together. It includes retries, orchestration routes, execution flow, and the logic that decides what happens next. It is not one more block beside them.
Model Selection

The LLM: the reasoning engine of your agent

Pick the model for the job, not the model with the most hype.

How to choose the best LLM for your agent
Start with the task, not the model brand.
Optimize for accuracy first.
Then reduce cost and latency.
Match context size to the workflow.
Test models on your actual agent loop.
Best model: Best fit for the workflow.
Simple decision matrix
Agent type
Model priority
FAQ / triage chatbot
Low cost, fast latency.
RAG research agent
Context handling + grounding quality.
Workflow agent
Tool reliability + stable structured output.
Coding agent
Strong reasoning + long-horizon task handling.
Managed business agent
Reliability, auditability, predictable cost.
Model Economics

Tokens, context window, and why cost varies

Context window = how much the model can see at once. Tokens = how vendors measure and price that usage.

Simple visual
Model working space / context window
Input tokens
Output tokens
Bigger prompt or longer history = more input tokens.
Longer answer or more reasoning steps = more output tokens.
If the total gets too large, you hit context-window limits or higher pricing tiers.
What to know

A token is a chunk of text the model reads or writes, and vendors usually bill by number of input and output tokens.

The context window is the total amount of text the model can “see” at one time, including instructions, conversation history, retrieved documents, and the model’s answer.

Input and output are often priced differently, and output is commonly more expensive than input.

Some vendors also change pricing when you use very long context windows.

Execution Mechanics

The agent execution loop

What actually happens when an agent runs

The real value of an agent comes from repeated cycles of reasoning and action, rather than a single direct generative answer. This loop highlights why agents require strict testing.

Why "Inspect" Matters: The inspection step physically separates an agentic execution model from a simple one-off API chain, ensuring output compliance.
01
Trigger / Goal
02
Plan Action
03
Call Tool
04
Inspect Result
05
Decide Step
06
Output / Escalate
aiLOOP
Orchestration Patterns

Single agent vs agent teams

Start with one agent. Add a supervisor or swarm only when the workflow truly needs specialization, routing, or parallel coordination.

Layout 01

Single Agent

One agent owns the full loop: it plans, calls tools, inspects results, and completes the task inside one policy boundary.

CRM
Email
Agent
Docs
Best for tightly scoped workflows with one owner and one audit trail.
Simplest option for testing, pricing, and governance.
Layout 02

Supervisor Team

A lead agent routes work to specialist agents, collects outputs, and decides what happens next.

Supervisor
Research
Analysis
QA
Best when routing, approvals, and escalation logic must stay centralized.
Good fit for managed agents with clear sub-tasks and human review gates.
Layout 03

Swarm

Multiple peer agents coordinate around a shared goal or state, often in parallel, without one permanent boss.

Scout
Planner
Builder
Checker
Router
Best for exploration, decomposition, and parallel search across many options.
Hardest pattern to govern because coordination, retries, and state are more distributed.
Real-World Case Study

An agency example

Use Case: Generate a weekly pipeline-risk brief for the Chief Revenue Officer (CRO)

The Chatbot Approach

An agency team builds a chat window linked to CRM documentation. To get a summary, the CRO must proactively log in, prompt the model, and manually review records one-by-one.

Relies on manual, proactive human actions.
The Agent Approach

An agent wakes up every Friday night, pulls CRM changes, flags anomalous deals, decides whether the signal is strong enough, pulls call notes and support history when it needs more context, re-scores the risk, drafts a review memo, and routes it to the director before sending.

Multi-step, self-correcting business process transformation.
1 Pull CRM
2 Check Deltas
3 Spot Risk
4 Need More Data?
5 Pull Notes
6 Re-score + Draft
7 Review + Send
Knowledge & Memory

Knowledge and memory: the context system of an agent

Knowledge helps the agent know more; memory helps the agent stay coherent over time.

KNOWLEDGE
External facts and source material the agent can access.

Usually retrieved when needed: through RAG, tools, or MCP resources.

Examples: documents, CRM data, policies, product data, database tables.
MEMORY
Retained context the agent uses again later.

Reused across steps or sessions: memory can be short-term within a run or long-term across sessions.

Examples: preferences, prior decisions, task state, summaries, open loops.
CONTRAST
Knowledge answers: “What should I know?”

Memory answers: “What should I remember?”

Bottom line: Knowledge is what the agent can look up. Memory is what the agent can keep track of.
Closing line: The best agents do not just retrieve the right information — they also remember what matters.
Core Architecture Pattern

RAG in plain English

Retrieval-Augmented Generation

Context Grounding: RAG retrieves precise chunks from external documents and injects them directly into the active prompt payload.
No Retraining Required: Allows language models to speak accurately about proprietary company files without expensive weight updates.
Ingests Unstructured Data: RAG works best on text-heavy content such as PDFs, policies, wiki pages, web pages, transcripts, and manuals.
What “Unstructured” Means: Information written for humans in documents and pages, not clean rows and fields in an operational database.
Refresh Limitation: The knowledge base must be triggered to read updated content again. New source data does not appear automatically unless something re-ingests it.
01 Source enterprise documents
02 Index and retrieval layer
03 Selected relevant chunks
04 Model context window
05 Grounded answer
RAG looks up the right material first, then gives only the relevant parts to the model.
RAG Operating Pattern

Two agents around one knowledge base

One agent refreshes the content layer. Another agent uses that layer to answer grounded questions.

Agent 01

Ingestion Agent

Triggered on a schedule or content-change event to scrape a website, extract text, chunk it, and ingest it into the knowledge base tool.

Trigger refresh
Scrape website
Clean and chunk
Ingest to KB tool
Knowledge Base Tool
Shared retrieval layer
Agent 02

Answering Agent

Triggered by a user question to query the knowledge base tool, retrieve the most relevant chunks, and answer from grounded context.

Receive question
Query KB tool
Retrieve chunks
Answer with grounding
Why this matters: If the ingestion agent does not run, the answering agent will use stale knowledge even if the source website changed.
RAG + Agent Design

Agentic RAG = knowledge base + agent + tools

RAG gives the agent grounded documents. The same agent can also keep workflow state and use action tools.

Knowledge Base Layer

RAG is the document grounding capability

The agent uses RAG when it needs grounded reference material from a knowledge base.

policy manuals
standard operating procedures
compliance catalogs
Agent Decides when to use RAG and when to use tools
Agentic RAG takes a knowledge base and adds it to an agent that can have other tools and continue across multiple steps.
Workflow Layer

The agent keeps working across steps

multi-step support cases
multi-week loan underwriting workflows
Action Tools

The same agent can act on live systems

updating records in Salesforce
scheduling meetings
triaging operational tickets
Clear framing: RAG is one capability inside the agent. It does grounded reading from a knowledge base, while the agent handles workflow logic and tool use.
Decision Checkpoint

What problem are you really solving?

Agencies often say “RAG” when the client means something else

CLIENT OBJECTIVE: "Expose proprietary data to AI"
Need grounded document answers?
RAG Architecture

Expose unstructured text in grounding contexts. Example: policy manuals, standard operating procedures, compliance catalogs.

Need state across a workflow?
Memory & State

Maintain historical session context across complex workflows. Example: multi-step support cases, multi-week loan underwriting.

Need to read or act on live systems?
API & MCP Tools

Establish real-time lookups and transactions on live systems. Example: updating records in Salesforce, scheduling meetings, triaging operational tickets.

Tools & MCP

Tools and MCP: how agents connect to the real world

Tools let agents act; MCP gives them a standard way to connect.

Tools are how an agent does things: query a database, call an API, send a message or update a system, and perform a computation or workflow step.
MCP is the standard connection layer: it connects AI applications to external systems, reduces one-off custom integrations, and works across tools, data sources, and reusable workflows.
One-line takeaway: Tools give the agent capabilities. MCP makes those capabilities easier to expose and reuse.
Reasoning Agent / LLM
Connection MCP client
Exposed capabilities MCP servers
CRM Database Email File system Search
Integration Strategy

MCP vs API: why MCP matters for agents

APIs connect software to software. MCP helps connect AI applications to tools and systems in a more standard, reusable way.

API

A direct integration to a specific system. Great when engineers know exactly what needs to be called, and often built one connection at a time.

Architecture pattern
Agent A Custom CRM API
Agent B Custom CRM API
Agent C Custom CRM API
Why teams choose it
direct and explicit for one known system call
good when the workflow is narrow and fixed
best when engineers know exactly which endpoints they need
MCP

A standard layer for connecting AI applications to external systems. It makes integrations more reusable across models and clients, reduces custom connector work, and helps agents access live tools and data more reliably.

Architecture pattern
Agent A / B / C MCP
CRM Database Files Internal systems
Why MCP matters for agents
makes integrations more reusable across models and clients
reduces one-off custom connector work and speeds up development
helps agents access live tools and data more reliably
Bottom line: API = custom pipe. MCP = standard adapter layer for AI.
MCP In Practice

Examples of MCPs and their tools

What agents can actually do once an MCP server exposes useful tools

Browser MCP

Web Interaction

Tools can open a page, click through a flow, extract information, fill forms, and capture screenshots.

open page click extract data

Google Drive MCP

Docs and Files

Tools can search files, read documents, create Docs or Slides, update Sheets, and leave comments.

search drive read doc create slide

Atlassian MCP

Delivery Operations

Tools can search Jira, create issues, transition tickets, comment on work items, and read or update Confluence pages.

create ticket transition issue update confluence

Files / SQL MCP

Internal Systems

Tools can query internal databases, read local files, inspect schemas, and run narrow operational actions behind one agent-facing server.

query sql read file inspect schema
Agent Landscape

Types of agents

Knowledge, database, workflow, and code-execution agents are practical patterns. Most real agents are a mix depending on the tools they can use.

Knowledge Agent

Uses external source material such as manuals, policies, and product documentation to ground answers or decisions.

a policy support agent that answers with citations from SOPs and compliance manuals
Database Agent

Works against structured records, tables, or operational systems to query status, detect changes, and sometimes write updates back.

a sales-ops agent that reads pipeline data and updates CRM fields when thresholds change
Workflow Agent

Coordinates multi-step operational work across systems, approvals, and handoffs rather than answering one question.

an onboarding agent that creates tickets, schedules meetings, routes approvals, and tracks completion
Code-Execution Agent

Reads codebases, edits files, runs commands, and tests changes to produce working software artifacts inside a controlled runtime.

an internal tool builder that creates a dashboard, API integration, or automation script from instructions
Reality: Most production agents are hybrids. A workflow agent may use RAG like a knowledge agent, read systems like a database agent, and call code tools when it needs automation.
Prompts & Skills

Prompts and skills: how agents know what to do

Prompts shape behavior in the moment; skills package repeatable ways of working.

Prompts: Tell the agent what task to do now and define instructions, context, constraints, and output format.
Best for prompts: One-off tasks, task framing, and response control.
Skills: Package reusable workflows for recurring tasks and combine instructions, resources, and optional scripts.
Best for skills: Consistency, repeatability, and specialization.
One-line takeaway: Prompt = this task. Skill = this kind of task, done the right way every time.
Prompt

"Draft a client-ready risk summary from these CRM notes."

Skill

"Weekly sales-risk analysis workflow: pull CRM data, identify changes, format summary, flag exceptions, route for review."

Distinction

The prompt is the request. The skill is the reusable operating procedure.

Guardrails

Guardrails: the control system of an agent

Guardrails define what the agent is allowed to access, decide, and do.

Wrong access: the agent sees or uses data it should not.
Wrong action: the agent takes an unsafe or irreversible step.
Wrong scale: the agent repeats a bad action too many times.
Wrong visibility: nobody can explain what the agent did after the fact.
Core controls: permission-aware access and tool allowlists, human approvals, sandboxing and network boundaries, logging and audit trails, and runtime limits with rollback paths.
One-line takeaway: Guardrails do not make agents smarter. They make agents safer, controllable, and deployable.
Agent core Agent
Access controls
Approval controls
Execution boundaries
Observability
Runtime limits
Up Next

Introduction to aiXplain and the operating system for AI agents

Next session: build and deploy managed agents, use coding agents to build aiXplain agents, and work with Marketplace assets and MCPs.

LEARN Managed agents on aiXplain

Learn how to build and deploy managed agents with the aiXplain operating system for AI agents.

BUILD Coding agents for aiXplain

Learn how to use coding agents to build aiXplain agents, tools, and supporting automation.

EXPLORE Marketplace and MCPs

Learn how to use the aiXplain Marketplace and available MCPs to connect agents to models, data, and tools.

REGISTER Get access

Studio: https://studio.aixplain.com/
Access: You will get 7 days of free access. After that it is pay-as-you-go, and we will discuss pricing in the next session.

JOIN Discord community

Discord: https://discord.gg/aixplain
Join Discord to ask questions and get answers the same day.

BEFORE NEXT TIME Come ready for the build session

Register, try the Signal Compass agent, explore the platform a bit, and come with questions for the next course session.