{"slug": "meet-mylo-an-ai-native-way-to-work-with-calico", "title": "Meet Mylo: An AI-native way to work with Calico", "summary": "Tigera introduced Mylo, an AI-native expert for Calico delivered through the Calico MCP Server, which enables AI agents to troubleshoot Kubernetes networking issues by tracing paths and identifying blocking policies in minutes. Mylo packages a decade of Calico expertise into semantic tools and skills, with the flagship diagnose_connectivity tool returning ordered network path analysis and suggested fixes.", "body_md": "*A library of Calico tools and skills — delivered through the Calico MCP Server*\n\n## What if your hardest network question took ten minutes instead of ten days?\n\nAnyone who has operated Kubernetes networking at scale knows the shape of a bad day. A request that should succeed is quietly failing. The application team swears nothing changed. Somewhere across a stack of tiers, selectors, and policies, some written last week and some inherited from an engineer who left two years ago, a rule is denying the traffic. Finding it means reading YAML, cross-referencing flow logs, and reconstructing the policy evaluation order in your head. For a genuinely knotty case, that work can stretch across days and pull in more than one team before anyone gets to the bottom of it.\n\nI think that day is about to get a lot shorter. Today we’re introducing Mylo, an expert for Calico that works inside the AI tools your teams already use. Ask Mylo why a pod can’t reach a service, and it traces the path, points to the exact policy and rule doing the blocking, and explains why in plain language, in about the time it took you to read this paragraph. Mylo is the library of tools and skills that makes Tigera’s Calico expertise usable by an agent; the Calico MCP Server is how we deliver it. The rest of this post covers what it is, how we designed it, and why we made the choices we did.\n\n## What Mylo really is: A decade of Calico expertise, as tools and skills\n\nBefore getting into how Mylo is delivered, it’s worth being clear about what it actually is, because the delivery mechanism is the least interesting part of the story. Mylo is the Calico and Kubernetes networking knowledge Tigera has accumulated over ten years, turned into something an AI agent can use directly. It comes as two layers, and those two layers, not the plumbing that delivers them, are where the value sits.\n\nThe first is a small set of tools. These aren’t thin wrappers over CLI commands; they’re semantic. The flagship, diagnose_connectivity, doesn’t hand back a raw dump for the model to interpret. It returns an ordered, opinionated read of the network path, down to the specific rule that allows or denies, with a suggested fix. The expertise lives in the tool; the reasoning stays with the agent.\n\nThe second layer, and the one that compounds over time, is skills: higher-level workflows that string those tools into the procedures an expert would actually follow. Troubleshooting a connectivity failure, triaging an incident, reviewing a policy before it ships: each is a multi-step reasoning pattern, and a skill encodes it, so the agent diagnoses, then traces the policy chain, then checks recent denials, then explains the offending rule, in that order. This is the part I’d point to first. A decade of Tigera’s own troubleshooting expertise, the kind that usually lives in the heads of a handful of senior engineers, is captured here as structured guidance an agent can carry out, rather than a static runbook a human has to follow.\n\n## Why an MCP server, and why now\n\nTwo things are true about the platform and security engineers who run Calico today. The first is that they are already deep in agentic workflows. In nearly every conversation we’ve had over the past few months, teams weren’t debating whether to adopt an AI assistant. They had already standardized on one, whether that’s a coding assistant in the IDE or an agent in the terminal, and connected it to a set of MCP servers for their metrics, logs, tickets, and source control. The Model Context Protocol has quietly become the way infrastructure tools present themselves to agents.\n\nThe second is that Calico holds a lot of the context those engineers need, and it isn’t always easy to reach. The policy model is powerful because it’s expressive, with tiers, global and namespaced policies, selectors, and ordered evaluation. That same expressiveness, however, is what makes a thorny connectivity problem hard to reason about when you’re under pressure. Flow logs hold the answer to “why was this blocked,” but writing the query to surface it is a skill of its own.\n\nDelivering that expertise over MCP sits naturally between those two facts. Rather than build yet another chat interface and ask teams to approve a new AI product with access to production, we expose Mylo’s tools so any MCP-compatible agent can call them. Your engineers keep the front-end they’ve already vetted, and Calico becomes the intelligence layer underneath it. MCP is the delivery mechanism, not the substance, but it’s the right one, because it puts Calico’s knowledge directly into the reasoning loop of an agent that is already helping your team get work done. This is a new way to work with the Calico Unified Platform. It doesn’t replace the CLI or the UI.\n\n## Composability: Workflows that weren’t possible before\n\nThe reason this approach matters, beyond the convenience of asking questions in plain English, is composability, and it’s worth reviewing, because a lot of teams are still early in adopting MCP. A tool exposed over MCP is a building block an agent can combine with every other capability it can reach. When Mylo runs alongside the MCP servers a team already uses, the agent can move across all of them in a single line of reasoning, and that unlocks workflows nobody shipped as a feature.\n\nConsider a request like this one: “Find the traffic denied by the policy I shipped this morning, correlate it with the elevated 5xx rate the monitoring tool flagged, and open a ticket with the policy diff to fix it.” Three systems answer that in a single pass. Mylo supplies the Calico half, the expert half, and the team’s existing monitoring and issue-tracking servers supply the rest, with the agent orchestrating the whole thing end to end. The same shape shows up all over an operations workflow. Before a pull request merges, the agent can ask Mylo to simulate the policy change against last week’s flow logs and post the impact summary to the team’s channel. When flow logs show a denied connection from a production service, it can page whoever is on call. None of those are workflows we built, and none of them existed as a product a team could buy.\n\nWhat I find encouraging is that we didn’t have to anticipate any of them. A traditional integration or dashboard can only run the paths its authors designed in advance. Because Mylo exposes a small set of well-designed, semantically clear tools, each team fits it into the operational reality they already have, and some of the most valuable workflows will be ones we never designed for.\n\n## The design philosophy: Restraint\n\nIf one principle shaped Mylo more than any other, it’s restraint. The instinct when you build for an agent is to expose everything, to ship a tool for every API method and every CLI subcommand and let the model sort it out. In our view that instinct is a mistake, and we’ve worked hard to resist it.\n\nMore tools is not better. Every tool you hand an agent is a claim on its attention, another chance for it to pick the wrong one, and another line item in the token budget. A server with a hundred thin wrappers around CLI commands doesn’t make an agent smarter. It makes it slower, more expensive, and more likely to wander off. That’s why Mylo’s tools are deliberately few and semantic rather than mechanical, and why the intelligence sits in the tool itself rather than in the model’s attempt to reconstruct it from unstructured output.\n\nWe wrote down the principles we kept returning to, half in earnest and half tongue-in-cheek. A few are worth calling out, because they’re where the harder decisions actually landed. Read-only by default, because the safe posture should never depend on someone remembering to configure it. State, not verdicts, because a good tool should report what is true and let the agent do the reasoning, rather than pre-baking a conclusion that strips away the context the model needs. Selectors, not switches, because tools should accept rich, expressive inputs instead of sprouting a new boolean flag for every situation. And the one we keep at the very bottom as a reminder to ourselves: thou shalt not ship a tool for every API method.\n\nOne more piece of architecture turns that discipline into something trustworthy: the router. Agents are eager to be helpful, and an agent that can’t reach a tool will often shell out instead, quietly running a CLI command to answer a question rather than admitting the question is outside its lane. That’s harmless right up until it isn’t, and for a tool that touches production networking, silent fallback is a trust problem. So Mylo can be invoked explicitly, and when a request comes in, the server tells the agent clearly whether it can actually handle it rather than letting it improvise around the edges. That deterministic guidance, with explicit boundaries, is what earns the confidence of a platform team.\n\n## Built to grow without slowing down\n\nThe natural question about a deliberately focused toolset is whether it can grow in scope without growing unwieldy. I’d argue the architecture is exactly what lets us expand without the usual penalty. Because skills are invoked in context and the router keeps each request scoped to what’s relevant, adding a new capability doesn’t tax the ones already there. A troubleshooting session doesn’t get slower or noisier because we’ve also taught Mylo to help with a migration. Breadth comes from adding well-described skills and the focused tools they lean on, not from piling more surface area onto every interaction. In practice that means the range of what Mylo can do for you keeps growing while the cost of any single interaction stays flat.\n\nWe’re being disciplined about sequencing, and read-only diagnostics and observability come first because that’s where the pull is strongest. The roadmap ahead is broad, though. Policy authoring is a natural next step, generating well-formed Calico policy from a plain description of intent and presenting it for review before anything is applied. We see real appetite for migration assistance, whether that’s moving VMs into Kubernetes, moving from Ingress to the Gateway API, or moving from Istio sidecars to Ambient. Configuration of Calico resources such as load balancers and egress gateways fits the same pattern. And compliance reporting keeps coming up in customer conversations, from summarizing an application’s secured egress destinations to demonstrating that PCI workloads aren’t communicating with non-PCI workloads, the kind of evidence a security team can hand to an auditor. Each of these is a skill and a small set of tools layered onto the same foundation, so we can keep growing what Mylo does for you without disturbing the safe, composable core underneath it.\n\n## Two ways to run it: Live cluster or diagnostics bundle\n\nMylo works against a live cluster, connecting through the same kubeconfig path your engineers already use for kubectl and calicoctl, with no new endpoint exposed. That’s the mode for real-time diagnostics and observability, for asking what is happening in the cluster right now.\n\nIt also works entirely offline, pointed at a Calico diagnostics bundle. This matters more than it first appears. A bundle is portable, shareable, and detached from the live environment, which makes it a good fit for the many settings where a laptop simply cannot reach production: air-gapped estates, tightly controlled prod, or after-the-fact analysis where the state you care about is the one captured at the moment of failure. The same tools and the same skills run against both. An engineer can triage a captured bundle on a plane and run live diagnostics from their desk using the identical workflow. Supporting both was not an afterthought. It’s how we’ve been able to test Mylo so thoroughly, and it’s what lets it meet enterprises where their access model actually sits.\n\n## Read-only by design\n\nFor the teams evaluating Mylo, the first question is almost always about safety, and our answer is deliberately conservative. Mylo is read-only by design. Its tools diagnose, explain, observe, and where they touch policy, generate proposed YAML. They do not apply, update, or delete anything. This holds even when Mylo is handed a cluster-admin kubeconfig, because the read-only boundary is a property of the tools themselves and not something we’re trusting the model to honor. Security teams have appreciated that they can point their own agent at the server and audit for themselves exactly what it can and cannot do.\n\nThe result is a much narrower profile than the interfaces these teams have already approved. Mylo is a typed, structured API with no browser session, no rendered pages, and no standing state to hijack. Access runs through the calling user’s existing Kubernetes RBAC, so if a user can’t list policies in a namespace, neither can Mylo on their behalf. That makes for a far shorter security conversation than approving a net-new AI product, largely because there is no new AI product to approve. The reasoning happens in a front-end the customer already trusts.\n\n## What the internal testing showed\n\nWe didn’t want to announce a promising demo. Before we put Mylo in front of anyone, we ran it against our own library of resolved support cases, real and historically difficult problems where we already knew the answer and how long it had originally taken to reach. It’s a demanding benchmark, because it measures Mylo against outcomes that skilled engineers had already worked hard to produce.\n\nThe results are the reason we’re writing this post. A class of case that historically took on the order of ten days to root-cause, the kind that bounces between teams and keeps escalating, Mylo worked through in roughly ten minutes. Not every case, and never without a person in the loop reading the output and making the call. But the pattern held often enough, across enough cases, that we’re confident this is real and repeatable. Compressing days of investigation into minutes changes what an under-resourced operations team is able to take on.\n\n## Early access, and what we’re seeing\n\nMylo is in early access now with a small group of design partners. They are large, security-conscious organizations, several of them in regulated industries, and all of them already fluent in agentic workflows. We’re keeping the program deliberately tight so we can learn quickly, and we’re bringing participants on in waves rather than opening the gates all at once.\n\nThe early signal has been better than we expected. Participants aren’t just kicking the tires; some are reaching for Mylo daily. One of the more encouraging patterns is teams using it to scope problems they simply couldn’t get their arms around before, such as surveying years of accumulated policy sprawl to find what’s orphaned or duplicated, work that used to mean writing custom tooling nobody had time to build. That read-only, get-the-data-out-of-Calico use case has been the wedge almost everywhere. The fastest path to value is answering “why is this happening” in plain English, and the appetite for it is real.\n\n## The road to GA\n\nEarly access is showing us what enterprise-ready has to mean, and the requirements have been remarkably consistent from one team to the next. On the way to general availability we’re focused on a few things: an in-cluster deployment option for teams that want Mylo owned and run by the platform rather than launched from a laptop; authentication and RBAC that carry each user’s real cluster permissions through to every tool call; tiered access that builds on the read-only foundation with a staged suggest tier, where policy changes are proposed as reviewable diffs and applied only after a human approves; and audit logging that records every tool invocation for the compliance and security teams who, rightly, want the full trail.\n\nNone of that changes the core posture. Mylo starts safe, stays composable, and earns each new capability rather than assuming it. That’s the philosophy that got us here, and it’s the one we intend to keep.\n\nIf you run Calico and your teams are already working with AI agents, we’d love to have you see this early. Mylo is how Calico shows up in that world, and I think it’s going to change what a hard networking day looks like.\n\nIf you’re not a customer yet and would like to learn more about Mylo, [drop us a line here](https://www.tigera.io/contact/).", "url": "https://wpnews.pro/news/meet-mylo-an-ai-native-way-to-work-with-calico", "canonical_source": "https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/", "published_at": "2026-09-03 18:21:50+00:00", "updated_at": "2026-09-03 18:54:12.670454+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "ai-products"], "entities": ["Tigera", "Calico", "Mylo", "Calico MCP Server"], "alternates": {"html": "https://wpnews.pro/news/meet-mylo-an-ai-native-way-to-work-with-calico", "markdown": "https://wpnews.pro/news/meet-mylo-an-ai-native-way-to-work-with-calico.md", "text": "https://wpnews.pro/news/meet-mylo-an-ai-native-way-to-work-with-calico.txt", "jsonld": "https://wpnews.pro/news/meet-mylo-an-ai-native-way-to-work-with-calico.jsonld"}}