How Agentic IT is built
— and why it is built that way.
A multi-tenant SaaS platform where IT operators chat with AI agents that understand their Azure, Microsoft 365, and vBox infrastructure, suggest improvements, and execute operations through natural language. This reference walks the system from a thirty-second overview down to the specific files and lines where decisions live.
Read order
The site is structured so you can read top-down. Each section starts with a high-level page and drills into the parts that matter. Cross-links point sideways when a concept first appears in one section but is owned by another.
What & why
The problem domain, the target user, and the capabilities the platform exposes today.
→ 02 — SystemHigh-level map
The three runtime tiers — frontend, API, MCP service — plus shared infra and observability.
→ 03 — BackendLayered projects
Five C# projects with a strict dependency hierarchy. The agent loop, tools, skills, data, auth.
→ 04 — FrontendReact 19 SPA
Hash router, typed API client, WebSocket subprotocol auth, component vocabulary.
→ 05 — MCPTool gateway
The separate service that hosts and proxies all MCP servers behind one HTTP host.
→ 06 — DataSchema & tenancy
Around 38 entities, soft schema bootstrap, no migrations, explicit tenant filters everywhere.
→ 07 — FeaturesHow features map to code
Per-feature deep dives: chats, artifacts, credits, schedules, approvals, sync, skills.
→ 08 — InfraCompose & Helm
Local Docker stack, parallel-worker layout, Kubernetes/Helm charts, GitHub Actions pipeline.
→ 09 — DebtRough edges
Known debt, intentional shortcuts, ghosts left from renames, and what we'd change next.
→ 10 — ReferenceLook it up
Env vars, settings, feature flags, every WebSocket message, every tool, glossary.
→ 11 — DecisionsWhy this way?
ADRs and invariants — the rationale behind every load-bearing architectural choice.
→The thirty-second picture
A user opens a chat. The browser opens a WebSocket carrying the JWT in the Sec-WebSocket-Protocol header. The API receives the user message and hands it to a SmartOrchestrator that asks a planner LLM to choose between a single generalist run and a fan-out of specialist agents. Whichever path runs, tokens stream back over the same socket; the agent calls tools — built-in Azure helpers, MCP-mediated cloud tools, file artifacts — and any destructive write is gated by a user-approval card. When the turn ends, memory and traces are persisted asynchronously.
The five core ideas
If you only have a coffee break, take these:
- Smart routing
- A planner LLM decides every turn between a single generalist agent and N specialist agents that fan out in parallel and then get synthesized. → §03·Agent system
- Approval gates
- Every destructive tool call is routed through an in-memory
ApprovalGate. The user clicks approve/reject in the chat before anything mutates a cloud resource. → §07·Approvals - MCP everywhere
- External integrations (vBox, Jira, Outlook, Teams, SharePoint, Azure CLI, Web search, Documents, Schedule, Price calculator) are uniform Model-Context-Protocol tools served by one MCP gateway service. → §05·MCP service
- Snake-case JSON
- The whole HTTP surface uses
snake_case; repositories returnDictionary<string, object?>rather than typed DTOs, so JSON shapes can evolve without migrations. → §03·Data layer - No DB migrations
- Schema is created via
EnsureCreatedAsync()at startup; new columns are added by inlineALTER TABLE … ADD COLUMN IF NOT EXISTSstatements inProgram.cs. → §06·Schema & tenancy
How to navigate this site
- The sidebar on the left holds every page in numbered order. Section headers expand and collapse.
- Each page ends with a prev / next pager that walks the natural reading order.
- Inline links of the form §03·Agent system jump straight to the page that owns a concept.
If you are new, start at §01 — Product and read forward. If you are diving for one specific thing, the feature catalog indexes capability → code path.