Work

case study · 2026

A multi-agent platform for Dubai Government services

ZafarLabs · Lead AI Platform Engineer

  • agents
  • mcp
  • on-prem
The constraint
Citizens ask anything, in any order, across several government domains. One wrong routing is a failed service, not a bad demo.
Who I talked to
client team

Context

Dubai Government offers dozens of services that citizens experience as one government. Traffic and vehicle matters, insurance checks, fines, community and family services: each is its own domain with its own systems, but the person asking does not think in domains. The client team wanted a single conversational entry point that could handle diverse, unpredictable questions and still answer with the accuracy each domain requires.

The constraint

The hard part is not answering a question. It is deciding which system should answer it, carrying the context from the last three turns into that decision, and doing it without the citizen ever seeing the seams. A general-purpose model with one giant prompt cannot hold the rules of four domains at once, and the platform has to run on infrastructure the government controls.

How it works

Every message enters through the intent router, which asks the agent registry which domain agents exist and what they can do. The router dispatches the turn to one agent inside a typed agent-to-agent envelope: the message, the resolved intent, and the slice of conversation memory that agent is allowed to see. Each domain agent is the same generic agent code with a dynamic system prompt and its own set of MCP tools that talk to the real government systems. Context memory sits beside the router so a follow-up like “and how much is that fine?” lands on the right agent with the right history.

What I did

I worked inside the client’s team, with their technical architect. We defined the architecture together: the envelope protocol, the registry and the intent router came out of that work rather than from any one of us. What I owned was the MCP integration for the community services domain, wrapping systems of record as tools an agent can call safely, and the generic agent that all the domain agents are built from: dynamic system prompts, context memorisation, and a strict contract for what an agent may say when its tools return nothing.

I talked to the client team directly, mostly the people who run the services, not the people who buy software. The plan changed twice because of those conversations: we added the registry after learning how often domains would be added, and we made the memory slice explicit after watching a test conversation leak an insurance detail into a traffic answer.

Outcome

Citizen queries that used to be redirected between services are answered in one conversation. Response time dropped and consistency improved, because each answer comes from the one agent that owns the facts. Adding a domain is now a registry entry and a tool set, not a platform change. Exact figures belong to the client; the shape of the result is what I can share.

Stack

PythonMCPagent-to-agent envelopesvLLMQdrantLangfuseKubernetesPostgreSQLRedis

Related