In the previous article, we established the difference between a chatbot and an AI agent. Assume korang dah faham agent — dia ada reasoning, ada tool access, ada memory. The next question practitioners typically ask: if one agent is good, why would you need more than one?
The answer has everything to do with how humans organise complex work.
Korang tak expect seorang accountant yang sama untuk juga handle legal compliance, write marketing copy, dan manage IT infrastructure serentak. Bukan sebab dia tak capable — sebab depth of expertise required in each domain is too high for any generalist to do well across all of them simultaneously. So korang hire specialists, and ada manager yang coordinate between them.
AI agent systems work the same way.
Kenapa satu agent ada ceiling?
The LLM powering an AI agent has a context window — a hard limit on how much information it can hold and reason about at once. Think of it as a desk. The context window is the desk size.
When you give a single agent too many different tasks, the desk fills up. Long system prompts, many tool definitions, accumulating conversation history, documents loaded for reference — everything competes for the same space. When the desk is full, performance degrades. The agent starts confusing instructions, missing early-conversation context, or making inconsistent decisions.
There is a second problem: domain expertise versus generalist coverage. Kalau agent korang kena jadi expert dalam compliance, expert dalam bid writing, expert dalam market analysis, dan expert dalam project scheduling — the system prompt becomes long and diluted. Dia jadi mediocre in every domain rather than excellent in one.
Analogi yang mudah: Bayangkan korang ada seorang PA yang korang brief dengan semua procedure seluruh syarikat — legal, finance, ops, sales. Dia boleh buat semua benda, tapi surface-level je. Versus korang ada PA yang know exactly siapa nak call untuk apa, dan specialists yang dia call tu genuinely expert dalam domain dorang. Result yang kedua jauh lebih baik.
Apa itu multi-agent orchestration?
Multi-agent orchestration is how we structure multiple AI agents to work together on a larger objective. Each agent has a defined role, tool access specific to its domain, and a mechanism to communicate with other agents.
The most common pattern — and the most proven in production — is the supervisor-specialist pattern.
Cara dia kerja:
- A user or system trigger sends a request to the Supervisor Agent
- The Supervisor assesses the request, understands intent, and decides which specialist is best suited to handle it
- The Supervisor delegates the task to the relevant specialist
- The specialist executes within its domain — with full context and relevant tool access
- Output from the specialist is returned to the Supervisor
- The Supervisor aggregates, validates, and presents the final output — or triggers another specialist if needed
This structure delivers several important advantages: the Supervisor can run specialists in parallel when tasks aren't dependent on each other. Specialists can be optimised and fine-tuned for their domain without affecting others. And if a specialist fails or returns unexpected output, the Supervisor can handle the exception without crashing the whole system.
Contoh sebenar: macam mana IRIS buat ia
IRIS — sistem AI kami untuk B2G procurement — is a production multi-agent system we can speak to specifically. Kami bina dia to manage the entire commercial workflow around a government tender, dari discovery sampai submission tracking.
IRIS architecture uses one persistent Supervisor thread per tender being pursued, orchestrating five Specialist agents:
When a new tender comes in, the Supervisor creates a pursuit thread for it. It assesses the tender — scope, deadline, requirements, complexity — then orchestrates specialists in parallel or sequential order depending on dependencies: Faridah starts scanning compliance requirements, Razif pulls intelligence on the listed contact officer, Izzat runs market positioning analysis. Aisyah tak start bid writing sampai output dari Faridah dan Razif dah ready.
This is what a single agent handling everything cannot do — coordinated parallel execution with proper dependency management.
Kenapa Specialists stateless? Dalam IRIS, specialists tak simpan state sendiri antara tasks — semua persistent memory ada dalam Supervisor thread. Ini design decision yang intentional. Stateless specialists mudah di-scale, mudah di-replace, dan tak ada risk of state corruption kalau satu specialist crash. Supervisor yang jadi single source of truth.
Comparison: single-agent versus multi-agent
| Dimension | Single Agent | Multi-Agent (Supervisor-Specialist) |
|---|---|---|
| Setup complexity | Rendah — satu system prompt, satu tool set | Tinggi — perlu design routing logic, specialist boundaries |
| Performance pada simple tasks | ✓ Laju, direct | Overhead dari orchestration layer |
| Performance pada complex, multi-domain tasks | Degraded — context window pressure, diluted expertise | ✓ Jauh lebih baik — setiap specialist focused |
| Parallel execution | ✗ Sequential only | ✓ Specialists boleh run serentak |
| Maintainability | Satu benda besar yang susah nak update | ✓ Update satu specialist tanpa affect yang lain |
| Error isolation | Error dalam satu task boleh corrupt keseluruhan flow | ✓ Specialist failure terkandung, Supervisor boleh recover |
| Right for you if... | Use case focused, satu domain, volume rendah-sederhana | Multi-domain workflow, high stakes, perlu parallel processing |
Patterns lain yang wujud
Supervisor-specialist bukan satu-satunya cara nak structure multi-agent systems. Bergantung pada use case, ada beberapa patterns lain yang relevant:
Sequential Pipeline
Agent A process input, pass output ke Agent B, yang pass ke Agent C. Straightforward untuk linear workflows — contohnya: extract data dari document → validate → format untuk downstream system. Tak perlu supervisor bila flow linear dan tak ada branching logic.
Peer-to-Peer / Collaborative
Agents boleh request help dari sesama dia tanpa perlu route through central supervisor. Lebih flexible, tapi harder to debug dan audit. Kurang common dalam production systems sebab traceability jadi masalah.
Hierarchical Multi-Level
Supervisor yang manage supervisors — untuk enterprise-scale systems dengan banyak domain. Kami tak recommend ini untuk SME; complexity overhead belum berbaloi melainkan korang genuinely ada workflow yang require ia.
Framework kami guna: IRIS dibina atas LangGraph — library Python yang design specifically untuk stateful, multi-actor agent applications. LangGraph handle graph execution, state management, dan streaming out-of-the-box. Kami pilih ia sebab ia gives precise control atas flow — lain dengan higher-level frameworks yang abstract too much dan jadi blocker bila nak customise.
Macam mana agents "cakap" sesama dorang?
Ini soalan teknikal yang penting untuk decision-maker faham, walaupun tak perlu tahu cara code ia.
Dalam LangGraph-based systems seperti IRIS, communication antara supervisor dan specialists berlaku melalui shared state object — basically satu structured data store yang semua agents dalam graph boleh baca dan tulis, ikut permission yang ditetapkan. Supervisor pass task ke specialist dengan update state, specialist execute dan write result balik ke state, supervisor read result dan decide next step.
Ini berbeza dari agents yang communicate melalui natural language messages sesama dorang — approach tu lebih flexible tapi jauh lebih susah nak debug dan validate. Structured state approach bagi korang audit trail yang jelas: every decision, every tool call, every output — logged dan traceable.
Untuk business yang operate dalam regulated environment — procurement, healthcare, finance — traceability ni bukan nice-to-have. Ia requirement.
Bila multi-agent masuk akal untuk business korang?
Honest answer: bukan semua business perlu multi-agent system. Kalau korang start dengan AI automation, single-agent adalah tempat yang betul untuk mula. Jangan over-engineer.
Tapi ada beberapa indicators yang signal korang mungkin dah outgrow single-agent approach:
- Workflow korang melibatkan lebih dari dua atau tiga distinct domains yang each perlukan different context dan expertise — contohnya: legal review + financial modelling + client communication dalam satu workflow
- Single agent korang consistent buat errors dalam certain domain tapi perform well dalam domain lain — ini classic sign bahawa context window pressure atau diluted expertise mula affect accuracy
- Korang nak parallel processing — beberapa steps boleh jalan serentak, dan bottleneck sekarang adalah sequential execution
- Scale of operation tinggi — bila volume tinggi, ability nak scale specialists independently (tanpa restart keseluruhan system) jadi critical
Kalau none of these apply, start dengan single agent yang well-designed. Ia lebih mudah nak build, easier nak debug, dan cukup untuk majority of SME use cases yang kami tengok.
Apa yang perlu ada sebelum korang consider multi-agent
Ini bukan checklist untuk scare korang. Ia honest assessment of what needs to be in place:
- Clean data infrastructure — specialists adalah hanya sebaik data yang dorang boleh access. Kalau inventory data korang inconsistent atau customer records half-complete, multi-agent system akan amplify masalah tu, bukan solve ia.
- Defined workflow boundaries — korang perlu boleh articulate exactly mana satu domain starts dan ends. Kalau korang tak boleh draw clear boundary between "compliance review" dan "bid writing" dalam proses korang sekarang, AI tak akan boleh figure it out for you.
- Human oversight mechanism — untuk production systems yang ada consequence sebenar (financial, legal, reputational), ada human checkpoint dalam loop. Agents yang fully autonomous tanpa oversight masih terlalu risky untuk high-stakes decisions. Ini yang artikel 1.4 akan cover dalam detail.
- Technical partner yang faham agentic architecture — ini bukan judgment call pada korang; ia just honest statement about complexity. Multi-agent systems require design dan debugging skill yang berbeza dari standard software development.
Takeaway
Multi-agent orchestration bukan magic bullet, dan ia bukan sesuatu yang setiap SME perlu start dengan. Tapi untuk business yang workflow dia genuinely complex, multi-domain, dan high-stakes — ia adalah architecture yang betul.
Pattern yang paling robust sekarang adalah supervisor-specialist: satu coordinator yang faham big picture, specialists yang genuinely expert dalam domain dorang, dan state management yang bagi korang full traceability. Ia macam mana kami bina IRIS, dan ia scale.
Next dalam series ni, kami akan cover RAG pipelines — macam mana korang connect agent kepada knowledge base korang supaya dia boleh reason tentang document, policy, dan data yang specific to business korang, tanpa hallucinate.