Agentic Ops in Practice: U Mobile, CNCF’s Boundary Problem and Grafana’s AI Observability

U Mobile’s telco operations have long relied on lean automation, but the rise of generative AI has opened a new frontier: agents that can navigate multiple back-office systems and resolve subscriber issues end-to-end. At the same time, the cloud-native community warns that the very tools empowering autonomous agents also blur the boundaries of what those agents can do, creating hidden governance risks.

This roundup reads three recent publications together: an AWS case study of U Mobile’s agentic help desk, a CNCF essay arguing that agent boundaries are a platform problem, and the observability announcements Grafana Labs made at ObservabilityCON 2026.

Context and Stakes

The operational bottleneck U Mobile describes begins when a subscriber cannot purchase a data add-on. The frontline service rep must pull interface logs, query business-support-system APIs for eligibility, and cross-reference internal policy documents before drafting a response. If any step fails, the ticket escalates to backend IT, extending the customer’s wait time. This coordination problem spans several heterogeneous systems and is not solved by simple script-based automation, which can only assist with response drafting.

The stakeholders span the entire telco value chain: frontline agents who spend minutes stitching together data, backend engineers who handle escalations, and ultimately the end-user whose experience degrades with each additional hand-off. Reducing the number of manual steps directly improves first-call resolution rates and cuts operational cost, a priority for a “newest 5G network provider” that prides itself on doing more with less.

Why now? Amazon Bedrock’s AgentCore platform offers a way to embed large-language-model reasoning into a workflow that can call APIs, retrieve logs, and consult knowledge bases without human prompting. U Mobile’s “AiDaH” initiative leverages this capability to move from isolated productivity gains to a holistic, upstream automation of problem diagnosis. Simultaneously, the CNCF’s analysis of the “boundary problem” highlights that as agents acquire more tools, their effective authority expands invisibly, often far beyond what operators intended. This drift is especially relevant when agents are granted credentials for one workflow that later persist across production environments, creating a latent security and compliance risk.

In this article we will explore how U Mobile built an agentic telco operation on Amazon Bedrock AgentCore, examine the platform-level challenges identified by the CNCF around tool accumulation and authority drift, and look at Grafana Labs’ recent push toward autonomous operations with AI-driven assistants. By grounding the discussion in these concrete examples, senior engineers will gain a clear view of both the opportunities and the governance pitfalls of deploying autonomous agents in production.

Background You Need

General background added for context, not drawn from the articles cited below.

Autonomous Agents

An autonomous agent is a software entity that can act on its own to achieve goals without constant human direction. It typically receives inputs from its environment, makes decisions using built-in logic or learned models, and performs actions that affect external systems. Autonomy does not imply omniscience; the agent’s capabilities are bounded by the tools, APIs, and data it can access. In practice, agents are used to automate repetitive operational tasks, such as incident triage, data retrieval, or policy enforcement, allowing human operators to focus on higher-level problem solving.

Tool Accumulation

When an autonomous agent is deployed, it often relies on a collection of utilities, scripts, APIs, credentials, and third-party services, to accomplish its tasks. Over time, new tools are added to support emerging workflows, and older tools may remain even after they are no longer needed. This gradual buildup creates a “tool accumulation” effect where the agent’s toolbox becomes larger and more complex than originally intended. The accumulated tools can be invoked unintentionally, expanding the agent’s effective reach beyond the scope of any single workflow.

Authority Drift

Authority drift describes the gradual expansion of an agent’s permissions as tools and credentials are added without a coordinated governance process. Each new capability may grant additional access, such as read/write rights to a database, the ability to invoke a deployment pipeline, or elevated network privileges. Because these grants are often introduced locally and invisibly, the overall authority of the agent can drift away from the original security model. The drift may go unnoticed for weeks, only becoming apparent when an unexpected action is observed.

Platform-Level Governance

Platform-level governance refers to the policies, controls, and observability mechanisms that oversee the entire lifecycle of autonomous agents across an organization. Effective governance requires a clear definition of permissible actions, systematic credential management, and audit trails that reveal when and why an agent exercised a particular tool. Without such oversight, the combination of tool accumulation and authority drift can lead to unintended side effects, security exposures, or operational instability.

Observability for Agentic Systems

Observability is the practice of collecting, correlating, and analyzing telemetry, logs, metrics, traces, to understand the internal state of a system from its external outputs. In the context of autonomous agents, observability enables engineers to see which tools an agent invoked, how decisions were made, and what outcomes resulted. Rich observability data supports debugging, performance tuning, and compliance verification, especially when agents operate across multiple services and environments.

AI-Driven Assistants

AI-driven assistants are conversational or programmatic interfaces that leverage large language models or specialized AI components to help users perform tasks. They can orchestrate multiple tools, generate code snippets, or summarize incident data, effectively acting as a thin layer of automation on top of existing platforms. While they increase productivity, they inherit the same platform-level risks, tool accumulation and authority drift, if their underlying toolset is not tightly managed.

What AWS Reports

U Mobile, Malaysia’s newest 5G network provider, has long pursued a lean operating model that emphasizes doing more with fewer resources through continuous automation. According to the AWS case study, the telco’s Information Systems Division (ISD) sought to move beyond basic productivity gains when new AI capabilities emerged. The goal was to improve the upstream phase of operations, specifically how teams diagnose and resolve problems, rather than merely assisting agents after an issue had been identified.

The case study explains that a typical subscriber problem, such as an inability to purchase a data add-on, is not a single fault but a coordination challenge. A customer service representative must retrieve interface logs for error codes, query business support system APIs to check subscriber eligibility, and cross-reference internal knowledge bases for relevant business policies. All of these steps span multiple systems before a single response can be drafted. If any step fails, the ticket escalates to backend IT teams, extending the subscriber’s wait time.

Traditional automation tools, AWS notes, can help agents compose better replies but cannot navigate multiple systems, synthesize the results, and propose corrective actions. To bridge this gap, U Mobile built an “agentic architecture” on Amazon Bedrock AgentCore. Working with AWS and the AWS Partner Axrail, the ISD created AiDaH, the AI-Driven Agentic Helpdesk. The case study describes AgentCore as a platform that enables the building, connecting, and optimizing of agents at scale, supporting any framework or model.

Two capabilities drove the selection of AgentCore. First, the managed agent runtime eliminated the need for the telco to operate its own agent infrastructure. Second, built-in memory allowed conversational context to persist across turns without requiring a separate state store. Within a year of initiating the project, AiDaH handles more than 150 documented operational scenarios across six business divisions. U Mobile’s internal measurements, as reported by AWS, show trouble-ticket volumes falling by up to 84.5 percent in key categories.

The case study outlines the three-pillar strategy that underpins the ISD’s approach:

• Reach, agents that can coordinate across backend systems in real time.
• Depth, chain-of-thought reasoning that supports multi-step root-cause analysis.
• Community, a secure, multi-tenant framework with role-based access control and built-in guardrails, available to every division.

The development timeline began in late 2025 with two pilot agents and Amazon Bedrock Knowledge Bases, a fully managed Retrieval-Augmented Generation (RAG) capability. A Q1 2026 pilot introduced the internal IT helpdesk with four agents covering 20 operational scenarios. Throughout 2026 the platform hardened, adding three-tier routing and expanding to six agents by mid-year. In Q3 2026 AiDaH went live to 50 L2 call-center and branch users with eight agents, and now supports over 150 documented scenarios.

The case study contrasts traditional AI assistance with “agentic AI” through a concrete example. For a “mobile data not working overseas” issue, a traditional AI assistant suggests troubleshooting steps but leaves the agent to manually verify roaming status, eligibility, raise tickets, and send the final reply. In contrast, AiDaH automatically checks the subscriber’s roaming configuration, verifies international data eligibility, identifies the failure point, and assembles a remediation plan, including which services to reset, what configuration to push, and whether a network ticket is warranted. The human agent reviews and confirms the plan before execution, preserving the decision point where it matters most.

A production case highlighted in the AWS narrative involved a subscriber unable to purchase an add-on. AiDaH traced the failure to an error code indicating a “Subscriber has pending order.” It further discovered that the customer had attempted the same purchase more than 30 times across multiple channels over three days, each attempt blocked by the same pending order. AiDaH surfaced the root cause and remediation steps in a single response, eliminating the manual cross-system investigation that would have been required previously.

Architecturally, AiDaH runs on a six-layer design built on Amazon Bedrock AgentCore and deployed in the Asia Pacific (Singapore) Region. Staff interact via Microsoft Teams, a deliberate choice to meet users where they already work, avoiding new applications or portal switching. Layer 1 provides the staff interface through Teams and a web portal served by Amazon CloudFront and protected by AWS WAF, with an AWS Lambda backend and a REST API for programmatic triggers. Layer 2 handles orchestration on AgentCore, applying pre-flight security checks (role-based access control, identity validation, guardrails) before routing requests. Roughly 70 percent of requests resolve through deterministic keyword matching without invoking a model, 20 percent are classified by a lightweight model, and only 10 percent require the full orchestrator, ensuring cost-optimized processing.

Layer 3 comprises specialist agents covering domains such as customer relationship management, number portability, order and SIM operations, infrastructure monitoring, big data analytics, cloud cost management, and finance operations. These agents communicate over the Agent2Agent (A2A) protocol, enabling delegation of subtasks and execution of cross-system workflows that no single agent could handle alone.

In summary, the AWS report details how U Mobile leveraged Amazon Bedrock AgentCore to transform a fragmented, manual help-desk process into an autonomous, agentic platform that dramatically reduces ticket volume, accelerates root-cause analysis, and scales across multiple business divisions while maintaining human oversight at critical decision points.

AWS: Mechanisms and Details

The U Mobile solution builds its agentic telco operations on Amazon Bedrock AgentCore, a suite of capabilities that together form a secure, observable, and extensible platform. The architecture is organized into six logical layers, each backed by specific AWS services and AgentCore features.

Layer 1, User Interface Agents are accessed through the AiDaH channel in Microsoft Teams. When a support agent types a request, the Teams message is captured by an AWS Lambda function. This function forwards both the user’s query and the federated identity of the caller to the orchestrator component.

Layer 2, Orchestrator and Identity The orchestrator performs a pre-flight check that validates the request against a six-tier role-based access control (RBAC) model stored in Amazon DynamoDB. Identity verification relies on AgentCore Identity, a capability of Amazon Bedrock AgentCore that issues short-lived access tokens. Amazon Bedrock Guardrails are applied to the incoming prompt to enforce content policies before any model invocation.

Layer 3, Routing and Classification After authentication, the orchestrator selects the cheapest tier that can satisfy the request. Deterministic phrase matching (for example, the exact phrase “port-in status”) bypasses model inference entirely. Ambiguous phrasing is sent to a lightweight classifier, while novel or multi-part questions are handed to the full orchestrator for deeper processing.

Layer 4, Agent Instantiation and Memory The chosen specialist agent runs as a session in the AgentCore runtime, another capability of Amazon Bedrock AgentCore. AgentCore memory rehydrates the conversation, automatically providing the agent with the subscriber number and any prior findings from earlier turns. This eliminates the need for the user to repeat information.

Layer 5, Tool Discovery, Authorization, and Backend Invocation Agents discover the tools they are entitled to use through the AgentCore Gateway. Each gateway publishes its backend as an MCP (Managed Cloud Platform) tool with typed inputs and outputs, allowing the agent to select a tool by name and schema rather than through hard-coded integration logic. OAuth authorization for tool calls is brokered by Amazon Cognito. The actual backend call is performed by a Lambda function or an MCP server, which translates the tool request into a call against the target system. Traffic traverses AWS Transit Gateway and an IPsec-encrypted Site-to-Site VPN tunnel to reach U Mobile’s on-premises number-portability platform. Sensitive fields are masked before the response is returned to the model.

Layer 6, Reasoning, Collaboration, and Response Generation If a query spans multiple domains, the agent uses the Agent2Agent protocol to delegate parts of the request to other specialist agents, for example, handing a billing block to the business support systems agent. Results from multiple agents are merged into a single narrative. The final response is grounded against Amazon Bedrock Knowledge Bases, ensuring citations to source evidence. The answer, together with any proposed remediation, is posted back to Teams for human confirmation.

Observability and Auditing AgentCore Observability streams every prompt, tool call, token count, and latency measurement to Amazon CloudWatch. In parallel, AWS CloudTrail records the corresponding API activity. This comprehensive trace enables full auditability of each interaction, satisfying U Mobile’s L2 support standard operating procedures.

Security Foundations U Mobile reinforced the platform’s security through a two-pronged approach. First, a Well-Architected Security Review validated the AWS Landing Zone against best practices, applying AWS Control Tower guardrails, AWS Organizations service control policies, and centralized identity federation. Findings were consolidated in AWS Security Hub, and encryption standards were enforced across every tier. Second, application-layer security ties every agent action to an authenticated user. Staff federate via Microsoft Entra ID, and AgentCore Identity issues the short-lived token that authorizes each agent invocation. Amazon Cognito mediates OAuth at the gateway, while the six-tier RBAC model enforces permissions per agent, per tool, and per data source. Sensitive subscriber data is masked at the gateway, and Amazon Bedrock Guardrails enforce content policies throughout the workflow.

Scalability and Extensibility Runtime hosts for AiDaH and its sub-agents are managed containers that scale automatically without server provisioning. Adding a new operational domain requires only the definition of a new gateway and its MCP tool specifications; steps 1-4 and steps 7-8 of the request flow remain unchanged. This stable core keeps the marginal cost of onboarding additional domains low, enabling U Mobile to cover over 150 documented operational scenarios across six domains, from customer management to business intelligence.

AWS: Examples, Results and Caveats

U Mobile’s deployment of the AiDaH platform illustrates how a telco can move from simple AI assistance to autonomous task execution using Amazon Bedrock AgentCore. The rollout began with a two-agent proof-of-concept that handled basic chat-bot interactions, FAQ look-ups and intent classification. Within nine months the system expanded to eight specialist agents that collaborate, invoke tools, and retrieve governed knowledge across operational domains. This progression is described as reaching “Level 7” on the competency model, where specialist agents support decision-making, while the target “Level 8” envisions fully self-healing systems that detect, diagnose and resolve problems without human involvement.

Concrete Use-Cases

The platform’s architecture is built around six layers that start with basic AI assistance (simple chatbots and FAQ look-ups) and culminate in autonomous task execution (AI completing defined tasks end-to-end with guardrails). Between these extremes lie contextual intelligence (memory-enabled, context-aware suggestions) and proactive AI (predictive alerts, anomaly detection, recommendation engines). The most advanced layer, collaborative multi-agent, enables specialist agents to work together, call external tools via the Model Context Protocol (MCP), and retrieve governed knowledge. Finally, self-healing and adaptive agents form the autonomous systems that continuously detect, diagnose, remediate and learn.

A concrete illustration of the collaborative multi-agent layer is the Agent2Agent (A2A) protocol. When a request spans customer records, interface logs and billing data, the query is automatically routed across the relevant specialist agents, each handling its sub-task and returning a combined answer. This eliminates the need for a monolithic integration layer and reduces the engineering effort required to onboard new backend systems.

Measured Impact

U Mobile’s internal measurements show dramatic reductions in trouble-ticket volumes after AiDaH entered production. Between January and September 2026, three major ticket categories fell by the following percentages:

• Provisioning and network tickets: down 84.5 %
• General inquiries: down 81.6 %
• Billing and charging tickets: down 48.7 %

These declines are attributed to the platform’s ability to automate routine checks, provide context-aware suggestions, and proactively surface anomalies before they become user-visible issues. An internal survey also rated the platform 4.6 out of 5 for ease of use, and daily usage has become routine among frontline teams. The platform’s formal incorporation into U Mobile’s Level 2 support standard operating procedures marked the transition from an optional tool to an auditable component of the support workflow.

Development Practices and Governance

The speed of expansion, from two use cases to over 150 documented scenarios, was enabled by a spec-driven development approach using Kiro, the AWS-provided agentic IDE. In Kiro, each new capability starts as a specification that defines requirements, design and task breakdown before any code is generated. This disciplined process allowed a small team to maintain a 12-week sprint cadence while adding new operational domains as repeatable “gateways” rather than bespoke integrations.

Security and governance were baked in early. The team performed a Well-Architected Security Review on the Landing Zone before scaling, ensuring that security controls are inherited by every new agent and gateway. Ongoing alignment with NIST SP 800-53, the OWASP Top 10 for LLM Applications, the CSA AI Trust Framework, and MITRE ATLAS provides a multi-layered compliance posture. Local regulations, Malaysia’s Personal Data Protection Act and the Malaysian Communications and Multimedia Commission rules, are also addressed throughout the platform’s lifecycle.

Caveats and Limitations

Despite the impressive ticket reductions, the source notes several practical constraints. First, adoption required a behavior-change effort; staff needed structured prompt templates to feel comfortable asking the AI for specific tasks such as “billing check” or “port-in status.” Without these templates, users hesitated to engage the system, indicating that technical capability alone does not guarantee usage.

Second, the platform’s autonomy is deliberately bounded by guardrails. While agents can complete defined tasks end-to-end, they still operate within a framework that requires human oversight for higher-risk decisions. The target Level 8 competency, full self-resolution without human involvement, is still a future goal, implying that current deployments stop short of complete autonomy.

Third, the reliance on managed infrastructure (Amazon Bedrock AgentCore) abstracts away scaling and patching responsibilities but also ties the solution to AWS-specific services. Organizations that prefer a multi-cloud or on-premises agent runtime would need to evaluate the portability of the MCP and A2A protocols.

Finally, the reported ticket reductions are internal measurements from U Mobile’s own systems. The source does not provide external benchmarks or third-party validation, so the results should be interpreted as organization-specific outcomes rather than industry-wide expectations.

Takeaway

U Mobile’s experience demonstrates that a telco can achieve substantial operational efficiencies by layering increasingly sophisticated AI capabilities, from simple chatbots to collaborative specialist agents, on top of a managed agent runtime. The concrete results, ticket reductions of up to 84.5 % in key categories, show the potential upside. However, success hinges on structured prompt design, disciplined spec-driven development, early security governance, and an explicit acknowledgment that full autonomy remains a work in progress. Organizations considering a similar path should plan for behavior-change initiatives, maintain clear guardrails, and assess the implications of a tightly coupled AWS-centric stack.

What CNCF Reports

The CNCF article “The boundary problem in agentic AI is a platform problem” frames the core risk of autonomous agents as a mismatch between the tools they can access and the intentions encoded in their prompts. William Rizzo and Francesco Beltramini argue that an autonomous agent “will do exactly what its tools let it do, and no more,” and that this apparent constraint is in fact the whole problem. The set of capabilities an agent inherits is rarely the set that any human deliberately chose; instead it is the accumulated set of tools, credentials, and delegations that have been added over time across many workflows.

Tool Accumulation and Authority Drift

According to the CNCF authors, a tool added for one workflow “stays available for every workflow.” Likewise, a credential scoped for a demo can survive into production, and a delegation introduced to unblock a Friday deployment can become a permanent edge in the graph. Because no explicit decision ever defines the agent’s reach, authority is granted “incrementally, locally, and invisibly.” Over enough deployments this pattern produces a drift where the system’s actual power “drifts steadily away from anyone’s model of what it should be able to do.” The authors note that by the time a stakeholder asks “wait, can it do that?” the honest answer is often “it could for weeks, and we only noticed now.”

Governance Mis-targeted at the Wrong Layer

The CNCF piece cautions against treating the boundary problem as a governance failure that can be solved with “process and review boards.” Process, they explain, governs the decisions humans make, but the boundary problem is “largely about the decisions nobody makes, the capabilities that arrive without a decision.” Since the changes never surface as a change, they cannot be reviewed. The authors therefore call for a substrate that “holds the line whether or not anyone is watching,” shifting the focus from human oversight to platform enforcement.

Limits of Agent-Centric Controls

A tempting shortcut, according to the CNCF authors, is to make the agent responsible for its own limits by embedding constraints in its instructions. This approach “fails structurally,” because an agent’s output is a probability distribution over next actions, not a guarantee. The authors illustrate that a boundary that “holds ninety-nine times and yields on the hundredth is not a boundary; it is a strong suggestion with a failure rate.” Moreover, the conditions that push an agent toward the edge, novel inputs, adversarial phrasing, unusual state, are precisely when the boundary matters most and the probabilistic adherence is weakest.

Even a perfectly compliant agent that always follows its instructions would still be limited by the authority of its tools and credentials. The CNCF writers point out that “the instruction is a statement of intent. The tool binding is a statement of capability. When those two disagree, capability wins, because capability is what executes.” An agent instructed not to move money but holding a tool that moves money is “one clever prompt or one confused reasoning step away from moving money.” Thus the gap between intended scope and granted capability constitutes the entire attack surface.

Platform-Level Boundary Enforcement

The CNCF article concludes that “bounded autonomy is not a property of the agent. It is a property of the platform the agent runs on.” The authors draw a parallel to the microservice world, noting that the industry has spent fifteen years learning to bound what a workload can do. A microservice is “software that will do whatever its identity, network access, and permissions allow,” and the discipline built around “not trusting a workload to police itself” applies directly to agents. An agent is described as “an unusually capable workload with a non-deterministic control loop,” but the same machinery that bounds workloads can be applied.

To operationalize this, the CNCF authors introduce the “Safe Operating Model,” which organizes bounding mechanisms as “concentric rings of least privilege.” Each ring binds one question about the agent, and each outer ring depends on the inner one. The order is intentional: “Reach cannot be enforced without knowing what is connecting; capability cannot be enforced without knowing what is acting.” By moving the boundary enforcement into the platform layer, the authors argue that the problem stops being novel and can be addressed with existing workload-security practices.

CNCF: Mechanisms and Details

CNCF frames the boundary problem for agentic AI as a series of concentric “rings” that together enforce a platform-level boundary. Each ring relies on a verified identity that is issued by a workload-identity standard, which provides every agent and tool server with a short-lived, attested credential. Because the platform no longer trusts an agent’s word about its own identity, every downstream decision, reach checks, capability checks, and data-plane authorizations, uses this verified identity instead of a bearer token that could leak or be replayed. Getting this identity verification correct, CNCF argues, is the foundation for any meaningful boundary.

Ring 1, Reach Once identity is established, the first enforcement layer limits reach: the set of services an agent may connect to. CNCF specifies that a service mesh enforces reach on a per-connection basis, using the verified identity rather than network topology. The mesh consults a declarative reach policy that lists the peers an agent is allowed to talk to. If an agent attempts to open a connection to a service without a declared relationship, the mesh refuses the connection before it is established. Because reach is declared, any addition of a new edge to the graph must be made through an explicit, reviewable change. This prevents the “drift problem” where connections accumulate silently at runtime.

Ring 2, Capability The second ring separates admission from call-path enforcement. Admission governs which capabilities, i.e., which tools, an agent may hold. CNCF describes this as a declarative resource in the cluster that lists approved tools. When an agent tries to bind a tool that is not in this list, the admission controller rejects the attempt at the moment of binding, preventing the tool from entering the system without review. The call-path layer then authorizes each individual invocation of a sanctioned tool against the agent’s identity. Even if a tool is present and reachable, the gateway can refuse a specific call if the tool is outside the permitted set for that invocation. This design makes capability a per-action grant rather than a latent permission that could be misused later. Holding a tool and being allowed to use it at a given moment are deliberately separated.

Keystone, Immutable Identity Authority Above the two rings sits a single “keystone” control that ensures the rings remain coherent. All boundary definitions, identity registrations, mesh authorizations, admission policies, and tool allow-lists, are expressed as declarative state. The keystone rule, as CNCF puts it, is that an agent’s own identity is denied any ability to modify the objects that define its authority. An agent can act within its bounds but cannot rewrite its own identity, capability definitions, or reach policies. Changes to these objects must come from a reviewed, version-controlled configuration change performed by a human or an automated pipeline, never by the agent at runtime. This immutable authority prevents an agent from dissolving its own boundary from the inside.

Ring 3, Data The outermost ring governs data scope. CNCF notes that data access is enforced at the data plane by the systems that actually store the records, not by the mesh or admission controller. Nevertheless, the same verified identity that the core established is used to authorize data requests. Because data governance is tied to the identity, the outer ring can enforce who may see which records without requiring a separate mechanism.

Implementation Steps

1. Issue Verified Identity, Deploy a workload-identity standard that issues short-lived, attested credentials to every agent and tool server.
2. Configure Reach Policies, Define declarative reach rules in the service mesh, mapping each verified identity to the set of allowed peer services.
3. Define Capability Allow-Lists, Create cluster-level declarative resources that list approved tools for each agent identity.
4. Enforce Admission, Deploy an admission controller that rejects any attempt by an agent to bind a tool not present in the allow-list.
5. Gate Call Paths, Place a gateway that authorizes each tool invocation against the agent’s verified identity and the per-action capability grant.
6. Lock Down Identity Authority, Apply a policy that denies agents any permission to edit identity registrations, reach policies, admission resources, or tool allow-lists.
7. Apply Data-Plane Controls, Ensure data storage systems check the verified identity on every read or write request, aligning data access with the identity-based model.

By layering identity verification, reach enforcement, capability admission, per-action call-path checks, and immutable authority, CNCF’s model provides a concrete, platform-level mechanism for bounding autonomous agents. Each ring is expressed as declarative configuration, making the boundary both auditable and resistant to runtime drift.

CNCF: Examples, Results and Caveats

The CNCF analysis frames the “boundary problem” for agentic AI as fundamentally a platform issue rather than a flaw in the agents themselves. The text offers concrete illustrations, expected outcomes, and the practical limits of this approach.

Example: Regulated loan-origination workflow In a typical loan-origination process, the agent is allowed to read the application, retrieve relevant signals, weigh risk, and generate a recommendation together with its reasoning. The deterministic part of the workflow, approval, pricing, and fund transfer, remains under human control and enforced by the platform. The agent’s output is emitted as a draft change, such as a pull request against the desired state, which must be reviewed by a human and then applied by a pipeline. This pattern shows how the agent can perform cognitive work while the platform retains the final, auditable decision points.

Result: Auditable, deterministic outcomes When identity is verified, reach is declared, and capability is granted per action, every step of the workflow leaves a trace in the platform. The platform records which agent performed which action, the policy that permitted it, and the resulting state change. Because the platform, not the agent, enforces the deterministic gates, the system produces evidence automatically. The CNCF text emphasizes that “provenance that falls out of enforcement is worth more than any assurance an agent could give about its own conduct.” In practice, this means regulators can rely on the platform’s logs rather than on after-the-fact statements from the agent.

Example: Cloud-native stack as a Safe Operating Model The CNCF authors argue that the mature cloud-native stack already contains the building blocks needed for a safe operating model. Specific components include:

• Workload identity for agents, agents are treated as workloads with cryptographic identities.
• Mesh-enforced reach, service meshes limit which services an agent can contact based on its identity.
• Policy-as-code at admission, admission controllers evaluate capability policies before allowing actions.
• Per-call authorization at the tool boundary, each tool interaction is checked against the agent’s declared capabilities.
• Version-controlled configuration, any change to the system must pass through a version-controlled pipeline.

These pieces are already production-grade projects, according to the CNCF text, and the remaining work is integration and rigor rather than invention.

Caveat: New declarative surface for identity and capability What is genuinely new, the CNCF notes, is the need to express an agent’s identity and permitted capabilities as first-class declarative objects, and to enforce per-tool authorization. This “surface is young and moving quickly.” Because it is a thin layer on top of a stable foundation, the risk is not a lack of underlying security but the immaturity of the declarative specifications and the tooling that enforces them. Early adopters must therefore monitor rapid changes in the ecosystem and be prepared to update policies as the abstraction evolves.

Caveat: Platform-centric bounding, not agent-centric security The CNCF authors stress that the boundary will not come from the agent. Agents are designed to explore possible actions, so the platform must decide the shape of that action space. This shifts the security responsibility from building “agent-specific security from scratch” to ensuring that the platform correctly bounds workloads. The implication is that any lapse in platform configuration, mis-configured mesh policies, outdated admission controllers, or gaps in version-controlled pipelines, directly compromises the safety guarantees for agents. Consequently, the burden of security rests on platform engineers rather than on AI developers.

Result: Minimal new engineering effort Because the required capabilities map onto existing cloud-native projects, the CNCF predicts that the engineering effort is largely about integration. The text states that “every one of them has a production-grade project behind it today.” Therefore, organizations can leverage existing tools, such as Kubernetes admission controllers, service meshes like Linkerd, and CI/CD pipelines, to enforce agent boundaries without building custom security layers.

Caveat: Limited scope of current examples The loan-origination scenario illustrates a regulated domain where deterministic gates are clearly defined. The CNCF text does not provide examples from less regulated or highly dynamic environments, leaving open the question of how the model scales to use cases where the boundary between deterministic and non-deterministic steps is fuzzy. In such contexts, the platform may need additional mechanisms to dynamically adjust reach and capability, which the current guidance does not detail.

Result: Platform-level evidence generation When the platform enforces reach, capability, and per-call authorization, the system “produces evidence as a byproduct of operating.” This evidence includes identity verification, declared reach, granted capabilities, and the audited path of any change. The CNCF authors argue that this evidence is more reliable than any post-hoc claim an agent could make about its conduct.

Overall assessment The CNCF perspective presents a concrete, platform-centric strategy for governing autonomous agents in regulated settings. By anchoring agent actions to deterministic infrastructure, identity, mesh reach, policy-as-code, per-call checks, and version-controlled pipelines, the model promises auditable outcomes and leverages existing cloud-native tooling. However, the approach hinges on the maturity of the declarative identity/capability layer and assumes that platform configurations remain flawless. Organizations must therefore treat the platform boundary as the critical security frontier, continuously validate policy enforcement, and be aware that the current examples focus on well-defined regulated workflows, leaving open questions for more fluid domains.

What Grafana Labs Reports

Grafana Labs used ObservabilityCON 2026 in San Francisco to unveil a suite of new Grafana Cloud capabilities that it frames as a path toward autonomous operations powered by AI. The announcements are organized around two themes: AI-driven assistance for operational workflows and cost-focused telemetry management.

AI-driven assistance

Grafana Assistant is positioned as the central AI layer that aggregates operational tasks inside Grafana Cloud. According to Grafana Labs, its AI features “automate much of the undifferentiated heavy lifting while still keeping you in control.” The first feature highlighted is Assistant Investigations, which has been generally available since late July. This capability can launch deeper investigations automatically from an alert or incident, and it can be invoked from the Grafana platform, Slack, the Grafana Cloud MCP server, or the gcx command-line tool.

The next addition is Assistant Watchers, now generally available, described as “always-on agents that detect changes not captured by predefined alert rules.” Users describe what to monitor in plain language and select the relevant data sources; the Watcher then builds a baseline from historical telemetry patterns and surfaces findings when those patterns diverge. This approach shifts the detection logic from static thresholds to a pattern-based model that learns from past data.

Grafana Labs also introduced Grafana Managed Sandboxes in public preview. The sandbox provides a controlled cloud environment where developers can ask questions about source code, make changes, and prepare pull requests directly from conversations in Grafana Cloud. The sandbox leverages context from repository code and live telemetry to propose potential fixes, which a team member can review and approve. This blends code-centric workflows with observability data, aiming to reduce the friction between detection and remediation.

Finally, Grafana Pages (public preview) extends the visualization model beyond traditional dashboards. Users describe the desired outcome in natural language, and the Assistant builds a page on a canvas without any code. Existing visualization components remain usable, but Pages are presented as “the next evolution of Grafana,” offering an app-like experience that can be customized through conversational prompts.

Grafana Labs emphasizes that customers can choose which parts of their operations remain manual and which are handed off to the Assistant, reinforcing a hybrid model of autonomy and human oversight.

Cloud economics reimagined

The second theme addresses the growing volume of telemetry and the need to control storage costs. Grafana Labs announced major query performance enhancements to Grafana Cloud Logs, built on technology from its Logline acquisition, and introduced Adaptive Telemetry, a suite that optimizes cost across metrics, logs, traces, and profiles.

Adaptive Telemetry works by “recommending what to aggregate or sample, so teams keep the telemetry that matters.” Grafana Labs states that customers “have cut telemetry spend by 30% to 50% on average.” One customer quote from Rapid7’s Principal Software Engineer, Carl Eastman, notes that moving to Grafana Cloud and using Adaptive Telemetry “cut our metrics costs enough to fund logs and traces as well,” while visibility improved and dashboards became faster and less noisy.

Specific components of Adaptive Telemetry include:

• Adaptive Metrics (generally available) that continuously applies optimization recommendations while preserving existing dashboards and alerts. A “cost-first mode” acts as a safeguard, applying only recommendations that do not increase the total active series, thereby preventing inadvertent cost spikes.
• Adaptive Logs Archive (public preview) that routes logs to an object-storage bucket owned by the customer. This enables cost savings by removing logs from Grafana Cloud storage while retaining them for low-cost, on-demand investigations, audits, or compliance. An associated preview, Adaptive Logs replay, allows users to bring archived logs back into Grafana Cloud when needed.
• Adaptive Traces (generally available) that aggressively samples traces to reduce volume, yet guarantees retrieval of any trace by ID from the last 24 hours, even if it was dropped by sampling. This ensures that cost reductions do not compromise the ability to investigate specific incidents.
• Volumetric sampling (generally available) replaces simple probabilistic sampling with a method that spreads the sample more evenly across the data set, delivering a “more valuable sample” for analysis.

Collectively, these features aim to align storage and query costs with the value derived from telemetry, allowing teams to “keep only the data worth paying for” while still maintaining the depth of insight required for autonomous operations.

Summary of the announced roadmap

Grafana Labs frames the new AI-driven Assistant features and Adaptive Telemetry suite as complementary pillars of an “agentic observability cloud.” The Assistant suite (Investigations, Watchers, Managed Sandboxes, Pages) is designed to reduce manual effort, surface anomalies through pattern-based detection, and integrate code-level remediation directly into the observability platform. Adaptive Telemetry, meanwhile, tackles the financial pressures of ever-growing telemetry streams by recommending aggregation, sampling, and archival strategies that have already delivered 30 %-50 % cost reductions for customers. By offering both operational autonomy and cost-aware telemetry management, Grafana Labs positions its cloud offering as a unified platform for teams seeking to move toward autonomous operations without sacrificing control or visibility.

Grafana Labs: Mechanisms and Details

Grafana Labs’ 2026 observability roadmap introduces several tightly coupled mechanisms that together expand the platform’s ability to surface context for both human operators and autonomous agents. The core of this expansion is the Knowledge Graph, a runtime context layer that aggregates components, relationships, and health signals across the entire stack. The Knowledge Graph is now positioned as a platform capability, meaning it is baked into every Grafana Cloud stack and can be curated by users to reflect organization-specific entities.

Knowledge Graph construction begins with automatic discovery of services, resources, and dependencies. Grafana Cloud continuously ingests telemetry from a variety of sources, frontend applications, synthetic checks, cloud provider resources, and databases. For each discovered element, the system creates a node in the graph and links it to related nodes based on observed communication patterns, trace spans, and metric labels. The graph’s coverage has been broadened to include:

• Frontend apps (generally available) that map user-facing signals to the backend services that serve them.
• Synthetic checks (public preview) whose alerts are placed alongside service health nodes, enabling a unified view of synthetic failures and real-world incidents.
• Google Cloud, Azure, and AWS resources (generally available) that are automatically mapped, giving a more complete picture of cloud infrastructure.
• AI agents (public preview) that are represented as “Agent Observability” nodes, showing how each agent connects to its dependent services.
• Microsoft SQL Server databases (private preview) that are discovered and added to the graph without manual configuration.

Beyond automatic discovery, the Knowledge Graph supports custom entities and relationships (generally available). Organizations can define domain-specific nodes, such as business processes, product lines, or compliance artifacts, and explicitly link them to existing service or infrastructure nodes. This extensibility allows the graph to reflect the unique operational model of each team.

A complementary mechanism is Service ownership integration (private preview). By linking the Knowledge Graph to Grafana Cloud Service Center, each service node is enriched with metadata about the owning team, on-call schedules, and runbooks. When an agent or user follows a dependency chain, the graph surface also displays who is responsible for the next hop, streamlining hand-offs during incident response.

To keep telemetry volume manageable while preserving diagnostic richness, Grafana Labs introduced Diversity sampling (generally available). Unlike traditional probabilistic sampling, Diversity sampling stores a unique combination of attributes, service, route, and status code, every 15 minutes. This approach ensures that low-volume services are not eclipsed by high-traffic ones and that the sample adapts automatically as traffic patterns shift. Early testing reported about 25 % higher information density compared to probabilistic sampling at the same volume, meaning more useful signals are retained per unit of data.

Another performance-focused mechanism is full-text search in Grafana Cloud Logs, built on technology acquired from Logline in April 2026. The feature enables needle-in-a-haystack queries without scanning the entire log corpus. In a real-world test, a customer reduced the volume of logs searched for newly submitted data from nearly a terabyte in three minutes to around 100 gigabytes in under three seconds, an 80-90 % reduction. This speedup not only benefits manual debugging but also accelerates AI-driven investigations, where agents may issue hundreds of queries to pinpoint root causes.

The platform also provides Adaptive Telemetry, a sampling strategy that dynamically balances budget across services and request types. By adjusting allocation as traffic changes, Adaptive Telemetry prevents low-volume services from being crowded out and maintains a consistent signal-to-noise ratio across the stack.

All of these mechanisms converge to give AI agents richer, more accurate context. Agents can query the Knowledge Graph to understand service dependencies, retrieve ownership metadata, and leverage fast full-text log searches to correlate events. The combination of automatic discovery, custom extensibility, and efficient sampling creates a feedback loop: agents surface insights, operators refine custom entities or ownership links, and the graph evolves to reflect the latest operational reality.

In practice, the workflow for an autonomous agent looks like this:

1. Discovery, The agent queries the Knowledge Graph to retrieve the topology surrounding a target service.
2. Ownership lookup, Using the Service ownership integration, the agent identifies the responsible team and on-call schedule.
3. Telemetry selection, The agent selects relevant logs via the full-text search API, benefiting from the 80-90 % reduction in data scanned.
4. Sampling, Diversity sampling ensures that the logs include representative low-volume paths, while Adaptive Telemetry guarantees that the query stays within budget.
5. Root-cause analysis, Correlating log entries, metric anomalies, and synthetic alerts, the agent proposes a hypothesis and surfaces it to the responsible team through Grafana Assistant.

Through these tightly integrated mechanisms, Knowledge Graph, custom entities, service ownership, Diversity sampling, Adaptive Telemetry, and high-performance full-text search, Grafana Labs provides a platform that not only aggregates observability data but also structures it in a way that autonomous agents can consume, reason about, and act upon.

Grafana Labs: Examples, Results and Caveats

Grafana Labs’ ObservabilityCON 2026 announcements showcase a suite of agent-enabled capabilities that illustrate how shared runtime context and automation can be applied across a modern observability stack. The examples range from AI-assisted incident response to user-experience monitoring, each accompanied by early-stage results and explicit preview status that serve as practical caveats for adoption.

Shared Knowledge Graph for AI agents Grafana Cloud IRM now integrates the Knowledge Graph as runtime context for AI agents. In practice, an agent, whether the built-in Grafana Assistant or a custom one brought in through the gcx integration, can query the graph to retrieve “operational context from past incidents” and surface relevant parts of the system during a new investigation. This shared context enables the agent to “build on what you’ve already learned,” reducing the need for engineers to manually re-assemble historical evidence. The result is a more streamlined root-cause analysis workflow, though the feature is only “generally available” for the Knowledge Graph itself; the surrounding integrations remain in preview, meaning production-grade reliability is not yet guaranteed.

Digital Experience Monitoring (DEM) previews Grafana Cloud’s DEM capabilities combine Synthetic Monitoring with Frontend Observability to surface both proactive test results and real-user signals. Three preview-stage features illustrate concrete use cases:

• Session Replay (public preview) records a user’s exact interactions within an application, then correlates those actions with underlying telemetry. Engineers can watch a playback to see precisely “what your users actually did,” then jump to the associated logs, traces, or metrics to understand why a failure occurred. The public preview status indicates that the feature is openly accessible but still undergoing refinement, so users should expect occasional gaps in coverage or UI polish.
• Mobile Observability (private preview) extends Frontend Observability to native mobile platforms (iOS, Android, React Native, Flutter) via upstream OpenTelemetry SDKs. By seeing what mobile users experience and linking it to the same telemetry as the rest of the stack, teams can diagnose performance regressions that are unique to mobile environments. The private preview label signals that access is limited to invited participants, and broader availability will depend on feedback and stability testing.
• Critical User Journeys (private preview) lets teams define “which journeys matter most” and provides a single view that traces a drop in conversion rate back to its root cause. This example demonstrates how a shared definition of “critical” can replace ad-hoc, team-specific metrics, fostering consistency across product and reliability groups. As with the other mobile features, the private preview status means that the functionality is not yet generally available and may evolve substantially before GA.

Grafana Workflows for incident automation The public preview of Grafana Workflows introduces event-driven automation that stitches together actions across Grafana Cloud and external tools. A concrete example describes a workflow that automatically creates an incident channel, pages on-call personnel, and invokes Grafana Assistant to “prepare a briefing from the available evidence.” Pre-built blueprints cover common scenarios such as incident kickoff, on-call handoff reports, and weekly service health summaries. The result is a reduction in manual steps during high-stress incidents, allowing engineers to focus on diagnosis rather than coordination. However, the preview nature of the product implies that workflow definitions, especially those involving custom integrations, may require adjustments as the API surface stabilizes.

Marketplace plugins as extensibility points Grafana’s Marketplace, now generally available, offers more than 30 partner-built plugins spanning security, networking, and cloud-cost optimization. While the marketplace itself is GA, many of the plugins are paid and come with “partner-backed commitments to ongoing maintenance, compatibility, and support.” For Grafana Cloud users, a 14-day free trial provides full functionality, allowing teams to evaluate extensions before committing financially. The caveat here is that the quality and update cadence of plugins depend on third-party partners; organizations must assess each plugin’s support SLA individually.

Overall performance implications and adoption limits Across these announcements, Grafana Labs emphasizes that the new capabilities are designed to “close the gap between system health and user experiences” and to “turn processes into automated steps.” Early adopters can expect faster incident triage, richer context for AI-driven analysis, and a more unified view of digital experience. Nonetheless, the prevalence of “public preview,” “private preview,” and “generally available” qualifiers signals a staged rollout. Teams should treat the preview features as experimental, suitable for pilot projects or non-critical environments, while monitoring Grafana’s blog updates for GA timelines and stability metrics. The reliance on external plugins also introduces a dependency risk that must be managed through partner evaluation and contractual safeguards.

Where the Perspectives Align and Diverge

• AWS and Grafana Labs both describe agentic systems as ways to reduce manual effort and accelerate incident resolution, with AWS citing “continuous automation” for telco operations and Grafana noting “AI features that automate much of the undifferentiated heavy lifting.”
• CNCF and AWS agree that the underlying platform determines what an autonomous agent can do; CNCF states “an autonomous agent will do exactly what its tools let it do,” while AWS highlights the “managed agent runtime” that removes the need to operate infrastructure.
• CNCF and Grafana Labs share the view that autonomous agents must be governed at a higher level than individual prompts or instructions; CNCF calls this a “substrate that holds the line,” and Grafana emphasizes “you’re doing it with AI features … while still keeping you in control.”
• All three sources treat the agentic approach as an evolution rather than a one-off project: AWS frames AiDaH as “the next step in a long-running journey,” CNCF describes the boundary problem as an “accumulative” pattern across deployments, and Grafana presents its “open agentic observability cloud” as a platform that will continue to expand.

Differences at a Glance

Scope of Application AWS’s narrative is rooted in a specific industry use case, U Mobile’s telco helpdesk, where the agentic platform orchestrates log retrieval, API queries, and policy checks to resolve subscriber issues. CNCF, by contrast, discusses the boundary problem in abstract terms, focusing on any autonomous agent that accumulates tools and credentials across workflows, without tying the discussion to a particular sector. Grafana’s coverage is broader still, positioning its AI-driven assistant as a general observability layer that can be invoked from alerts, Slack, or the Grafana Cloud MCP server, targeting a wide range of cloud-native teams rather than a single vertical.

Mechanisms for Autonomy AWS emphasizes two concrete platform capabilities: a “managed agent runtime” that eliminates the need for dedicated infrastructure, and “built-in memory” that preserves conversational context without a separate state store. These mechanisms are presented as the technical foundation that enables AiDaH to handle “over 150 documented operational scenarios” within a year. CNCF does not describe any specific runtime or memory features; instead, it warns that agents inherit every tool added to the system, leading to “authority is granted incrementally, locally, and invisibly.” The CNCF solution is a conceptual “substrate” that enforces boundaries, not a concrete runtime. Grafana’s approach blends platform services with AI assistance: “Assistant Watchers” continuously monitor telemetry baselines, while “Grafana Managed Sandboxes” provide a controlled environment for code-related queries. The emphasis is on plug-in style extensions that augment existing observability data rather than on a unified runtime.

Target Audience and Decision-Making Context AWS writes from the perspective of a telco operator (U Mobile) and its ISD team, addressing senior engineers who need to integrate multiple internal systems and reduce ticket escalation latency. The article positions the platform as a solution to “lean” operational constraints. CNCF targets a developer-centric audience concerned with governance and security across large-scale deployments, warning that “process governs the decisions humans make” while the platform silently expands agent reach. Grafana addresses cloud-native practitioners who are already consuming Grafana Cloud services; its guidance includes “preview” status warnings and advises teams to treat new features as experimental, focusing on adoption risk rather than governance.

Treatment of Governance and Control AWS portrays the managed runtime and built-in memory as simplifying control: “no agent infrastructure to operate” and “conversational context across turns” reduce the need for manual state management. Governance is implied to be handled by the platform provider (AWS) rather than the user. CNCF explicitly argues that traditional governance, processes, review boards, misses the core issue, advocating instead for platform-level enforcement that automatically contains authority drift. Grafana adopts a hybrid stance: it offers “always-on agents” (Assistant Watchers) that operate autonomously but still require human oversight (“a person on your team can then review and approve” fixes proposed in sandboxes). Thus, Grafana acknowledges the need for human-in-the-loop checks even as it pushes automation.

Readiness and Stability Signals AWS presents AiDaH as a production-ready service that already “handles over 150 documented operational scenarios” after a year of deployment, suggesting a mature, stable offering. CNCF’s discussion is forward-looking, identifying a systemic risk without providing a concrete product roadmap or maturity level. Grafana explicitly labels new capabilities with “public preview,” “private preview,” and “generally available,” signaling a staged rollout and urging teams to treat preview features as experimental. This contrast matters for readers deciding whether to adopt a solution now (AWS), to plan for future governance frameworks (CNCF), or to pilot emerging AI features while monitoring stability (Grafana).

Out-of-Scope Topics CNCF does not address specific telco workflows or the concrete memory handling that AWS describes, and it does not discuss preview release strategies that Grafana emphasizes. Conversely, Grafana does not delve into the boundary-drift problem or the incremental credential accumulation highlighted by CNCF, nor does it provide the telco-specific integration details that AWS supplies. These gaps are relevant only when a reader’s decision hinges on industry-specific integration (favoring AWS), on platform-wide security governance (favoring CNCF), or on staged feature adoption within a cloud-native observability stack (favoring Grafana).

Technical Details and Practical Guidance

AWS Bedrock AgentCore Integration

• Conversation state, Deploy AgentCore memory (a capability of Amazon Bedrock AgentCore) to persist context across turns. The memory rehydrates the session so the agent inherits the subscriber number and prior findings without prompting the user again.
• Access control, Store the six-tier role-based access control model and session metadata in Amazon DynamoDB. The orchestrator validates the caller’s federated identity against this model before any tool invocation.
• Identity verification, Use the AgentCore Identity token, issued by Bedrock AgentCore, and validate it with Amazon Cognito, which brokers the OAuth flow for downstream tool calls.
• Routing logic, Implement a deterministic phrase matcher for known intents (e.g., “port-in status”) that bypasses model inference. For ambiguous phrasing route to a lightweight classifier; for novel or multi-part questions forward to the full orchestrator.
• Agent instantiation, Run each specialist agent as a session in the AgentCore runtime. The runtime fetches the appropriate tool definitions from the AgentCore Gateway, which publishes back-ends as MCP tools with typed inputs and outputs.
• Network connectivity, Configure AWS Transit Gateway and AWS Site-to-Site VPN (IPsec-encrypted tunnel with no public internet exposure) to reach on-premises operational systems such as a number-portability platform. Ensure sensitive fields are masked before the response returns to the model.
• Collaboration, When a request spans multiple domains, enable the Agent2Agent protocol so agents can delegate work to peer agents securely.

CNCF Identity-Centric Control Model

• Workload identity, Issue each agent and each tool server a short-lived, attested credential via a workload identity standard. This replaces bearer tokens and prevents replay attacks.
• Reach enforcement, Declare the set of services an agent may connect to (Ring 1). Enforce this per-connection in the service mesh; any attempt to reach an undeclared peer is refused before the connection opens. Changes to reach declarations are versioned, reviewable, and attributable.
• Capability enforcement, Define the tools an agent may invoke in a declarative resource (Ring 2). Policy admission checks reject any attempt to bind a tool that has not been pre-approved. The call-path enforcement point then ensures the agent cannot execute actions beyond its granted capabilities.

Grafana Labs Adaptive Telemetry and Full-Text Search

• Diversity sampling, Enable the generally available diversity sampler to store a unique combination of attributes (service, route, status code) every 15 minutes. This approach yields about 25 % higher information density than probabilistic sampling at the same volume, according to Grafana Labs testing.
• Full-text search, Activate the Logline-based full-text search in Grafana Cloud Logs (generally available). In a benchmark, processing nearly a terabyte of logs in three minutes was reduced to around 100 gigabytes in under three seconds, representing an 80-90 % reduction in the volume of logs searched. This speedup benefits AI-driven investigations that issue many queries.
• Knowledge Graph, Leverage the expanded Knowledge Graph to provide richer operational context for AI agents. The graph links telemetry across services, routes, and status codes, enabling agents to reason about system health and root causes without custom integration code.

Practical Step-by-Step Blueprint

1. Provision identity, Deploy a workload-identity provider (e.g., SPIFFE) to issue short-lived credentials for every agent and tool server.
2. Define reach, Create service-mesh policies that enumerate allowed destination services per agent. Apply these policies before any network traffic is permitted.
3. Declare capabilities, Store approved tool definitions in a Kubernetes custom resource (or equivalent declarative store). Configure admission controllers to reject any binding to undeclared tools.
4. Set up AgentCore, - Deploy the Bedrock AgentCore runtime in your VPC.

• Configure AgentCore memory to use DynamoDB for session state.
• Register specialist agents and their MCP tool schemas in the AgentCore Gateway.

1. Configure networking, - Establish an AWS Transit Gateway and Site-to-Site VPN tunnel to on-premises systems.

• Ensure TLS termination and field-level masking in the Lambda functions that mediate tool calls.

1. Enable observability, - Turn on Grafana’s diversity sampler (15-minute interval).

• Activate full-text search in Grafana Cloud Logs.
• Integrate the Knowledge Graph with your agents to surface service-level context automatically.

When to Use What

• Use AWS Bedrock AgentCore when you need tight integration with AWS services, role-based access control stored in DynamoDB, and secure VPN connectivity to on-premises telco platforms.
• Choose the CNCF identity-centric model for platform-wide security governance that enforces reach and capability via declarative policies, especially in heterogeneous, multi-cloud environments.
• Deploy Grafana’s diversity sampling when you want higher information density without writing custom sampling logic, benefiting low-volume services that might otherwise be ignored.
• Activate Grafana full-text search when AI agents must execute large numbers of log queries quickly, as it can cut log-search volume by up to 90 %.
• Combine Agent2Agent delegation with the Knowledge Graph when a request spans multiple domains and you need agents to collaborate while preserving verified identity and capability checks.
• Prefer service-mesh reach enforcement for preventing unauthorized network connections at the edge, reducing the risk of drift in agent connectivity.

Practical Takeaways

• Deploy Amazon Bedrock AgentCore to orchestrate cross-system diagnostics, letting a single AI-driven workflow pull interface logs, query BSS APIs, and consult internal policy stores as U Mobile did for data-add-on failures.
• Design your agent platform with an identity-centric control model that scopes credentials per workflow, preventing the incremental, invisible authority creep highlighted by CNCF’s analysis of the boundary problem.
• Treat every tool added to an autonomous agent as a permanent edge in the permission graph; enforce explicit revocation policies to avoid the drift described by William Rizzo and Francesco Beltramini.
• Leverage Grafana Assistant Watchers as always-on agents that surface changes not captured by static alerts, mirroring Grafana Labs’ push toward autonomous operations with AI-driven heavy-lifting.
• Combine Assistant Investigations with Slack or the Grafana Cloud MCP server to launch deeper incident analyses automatically from alerts, as demonstrated in the ObservabilityCON 2026 announcements.
• Use service-mesh reach enforcement to lock down network paths for agents, reducing the risk of unauthorized connections that can emerge when tools accumulate unchecked.
• When scaling agentic workflows, integrate knowledge-graph enrichment to verify that each step aligns with verified identity and capability checks, ensuring the platform respects the boundaries CNCF warns about.
• Monitor the operational latency of agent-driven ticket resolution against traditional manual processes to quantify efficiency gains, following U Mobile’s focus on reducing subscriber wait times.

Caveats and What to Verify

• Check the security posture of any credential delegation that persists beyond its original demo or sprint, as CNCF notes such drift can remain unnoticed for weeks.
• Verify that Grafana Assistant’s AI features have been benchmarked in your specific stack; the announcements do not provide performance numbers.
• Benchmark the end-to-end latency of Bedrock AgentCore integrations against your existing automation tools to ensure the promised lean operations materialize.
• Confirm that service-mesh policies are consistently enforced across all deployment environments, since boundary erosion can occur silently when tools are added.

Sources

• How U Mobile built agentic telco operations with Amazon Bedrock AgentCore (AWS, Wed, 04 Nov 2026)
• The boundary problem in agentic AI is a platform problem (CNCF, Thu, 29 Oct 2026)
• ObservabilityCON 2026: A guide to all the announcements from Grafana Labs (Grafana Labs, Tue, 20 Oct 2026)