Course module
Agentic Systems
An agent is not a chatbot with tools.
An agent is not a chatbot with tools.
An agentic system is a workflow where the system can decide the next step, call tools, observe results, and continue until a goal is reached or a boundary is hit.
The hard part is not making the agent act.
The hard part is making the action safe, observable, reversible, and useful.
Scenario: support workflow assistant
Imagine an assistant for a SaaS support team.
A user says:
A customer says they were charged twice. Check the account and prepare a refund if needed.
This is not a normal Q&A problem.
The assistant may need to:
- inspect customer account details
- check invoices
- compare payment events
- draft a support reply
- prepare refund action
- ask for approval before executing
- log every step
Now the system is not only answering. It is acting.
Bad agent design
A weak design says:
This is dangerous because the system has no clear boundary.
Common mistakes:
- giving the agent too many tools
- no risk classification
- no human approval for money movement
- no trace of why a tool was called
- no retry or rollback plan
- no timeout or stopping condition
- memory mixed with audit logs
Rule
The more power an agent has, the more boring and explicit the control layer should be.
Better agent design
A better design separates reasoning from permission.
Action risk levels
| Action | Risk | Control |
|---|---|---|
| Search docs | Low | Log only |
| Read account status | Medium | Permission check |
| Draft refund reply | Medium | Review suggested |
| Execute refund | High | Human approval required |
| Delete account | Critical | Usually block |
This table is more important than the model choice.
Memory design
Do not put all memory in one bucket.
Use different memory types:
| Memory type | Example | Purpose |
|---|---|---|
| Short-term context | Current ticket details | Solve current task |
| User preference | Customer prefers email | Personalize response |
| Tool state | Refund check completed | Avoid repeating steps |
| Audit history | Tool calls and approvals | Debug and compliance |
| Long-term learning | Common failure categories | Improve future workflow |
A common beginner mistake is to mix audit history and preference memory. That creates confusing and unsafe behavior.
What to log
For every agent step, log:
- original goal
- planned next step
- selected tool
- input to tool
- output from tool
- risk level
- approval status
- model used
- cost and latency
- final result
If you cannot inspect a step, you cannot trust it.
Evaluation signals
| Signal | Question | Failure example |
|---|---|---|
| Task success | Did the agent complete the goal? | It found invoices but did not prepare reply |
| Tool correctness | Did it call the right tool? | It searched docs instead of checking billing |
| Boundary safety | Did it ask approval for high-risk action? | Refund executed without review |
| Drift control | Did it stay on task? | It started explaining billing policy instead |
| Trace quality | Can a human inspect the path? | Missing tool inputs or outputs |
Practice exercise
Design an agent for one workflow:
- pharmacy order support
- college admission inquiry
- refund processing
- internal IT helpdesk
Write:
- Goal
- Allowed tools
- Blocked actions
- Actions requiring approval
- Memory types
- Logs and traces
- Evaluation signals
Summary
Agents are useful when a workflow needs reasoning plus action.
But autonomy without boundaries is not engineering.
A good agentic system defines what the system can do, what it cannot do, what needs approval, what gets logged, and how failures are evaluated.