Short versions of the one-page notes we send on request. Each one comes from a build we did, with the decisions and the numbers that mattered. Nothing here names a client who has not agreed to be named.
- Three things that got an agentic NOC from pilot to production
- Three things that decide whether a multi-team Kubernetes platform sticks
- Keeping agents auditable: guardrails for an agent runtime
- From observability to agentic assurance: three decisions
- Integrating agents with BMC Helix over A2A
- Landing zones for public-sector and healthcare teams
- An air-gapped GenAI platform: sizing and the residency question
Three things that got an agentic NOC from pilot to production
At a Tier-1 Nordic operator, a multi-agent pipeline now turns fault situations on the 4G/5G Packet Core into ranked root causes and a recommended action. The MVP took six months for six use cases, and the operator funded production on the measured results. Three decisions made the difference.
Flows the NOC can audit. A deterministic four-step flow (retrieve, annotate, recommend, format) instead of an open agent loop. Every output is reproducible, so engineers could check the agent's work. They accepted 84% of its notes as written.
Inference inside the tenancy. Public models were ruled out on network-data confidentiality. An open-weight model runs behind a gateway on the operator's own Kubernetes, with the embeddings on persistent storage, tracing end to end and the operator's identity provider at the gateway.
A KPI baseline agreed with operations first. Alarm-noise suppression and time to root cause were measured against 250 historical situations before anyone argued about the design. The numbers that came out, 87% suppression and a median of 42 seconds, are the numbers that funded production.
Three things that decide whether a multi-team Kubernetes platform sticks
We have standardised managed Kubernetes for an operator across AWS, Azure and GCP, and assessed and enabled a Dutch municipality's AKS landing zone this year. The pattern of what sticks is the same in both.
Ingress, egress and access tiers before the first workload. Decided once, centrally, so distributed teams start with resilience and security in place rather than retrofitting them under delivery pressure.
Guardrails as self-service modules, not gates. A control that needs a request gets bypassed. A Terraform or Bicep module a team can consume on its own gets adopted, and compliance runs in the pipeline instead of in a review queue.
A plan for the people who inherit the platform. A platform the in-house team cannot operate is not finished. For the municipality that meant nine enablement sessions, not a hand-over document. The full note includes the module layout we used.
Keeping agents auditable: guardrails for an agent runtime
These are the guardrails we run in our own real-time voice agent runtime, and the ones we design into agents for clients. None of them depends on the model behaving.
A deterministic execution model. Intent, then tool chain, then confirmation, then action. Flow drift from the model is replaced by a stateful runtime that decides what runs.
One tool abstraction. The model can only invoke the tools it has been given through a single, governed interface. It cannot reach a system it was not handed.
Tracing end to end. OpenTelemetry on every step, with latency objectives on time to first byte and between chunks, and drift detection in production.
Compliance as architecture. GDPR session boundaries and data minimisation, and EU AI Act Article 50 disclosure built into the conversation flow rather than added to a policy document.
From observability to agentic assurance: three decisions
Observability data is the raw material for agentic assurance, but three decisions decide whether an agent earns a place in the NOC.
Which situations the agent may enrich. We started with one network function type, three use cases each on two element types, and widened the scope only after the acceptance rate held. The agent never acts on the network. It recommends.
How a ranked root cause reaches the ticketing platform. An agent-to-agent integration with the ITSM platform's own agent: submit and poll, an agent card, an audit record and replay behaviour, so every recommendation in a ticket can be traced back to its inputs.
Who signs off the KPI baseline. Operations, in week one, on historical situations. If the people who will measure the agent did not agree the measure, the pilot will not become production.
Integrating agents with BMC Helix over A2A
At the Tier-1 operator, BMC Helix is the operations backbone. Fault situations arrive from it, and the agents hand ranked root causes back to it. We designed that integration against HelixGPT's Best Action Plan using the A2A protocol.
What the design covers. A submit-and-poll interaction, the server and client topology, the agent card that describes what each agent offers, an audit record for every exchange, and the replay behaviour when something fails mid-flight.
The transition. The agents started on a REST integration and moved to A2A in step with the platform release that supported it, so the operator never ran an unsupported path.
What we would do again. Keep the agent tools on MCP and the agent-to-agent traffic on A2A through a gateway with the operator's identity provider. The two protocols do different jobs, and mixing them costs you the audit trail.
Landing zones for public-sector and healthcare teams
Through an MSP partner we assessed a Dutch municipality's AKS landing zone and built a secured Azure Virtual Desktop platform for a national healthcare screening organisation. Four things carried over between them.
Assess with evidence from the estate. Resource Graph and Traffic Analytics, not interviews alone, so every finding points at a resource someone can fix.
Identity before desktops. The screening organisation's Entra ID and Kerberos gaps were closed into a secured landing zone before the desktop platform went in. A desktop platform is only as safe as the identity it trusts.
A monitoring baseline on day one. Azure Monitor alerting shipped with the platform, so nobody discovered the missing alerts in an incident.
Enablement as a programme. Nine sessions for the municipality's engineers, because the platform is not finished until the in-house team can run it.
An air-gapped GenAI platform: sizing and the residency question
For a Nokia account team in Japan we advised on an on-premises, air-gapped GenAI platform for network-function documentation. Nothing could leave the customer's site, and the hardware had to be defended before it was ordered.
Two planes. A CPU plane for everything that is not inference and a GPU plane reserved for it, because CPU capacity is cheaper to add and the GPU plane should never be shared with retrieval or orchestration.
Two sized options. A roughly 400B-parameter open-weight mixture-of-experts model on 8×H100, and a 35B-parameter alternative, both costed, so the customer could weigh answer quality against hardware.
Embeddings evaluated, not assumed. Retrieval quality over the documentation decides whether engineers use the platform at all.
Residency and sovereignty kept separate. An air-gapped platform satisfies both, but each customer requirement was traced to one or the other, so the design could be defended line by line.