When we started building EduPilotPro's AI layer, the obvious question was: one agent or many? The temptation to build a single 'do-everything' agent is strong — it simplifies the architecture and feels more like a product than a patchwork. But after analyzing the 12 distinct workflows school administrators need, we realized that a single agent would require so much prompt engineering that it would become unreliable for every individual task. We chose specialization: 6 agents, each optimized for a specific domain.
The 6 Agents and Their Domains
Each agent was designed around a single administrative workflow: (1) Attendance Agent — automates daily attendance tracking, parent notifications, and absence pattern detection. (2) Admissions Agent — reviews applications, scores candidates against criteria, and drafts acceptance/rejection letters. (3) Fee Collection Agent — generates invoices, tracks payment status, sends reminders, and escalates overdue accounts. (4) Timetable Agent — optimizes class schedules considering teacher availability, room constraints, and student preferences. (5) Performance Agent — analyzes student grades, identifies at-risk students, and generates progress reports. (6) Communication Agent — drafts newsletters, parent messages, and internal announcements with appropriate tone and content.
Why Specialization Wins
A general-purpose agent needs to understand 12 different domains, handle 50+ intent types, and maintain context across wildly different conversation flows. Our testing showed that a general agent achieved 72% accuracy across all tasks. The specialized agents each achieved 91-96% accuracy on their specific domain. The reason is simple: each agent's system prompt, few-shot examples, and tool definitions are tightly scoped to one problem. The LLM doesn't need to 'decide' which domain it's operating in — it's pre-configured for exactly one.
Note
Specialization also simplifies debugging. When the Attendance Agent produces a wrong output, you know exactly which prompt, tools, and data to inspect.
Google Gemini as Primary, WebLLM as Fallback
We used Google Gemini as the primary inference provider for all agents. But schools in low-connectivity regions needed offline capability. We integrated WebLLM as a secondary fallback — a smaller model running entirely in the browser. When the network is available, agents use Gemini for maximum accuracy. When offline, they gracefully degrade to WebLLM with reduced capability but continued functionality. The switchover is transparent to the user.
Agent-to-Agent Coordination
Some workflows span multiple agents. A new student admission triggers the Admissions Agent (acceptance), Fee Collection Agent (invoice generation), and Communication Agent (welcome email). We built a lightweight orchestration layer that detects cross-agent workflows and coordinates handoffs. Each agent exposes a structured output schema, and the orchestrator validates outputs before passing them to the next agent. This kept individual agents simple while enabling complex multi-step workflows.
Conclusion
The single-agent vs. multi-agent decision is not about architectural elegance — it's about accuracy and maintainability. When your domain has clearly separable workflows, specialization wins on both fronts. Each agent becomes a smaller, testable, debuggable unit. The orchestration layer is the only 'smart' component; the agents themselves are purpose-built and deterministic in their scope.
Key Takeaways
- Specialized agents achieved 91-96% accuracy vs. 72% for a general-purpose agent
- Each agent handles one domain with tailored prompts, tools, and few-shot examples
- Google Gemini + WebLLM provides online/offline capability for low-connectivity regions
- A lightweight orchestrator handles cross-agent workflows while keeping agents simple