What makes a system "agentic" — the loop that drives it, the four shapes agents come in, and which shape fits which GS Support 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 chat transcripts, D365 case fields, screenshots a Pax sent, datalake responses. For GS: read the case description, see the SOP, fetch the booking history.
Decide. Match observation against the goal and the SOPs. Choose the next step. For GS: "this is a P1 Safety case — escalate to Country Safety" or "refund is below the SGD 50 threshold — auto-process".
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-process refunds < SGD 50 with no DSAT history). Anything outside escalates to TL.
Agent owns the outcome and chooses its own steps. Reserved for low-risk, well-instrumented domains. Most GS Support 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 GS 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 |
| GS use case | Case Context Summarizer | L1 Email Triage (true Safety vs downgrade) | SOP Lookup with TL escalation | Cross-team Safety incident 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 Case Context Summarizer agent might be given access to:
| Tool | What it does | Who owns it |
|---|---|---|
| get_case(case_id) | Pull D365 case header + chat transcript + booking | GTS / GSTF |
| get_pax_history(pax_id) | Past complaints, VIP status, prior cases from the datalake | GTS / Eternals |
| get_dax_history(dax_id) | Past Safety flags, suspension history, ratings trend | GTS / Eternals |
| search_sop(query) | RAG over your SOP / KB corpus — your SOP Lookup Day 2 build | KB / Help Centre team |
| post_to_d365(case_id, fields) | Write summary + severity + PAC tags back to D365 with audit trail | GS Operations (high-risk — TL review on Safety cases) |
| notify_pax(case_id, message) | Send Pax response via the live-chat thread or email | GS Operations / GSTF (Smart Assistant successor) |
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 |