01

A multi-agent operations harness

Gateway, super-agent, specialised agents, MCP tools, knowledge and a person at the end. Use Walk Through It for the flow.

Multi-Agent Harness for IT Operations
ticketsrequeststoken checkmodel callsknowledge · memorypolicy checksignalsopens a tickethand-overIdentity, models, runtime and policyWork coming inGateway pipelineAgent workflowsSpecialised agentsToolsEnterprise systemsKnowledge, memory and eventsAuditPeopleKeycloakSSO · SAML / OIDCAD / LDAPcustomer directoryLiteLLMmodel routing · budgetsLLMsClaude · OpenAIKubernetescontainer orchestrationAWS Secrets ManagerOPApolicy as codeITSM deskticketsChat and portalusers, IT operatorsMonitoring signalsapps, databases, servicesKongAPI gatewayGuardrails AIinput and output checksSuper-agentroutes by intentIntake agentclassify, routeKnowledge agentanswers with sourcesData agentquery → run → checkMonitoring agentdetects anomaliesRunbook agentconfirm, guide the fixChange agentplan → deploy → testMCP gatewayContextForgeTickets and changesITSM recordsDatabasesServers and legacyappsAPI · MCP · DBKafkaevent modelQdrantvectors · BM25 + RRFNeo4jknowledge graphPostgreSQLoperational dataMongoDBconversations, contextRedisshort-term memoryObservabilitylogs · traces · alertsEngineerhand-over · approvals

Point at a component to light its links; select it for what it does here and the practice that makes it right on AWS.

Point at a component to see what it does; select it for the best practice.Open the architecture
02

One super-agent, specialised agents behind it

A typical first set for IT operations. Point at a source of work to see which agents take it.

Work coming inSpecialised agents
Super-agentroutes by intent

Point at a source to see what it feeds, or at a result to see where it comes from.

03

Before and after, job by job

What people do by hand today, and what agents take on.

Before With agents
Logging a requestThe user logs a ticket by hand.The user asks in chat; the agent logs it with context.
RoutingL1 receives it and passes it to L2.Routed and prioritised at once; common issues answered directly.
Data requestsL2 writes and runs the query by hand.The data agent writes, runs and checks the query.
MonitoringAdmins check several tools and log tickets.The monitoring agent detects anomalies and summarises them.
Failure handlingEngineers look up the procedure.The runbook agent confirms the failure and guides the fix.
Change requestsHours of planning, deploying, testing and reporting by hand.The change agent drafts the plan, deploys, tests and reports; a person approves.
04

The second path: nobody raises a ticket

Many incidents start as a signal, not a request. Here the system opens the ticket itself.

1 of 6

Watch

The monitoring agent queries application and database services and reads the logs.

05

A reference stack for an agent harness

Open-source and commercial parts we build with. The combination is chosen per customer.

Agents and models

DifyClaudeopenaiLiteLLM

Knowledge

QdrantNeo4jHybrid BM25 + RRF

Tools and events

MCP gateway (ContextForge)KafkaKongservicenow

Data

PostgreSQLMongoDBRedis

Security and policy

KeycloakOPAGuardrails AI
SourcesNGT Service Offering v3.2 (Jul 2026)AI-First DevOps Transformation: Services & Solutions, NGT (Oct 2026)Full SDLC with GenAI & Multi-Agent AI, NGT (Jun 2025)Platform Engineering v1.2, NGT (Sep 2026)FHN AI Service Introduction v0.9.3 (Mar 2026)Executive briefing: Look Forward 2027, FHN (Oct 2026)FPT Smart Cloud: AI Agents, Token Factory and AI Factory introductions (2025–2026)