Case study

Multi-agent PR intake & routing gatekeeper

Classification, routing, and compliance for public-sector communications intake

Sanitized production case studyRole · AI backend lead — architecture and implementation

Production multi-agent system that ingests inbound communications requests, classifies and validates them against policy, and routes each to the right downstream workflow — behind a strict state machine and data-residency guarantees.

Problem

Inbound public-sector communications requests arrived unstructured and high-volume, with no consistent triage. Routing was manual, inconsistent, and hard to audit. Arabic and English requests needed identical guarantees, and compliance required all processing to stay inside an approved data-residency boundary.

My responsibility

Architected and built the AI backend end-to-end on an enterprise agent framework — the agent orbit, the domain models, the status state machine, and the test suite. Designed the system so the LLM is bounded by typed contracts and explicit states, not trusted to free-run.

Key decisions

Model the entire intake lifecycle as an explicit multi-state status machine, so every request has a known, auditable position and no agent can skip a required step.
Run a fixed orbit of specialized agents behind duck-typed Protocols, so each agent is swappable and independently testable.
Parse every LLM output into Pydantic v2 models and reconcile against a registry — reject or repair anything that fails validation rather than passing raw model text downstream.
Pin the Azure client to explicit endpoint, api_version, api_key, and model so all inference stays inside the approved data-residency boundary — no implicit defaults.

Architecture

Orbit

fixed orbit of specialized agents in the intake

Multi

states in an explicit intake status machine

E2E

comprehensive end-to-end test suite

In-region

all inference inside the approved data-residency boundary

Deterministic / validated
LLM / generative (bounded)
Orchestration / boundary
Neutral component

Intake status machineC1 · rename to your states

Every request holds a known, auditable position. No agent can skip a required state. State names here are representative.

Agent orbit & residency boundaryC2 · fixed orbit, one boundary

A fixed orbit of specialized agents behind duck-typed protocols, each swappable and independently testable. The dashed boundary is the compliance guarantee: the Azure client is pinned to explicit endpoint, version, key, and model so no inference leaves the approved region. Agent names are representative.

Typed validation flowC3 · LLM output is never trusted raw

Raw model text never reaches the routing decision. Every agent output is parsed into a Pydantic model and reconciled against a registry; anything that fails validation is repaired or rejected, not passed downstream.

Stack

Python 3.12
FastAPI
Microsoft Agent Framework
Azure OpenAI
Pydantic v2
pytest

Outcome

· A multi-agent intake orbit shipped with an explicit multi-state status machine and a comprehensive end-to-end test suite.
· Deterministic, auditable routing — every request lands in a known state with a typed decision.
· Bilingual (Arabic / English) intake behind the same contracts and guarantees.

Known limitations

· Sanitized details only — client policy logic and routing taxonomy are not public.
· The orbit is tuned to a specific intake taxonomy; new request types require schema and test updates.
· Classification quality is bounded by labeled examples; edge-case intents still benefit from human review.
· Client details and specific figures are sanitized and available under NDA during a technical interview.

Sanitized details available during technical interview.