<imgsrc="../images/ai/osl_ai.png"alt="OSL AI architecture">
<figcaption>Figure 1. OSL AI architecture</figcaption>
</figure>
OpenSlice introduces a dedicated AI layer that brings conversational and agentic capabilities on top of the existing NaaS and Service Orchestration functionalities. The goal is to let stakeholders, like operators, developers, and end customers interact with OpenSlice through natural language, and to let OpenSlice itself use AI agents to support orchestration decisions.
The OSL AI layer is built around four concepts:
@@ -41,7 +46,10 @@ Architecturally, the MCP Backend combines three capabilities:
In addition to its REST interface, the MCP Backend connects to the OpenSlice Service Bus, which extends its agentic capabilities to other OpenSlice components rather than restricting them to HTTP-based callers.
[](images/ai/osl_ai.png)
<figure>
<imgsrc="../images/ai/osl_ai_mcpbe.png"alt="MCP Server and MCP Backend architecture">
<figcaption>Figure 2. MCP Server and MCP Backend architecture</figcaption>
</figure>
## OSL Assistant
@@ -56,13 +64,19 @@ Authentication is end to end rather than assistant local: the user authenticates
The OSL Assistant also keeps session level memory, retaining conversational context for the duration of a session so the user does not need to restate information already given earlier in the conversation.
Agentic Orchestration is an early, beta capability. It is functional but has not yet undergone the same level of testing and hardening as the rest of the OSL AI layer, and its behavior may still change in upcoming releases.
Orchestration decisions within OpenSlice are made in one of three ways, corresponding to increasing levels of autonomy as defined by the TM Forum Levels of Autonomy model:
@@ -79,4 +93,13 @@ Agents connect to the OpenSlice Service Bus, each advertising a name and listeni
The OpenSlice Orchestrator (OSOM) can call any of these agents throughout the orchestration lifecycle, communicating with them over the Service Bus whenever a step calls for an agent-driven decision rather than a predefined or rule-based one. This allows a single workflow to combine orchestration styles: routine steps continue through predefined or no-code flows, while steps that require contextual judgement are handed off to an agent, local or remote, OSL-native or third-party, connected to the Service Bus.
