Kenmei

The platform reads from a wide range of operator systems. It offers "streaming and batch ingestion from OSS, traces, UE, and external systems", with multi vendor, multi RAT OSS support and integration of alarms, configs and traces. That covers several distinct classes of operator system, across vendors and radio access technologies.

Every connection Kenmei describes is a read, with no authenticated action in those systems. The architecture runs through ingestion, decoders, builders and a data model, and stops where a write would begin. There is no execution or action framework and no named system the agents change, and Kenmei does not say how a change would be applied.

Kenmei says its "agents decide and act", that they "turn insights into action across the network lifecycle" and that they offer "real-time diagnosis and mitigation". None of these lines names a target system, authenticated write or protocol. Kenmei's own summaries say the agents "analyze, correlate, and suggest next steps" and "detect anomalies, find root causes, and recommend next actions automatically while your team stays in charge." Kenmei describes no write back into an operator's systems.

Sourcekenmei.ai/solutions/telco-fabric architecture and what-it-is sections, kenmei.ai/solutions/kanp solution and how-it-works sections, kenmei.ai homeread 2026-09-14

Multi agent coordination runs through the Orchestrator Agent. "Each AI agent is designed with a specific goal: from detecting quality degradations to planning expansions or troubleshooting issues in real time. Together, they cover the full network lifecycle and work in coordination through the Orchestrator Agent."

The agents also interact with each other, "enabling orchestration and automation at network-wide level." Each has its own role, so that "one might analyze performance deviations, another may troubleshoot root causes, while others optimize planning, capacity, or user experience." Together they "form a coordinated system that turns fragmented network data into timely, contextual actions."

The work runs in stages. Data is unified first, intelligence is applied second and action is taken third, with agents running end to end journeys across the network lifecycle. Kenmei names no orchestration runtime, workflow graph, versioning or customer authoring surface. The customer configures boundaries and goals, not a sequence, and the agents are named by function, not listed one by one.

Sourcekenmei.ai/solutions/kanp meet-the-agents, how-it-works and scalability sectionsread 2026-09-14

A maintained data layer built from the operator's own network grounds the agents. New knowledge enters by ingestion, not retraining. The Telco Fabric has four named layers. Data ingestion offers "streaming and batch ingestion from OSS, traces, UE, and external systems". Data decoders convert raw telco formats into standardized, open formats such as Parquet. Data builders enrich data with temporal and geographical context, then aggregate and correlate it. A data model "defines consistent structures for all use cases and AI agents".

The layer persists and can be queried. Kenmei promises "one-time data processing for infinite use cases", where the "same data feeds multiple agents and use cases", and calls it "a single, query-ready layer". The content is the customer's own, made up of multi vendor, multi RAT OSS data, traces, UE data, alarms and configs from that operator's network. Kenmei does not say how retrieval works, whether by index, embedding or graph.

Sourcekenmei.ai/solutions/telco-fabric architecture and what-it-is sections, kenmei.ai homeread 2026-09-14

Agents act on their own within limits, and people can step in. In Kenmei's words, "instead of waiting for decisions, they move first", within "boundaries you control". The operator sets those boundaries. "Kenmei's AI agents operate under operator-defined rules, not black-box autonomy. Access, actions, and decision boundaries are governed by clear policies and role-based permissions." Network teams "retain continuous visibility and control, with the ability to monitor, pause, or override agent behavior across RAN, Core, and Transport."

Boundaries limit what an agent is allowed to do, and an override stops or reverses what it did. Pause and override come after the decision, not before it. No person reviews and approves an action before it commits. Kenmei's positioning points toward minimal human intervention, with automated decisions reducing the need for engineers to react manually.

Sourcekenmei.ai/solutions/kanp solution, benefits and governance-and-security sections, kenmei.ai homeread 2026-09-14

An information security policy for Kenmei Technologies S.L. sets out an objective, a scope, responsibilities and a list of ISMS commitments. It names no certificate, ISO 27001 number, certifying body, SOC 2 report, audit period or report available on request. The policy calls the ISMS "a constantly evolving cycle, conducting regular assessments to achieve progressively more advanced levels of information security maturity", which is a commitment to keep improving, not a completed audit.

The controls are specific. On the Telco Fabric, "all data ingested and processed is encrypted at rest and in transit", and "personally identifiable information (PII) is anonymized or obfuscated". Access is limited too, since "fine-grained access controls (RBAC, IAM, VPN, etc.) ensure only authorized teams can access specific data layers".

On the agent platform, "access, actions, and decision boundaries are governed by clear policies and role-based permissions." The ENISA badge in the site footer sits beside an EU funding logo. It is a public innovation funding mark, not a security certification.

Sourcekenmei.ai/legal/security in full, kenmei.ai/solutions/telco-fabric security and compliance section, kenmei.ai/solutions/kanp governance and security sectionread 2026-09-14

Kenmei claims full traceability of every agent action. For the agents, "access, actions, and decision boundaries are governed by clear policies and role-based permissions, with full traceability of every action", and "network teams retain continuous visibility and control, with the ability to monitor, pause, or override agent behavior across RAN, Core, and Transport." That monitoring is the customer's own teams watching the agents. The continuous network observability Kenmei sells is the product itself, a reading on the customer's network and not on the agents.

Kenmei names no log view, audit trail, export, retention period, SIEM or observability integration for this traceability. It does not say what a traced action record contains.

Sourcekenmei.ai/solutions/kanp governance-and-security sectionread 2026-09-14

The agents have no memory of their own. The Telco Fabric holds live and historical network state, which is the customer's record of what the network did, ingested from the operator's systems and enriched for analysis. Agents do not write anything into it to read back on a later run.

The four layers, ingestion, decoders, builders and data model, hold no agent state and carry nothing over between runs. Data is reused across use cases, but context is not kept from one agent run to the next. There is no conversational state either. Network events on a streaming layer start the agents, not a user turn, and there is no chat, thread or session. The operator supplies rules and boundaries as configuration.

Sourcekenmei.ai/solutions/telco-fabric architecture and benefits sections, kenmei.ai/solutions/kanp how-it-works sectionread 2026-09-14

Customers can run the platform in their own cloud or on premises. Kenmei's line is "Runs where you need it", and it tells customers to "deploy in your cloud or on-premise. Your data never leaves your perimeter." The customer's own infrastructure is one of the options. Execution stays inside the operator's boundary as well as the data, since "all data access and execution remain within the CSP environment". On a product that ingests signaling traces and subscriber adjacent data, that decides whether it can be deployed at all.

The Telco Fabric is cloud native, with a "-90% CAPEX" claim for cloud native deployment, while the platform above it deploys into the customer's cloud or on premises. Customers can also buy through the Microsoft commercial marketplace, which is a sales channel and not a way of deploying. No region list, residency menu or named cloud region is published for the hosted option. Kenmei does not say what an on premises deployment requires and offers no installation, sizing or architecture guide for one.

Sourcekenmei.ai/solutions/kanp benefits and governance-and-security sections, kenmei.ai/solutions/telco-fabric benefits sectionread 2026-09-14

The AI Products catalog holds three named products, Anomalies, Geolocation and Interference. Each has its own page under /solutions/ai-products, linked from the main navigation on every page. Kenmei sells them as products in their own right, "Interference, Anomalies, Geo", where "each product pulls from the same unified source". They sit beside AI Agents and Professional Services as things built on the Telco Fabric.

Each product solves a named operational problem and can be adopted alone. None is a tier or module. Interference detection, anomaly detection and geolocation are long standing telecom analytics specialisms of Kenmei's. The agents themselves have no catalog. The Orchestrator and its specialists are named by function and have no pages of their own.

Sourcekenmei.ai/solutions/telco-fabric built-on-the-fabric section, kenmei.ai primary navigation read across three pagesread 2026-09-14

A continuous stream of network data starts the agents' work, with nobody at a screen. "Streaming and batch ingestion from OSS, traces, UE, and external systems" is the first of the four Telco Fabric layers, and the agents sit on top of it. Kenmei says its "AI agents detect, analyze, and recommend actions within seconds of an issue emerging", against the slow response to anomalies of older tools.

Kenmei's central argument is taking people out of the detection loop. "Most telco tools weren't built for autonomy. They're dashboards, not designed to simplify decision-making. Engineers still spend hours comparing KPIs, interpreting charts, and jumping between use-case specific tools, built to assist, not to act."

The events come from many kinds of source, including OSS records, signaling traces, UE data, alarms, configs and external systems. Batch ingestion handles sources that arrive on a cycle. Kenmei names no webhook, event subscription model, scheduler interface or queue the customer can configure.

Sourcekenmei.ai/solutions/telco-fabric architecture section, kenmei.ai/solutions/kanp why and meet-the-agents sectionsread 2026-09-14

No model provider, model selector, routing or bring your own key option is named. The architecture has an "AI / ML layer" that "applies advanced telco-specific algorithms to find issues and patterns", with no model named in it. Kenmei says "every algorithm is developed in-house for RAN, Core, and Transport scenarios", with "no generic AI".

Kenmei's own site does not name Microsoft Foundry, and a cloud vendor in the delivery path supplies infrastructure, not a model. Customers control objectives, rules and decision boundaries, which steer what the agents do but not which model runs. Kenmei has no documentation site.

Sourcekenmei.ai/solutions/kanp how-it-works and built-for-telco sections, kenmei.ai/solutions/telco-fabric architecture sectionread 2026-09-14

No API, SDK, MCP server or webhook is named on Kenmei's own site, which has no developers section and no documentation site. Its Microsoft Marketplace listing (offer kanp001), which Kenmei publishes, says that "Kenmei agents can securely communicate and collaborate with external agents outside the platform using Model Context Protocol (MCP)." Kenmei's site gives no technical detail on that MCP connection.

The direction of the connection is not clear. Kenmei's agents could use MCP as a client to reach external agents, or expose an MCP server that outside callers drive.

Sourcekenmei.ai navigation and footer read across three pagesread 2026-09-14

No pre deployment harness, scored test cases, golden set, accuracy or precision measure, judge or verdict is named for the agents, and there is no named release gate for a changed agent. Kenmei names no optimization loop on the agents' own output. The loop it describes optimizes the network, with agents continuously analyzing and optimizing network operations as their job.

The figures Kenmei gives measure the platform and customer economics, not agent quality. They are "up to 5x faster than generic ETL thanks to C++ core and Spark engine", ">3x ROI on ingestion", "-90% CAPEX via cloud-native deployment" and "-50% time-to-insight". Kenmei also says every algorithm is developed in house, which describes how the models were built. Kenmei does not say how it tests the agents internally.

Sourcekenmei.ai/solutions/kanp and kenmei.ai/solutions/telco-fabric read in full, kenmei.ai homeread 2026-09-14

The action path is a data pipeline, and the agents drive no hosted or local browser, desktop session or remote computer. The pipeline runs from ingestion to a data model the agents read, with decoders that "convert raw telco formats into standardized, open formats (e.g. Parquet)". There is no screen in the loop at any point, so a changed user interface cannot break the agents.

The multi vendor, multi RAT OSS integration reaches other systems through data interfaces. The customer's engineers operate the platform's own screens, and Kenmei's pitch is that engineers should stop doing so ("they're dashboards... engineers still spend hours comparing KPIs, interpreting charts"). The agents read an OSS vendor's data export and do not drive its console.

Sourcekenmei.ai/solutions/telco-fabric architecture section, kenmei.ai/solutions/kanp how-it-works and why sectionsread 2026-09-14