What makes a system "agentic" — the loop that drives it, the four shapes agents come in, and which shape fits which finance problem.
Strip away the technology jargon and an agent is just three capabilities running in a continuous cycle. See what's happening, think about what to do, act, then look again. The loop is what separates an agent from a chatbot — and what makes the leadership conversation about where to put a human, not whether to use AI.
Observe. Take in text, PDFs, screenshots, API responses. For finance: read the invoice, see the dashboard, fetch the bank statement.
Decide. Match observation against goal. Choose the next step. For finance: "this is a duplicate vendor — flag for review" or "GST applies, calculate at 9%".
Execute. Call an API, post a journal entry, send the confirmation, queue for human approval. The loop continues until the goal is met.
The loop is your governance hook. Each step — perceive, reason, act — is a place you can put oversight, controls, and audit trail. The L1/L2/L3 maturity model from Module 7 (Day 1) lives here:
Agent runs perception + reasoning, surfaces the proposal. Human approves every action. Audit-friendly default.
Agent acts within preset thresholds (e.g., auto-pay invoices < SGD 25K with clean POs). Anything outside escalates.
Agent owns the outcome and chooses its own steps. Reserved for low-risk, well-instrumented domains. Most finance teams stay at L1 or L2 for years.
Not every agent looks the same. Pick the shape that matches the problem — the wrong shape is the most common reason an agentic pilot fails. Click each card to see when it fits, what it costs to build, and a finance example.
Follows a predetermined sequence — like a recipe card. The path is fixed at design time: Trigger → Step 1 → Step 2 → Step 3 → Done. The agent can call tools and reference knowledge bases at each step, but only in the prescribed order. No improvisation.
| Dimension | 📋 Workflow | 🤖 Autonomous | 🧬 Hybrid | 👥 Multi-Agent |
|---|---|---|---|---|
| Path planning | Fixed sequence | Agent plans each step | Router picks workflow vs autonomous | Coordinator + specialists |
| Speed | ⚡ Fastest | 🐢 Slower (reasoning loop) | ⚡ Balanced | 🐢 Variable |
| Predictability | ✅ High | ⚠️ Lower | ✅ Medium | ⚠️ Variable |
| Cost per run | $ Cheap | $$$ Higher (more LLM calls) | $$ Mid | $$$$ Highest |
| Build effort | Low | Medium | High | Very high |
| Audit trail | Trivial | Needs structured logging | Per-branch logging | Cross-agent tracing |
| Finance use case | Period-close journals | Vendor escalation triage | Tax helpdesk + escalation | Quarter-end orchestration |
An agent without tools is just a chatbot. An agent without memory forgets every step it took. Tools let the agent do; memory lets it continue. This module is the conceptual intro — the practical setup is in M5 Skills, M6 Plugins/Connectors, and M7 Cheat Sheet.
A tool is anything the agent can call to interact with the real world. Your existing systems — ERP queries, bank rail status checks, the policy library, the chargeback ledger — become tools the moment you wrap them and tell the agent they exist.
What a vendor-escalation agent might be given access to:
| Tool | What it does | Who owns it |
|---|---|---|
| get_invoice(id) | Pull invoice header + line items from ERP | Finance Systems / IT |
| check_payment_status(invoice_id) | Status from the bank rail / payment gateway | Treasury |
| match_po(invoice_id) | Three-way match against PO + receipt | Procurement |
| search_policy(query) | RAG over your tax / treasury / accounting policy library | Knowledge owner per domain |
| post_journal(entry) | Post a journal entry with full audit trail | Controllership (high-risk — usually behind L1 review) |
| notify_vendor(vendor_id, message) | Send vendor portal / email update | Procurement / AP |
What the agent has done in this run. The reasoning chain so far. Stays alive for the duration of the task — minutes, not days. Drives "what's the next step?".
What the agent has learned over time — vendor preferences, your team's escalation patterns, common exception cases. Survives across runs. This is where the productivity compounding comes from.
Every framework used to invent its own way to wire up tools. Model Context Protocol (MCP) is the emerging standard — a universal protocol so any agent (Claude Cowork, Bedrock AgentCore, etc.) can use any compliant tool. Your IT team writes the tool once as an MCP server, and any agent your business uses can call it.
Take the eight functions in the room. Match each to the agent shape that best fits. This is the workshop's most useful slide — print it, take it back to your team, use it as the starting point for your first build.
| If your process looks like… | Pick this shape |
|---|---|
| Same steps every run, well-documented, you could SOP it | 📋 Workflow agent |
| Steps depend on what the agent finds (anomaly investigation, vendor query) | 🤖 Autonomous agent |
| Most cases are routine, but some need open-ended investigation | 🧬 Hybrid agent (router + workflow + autonomous) |
| Multi-domain process spanning several specialised teams (close, audit, group reporting) | 👥 Multi-agent system — but build the single agents first, orchestrate later |