This feature request is a small-ish one, but you'd be surprised how many users have been asking for it in recent times :)
Title says it all, our users love AI Advisor so much that they want to make it their landing page, so here it is !

How can I switch my landing page to AI Advisor ?

First head out to your user profile, on the upper right corner of Kentik Portal

Once there, find the Landing Page setting as shown below

And you're done ! 

Hint: you can always go back to your landing page by clicking the upper left Kentik Logo 

What more can I do ?

Bulk-setting the landing page for multiple users in one go

If you go to the Settings > Users you'll notice you can select multiple users, it will make a bulk edit floater open at the bottom of the screen.
If you are an Admin user, you'll then be able to modify a variety of user attributes in bulk.

Role-Sets & the Landing Page

If you are an avid RBAC (Role Based Access Control) admin user, you may already have assigned users to Role-Sets: these objects are groups of RBAC Roles that can be assigned to users.
One of the things Role-Sets also allow you to do is let you configure a single Landing Page. Every user under this Role-Set will have their landing page follow this configuration.
We have made sure to add AI Advisor to the configuration options of these Role-Sets.

Static IPs Are Here for Global Agents!

We are thrilled to announce that Static IP support is officially live for Kentik Synthetics Global Agents!

Managing network access, firewalls, and allowlists just got a whole lot easier. If your testing relies on fixed source IPs to get past strict firewall rules or internal access control lists (ACLs), this update is designed specifically for you.

What’s New?

• Filter by Static IP: Effortlessly search and filter the Global Agents list to isolate agents configured with static IP addresses.

• Agent Details View: Instantly view assigned static IP addresses directly within the Agent Details panel for fast verification and allowlist configuration.

• Streamlined Test Creation: Select agents with confidence! You can now filter for static IP agents directly within the Test Creation workflow, ensuring your synthetic tests run smoothly through locked-down gateways.

Why You’ll Love It

No more guessing which agent IP to put on your allowlist or dealing with broken test runs due to unexpected IP shifts. With static IPs, you gain predictable source addresses, simplified perimeter security management, and seamless testing against protected endpoints and private services.

In a follow up release, you will be able to retrieve the list of global agent static IPs via the API.

Ready to streamline your agent management? Head over to Synthetics > Agents to check out the new filters today!

A steady portion of our Kentik AI Advisor work happens behind the scenes which main goal is to make it both safer and more transparent for users to feel confident when they use it.
When it comes to AI, we strongly believe that security, safety and transparency are key features, even though they're never listed as such and hardens the trust that our users place in Kentik, as well as provide the sound guardrails required for adoption to keep growing.

Today's release is about another one of these focused runs, it is about our engineering team adding guardrails around AI Advisor's Custom Network Context - read on!

AI is Magic. Sometimes too much.

As detailed in this previous post about Kentik's AI Runbooks, both the Custom Network Context (aka CNC) and Runbooks deeply affect AI Advisor's reasoning.
Imagine Kentik users whose workflow could rely on a very specific prompt, which they'd for example routinely enter every morning with their first coffee - say What's the status of my edge routers this morning ?

In this example, imagine that the list of Edge Routers is documented in their company's Custom Network Context. (which is one of the most common usages of CNC, by the way...)
Also a reasonable hypothesis: users who rely on this mapping ignore that it has been configured via CNC by a benevolent coworker.

What the above implies is the following sum of safety features:

• provide ways to track any AI related configuration change (in this case Custom Network Context)
• allow users to determine who made the change and when
• allow the security team to be able to research modifications on such configuration objects, even if they are not users of AI capabilities
• allow users to rollback such changes if it turns out that their effect on AI Advisor answers negatively impacts its answers

This is what today's feature is all about !

Side note: versioning and audit logging was already available for Runbooks, we extended them and perfected them for CNC.

Updated Custom Network Context Interface

Let's head to Company Settings > Kentik AI > Custom Network Context.
First off, we gave the default empty state a bit of a facelift, you know - while at it...

For those out there with an already populated Custom Network Context, here's what it looks like now: a right-side drawer contains every previous version with:

• Date, Author and Summary metadata attached to it
• The ability to load it in the main center section, from where the user will be able to
  • Inspect the Diff with the previous version
  • Trigger a Roll back to said version

Selecting a previous version, and then switching to Diff display mode:

Custom Network Context & Audit Log

While working on AI Safety measures for Custom Network Context, we also added support for Audit Log: with any modification on the CNC (Create, Edit, Delete), an Audit Log line is now generated, and visible in the usual Company Settings > Audit Log as displayed in the screenshot below.

Every network operations team has a "tribal knowledge" problem. When a critical alert fires at 2am, the outcome can depend too much on who responds — who has seen this problem before, who remembers that one strange configuration issue from six months ago, or who knows that when one signal looks normal, the next thing you should really be checking is somewhere else entirely.

Runbooks have always been the answer in theory, allowing organizations to codify that knowledge and those best practices into a repeatable checklist that can be applied consistently across the team irregardless of how good of network and infrastructure engineers they are - they used to be called NOC procedures. 

If only it were quite that simple.

In practice, runbooks tend to be partially maintained notes scattered across Confluence, Slack threads, old tickets, and sleeping brains. And even when a good runbook does exist, it is usually disconnected from the tools where the investigation is actually taking place — so you're context-switching between your observability platform and a document, manually translating "check the BGP neighbor state" into the right query, on the right device, for the right point in time.

Let's look at how AI Advisor natively includes the concept of Runbooks and how we cranked it up a notch in this release!

AI Advisor Runbooks in a nutshell

Runbooks: TL;DR

If you've been using AI Advisor for a while, you may already know that AI Advisor has a native Runbook capability designed to solve for this.
You can write, in natural (wiki-style markdown) language, specific step-by-step instructions for how you want AI Advisor to investigate a particular situation, including what to look at, what certain results mean, and what it should investigate next. 

You can either manage them in Org Settings > Kentik AI > Runbooks

...or ask AI Advisor directly

Composing with Runbooks

Here are a few cool things you can do with Runbooks - go ahead and try them

• Let AI Advisor select the right Runbook for you. Runbooks can be dynamically invoked by AI Advisor based on the context of a user's prompt, so you don't always need to explicitly call one by name. AI Advisor will also expose if it is selecting and using a rubook for an investigation.
• Run a Runbook with variable arguments. If the first lines of a Runbook define required variables, AI Advisor will ask the user to provide those inputs before execution.
  Example: Run the Peering Vetting Procedure for AS12322, where Peering Vetting Procedure is the runbook andAS12322 is passed in as the argument.
• Run Runbooks on a schedule. A Runbook can be executed at a defined frequency using Org Settings > Report Subscriptions with the AI Advisor report type, with the resulting output attached to an email as a PDF.
• Trigger Runbooks from alerts. In the near future, Runbooks will be able to map directly to Alert Policies and automatically execute as an Auto-Investigation whenever the associated alert fires. This capability is currently in Early Access with select customers and will be available more broadly soon.

Runbooks vs Custom Network Context

Now some of you may wonder what's the difference between Runbooks and the Custom Network Context that is also part of AI Advisor. To understand that, ket's look at the concept of AI Context and how it works in general. 

AI Advisor leverages incremental context within a session: this attached context is a consumable budget - it is handed over to the LLM with each prompt to help it answer the most recent question and each turn/response appends to the context, consuming budget: it is therefore a finite quantity and precious resource 

A fresh AI Advisor session launches with the default System Prompt that's common to every customer, to which we append the Custom Network Context (CNC) on the fly. This is specific information you or your organization has provided to AI Advisor that matters for understanding your network.

This is why CNC is best used for general directives and metadata that apply broadly to the entire infrastructure, because it's your default context spend.

If are familiar with Claude, Custom Network Context is basically your claude.md.

Realistically, you cannot attach every single task-specific procedure your NOC has in the CNC because of the risk of eating your entire context budget the second AI Advisor instantiates. For that, we we created Runbooks.

Runbooks leverage dynamic linking: AI Advisor fires a Runbook tool with every turn, which looks up similarities between the ongoing prompt and all of the Runbook's Title and Description (do make sure these are self-explanatory). When a match is found, the Runbook is appended to the session's AI Context, only consuming from the budget when a match is found.

Again, if you are fluent with Claude, a good way to reason about AI Runbooks in Kentik is the parallel with Claude Skills.
 
As explained, both technically and conceptually behave the same:

• Runbooks are task-specific, describe complex and multi-steps workflows (troubleshooting, analyzing, auditing, planning...)
• Runbooks are discovered via metadata (title, descriptions) and loaded only when Claude recognizes a relevant task.

Runbooks & AI Safety

Modifying Runbooks (also valid for CNC), may make AI Advisor start giving different answers overnight to users that were use to getting consistent answers from the same prompts day after day.

As a first principle, Kentik strives to provide the necessary guardrails for the entire company to use AI Safely and Transparently, which implies the following features that come for free with Runbooks:

• Any change (or creation, deletion...) on a Runbook is logged in our Audit Log facility
• Any time AI Advisor dynamically summons a Runbook, it will
  • explicitly mention it in its reasoning
  • let the user view the runbook as part of the process
• Any change in an AI Runbook populates a history, with a view to track changes across time and the ability to revert them

Building on Runbooks

Cranking it up a notch

Now that you know everything there is to know about Runbooks, a problem still stands: you can't foresee every situation in advance, and not every troubleshooting process is already documented well enough to turn into a runbook.

In fact, something we've heard from customers is that one of the useful parts of working with AI Advisor is the ability to prod and poke at an investigation — telling it to look somewhere else, providing additional context, correcting an assumption, or guiding it toward the signals you know matter in your network. 

Here's the beauty of it all: over the course of a fruitful investigation, you've effectively taught AI Advisor how you would troubleshoot that particular problem.
...and now you're telling me I need to open an extra tab, and tediously copy/past every single prompt I've entered during that session into a newly created Runbook ?  Color me disappointed!

Try a prompt like this and AI Advisor will have your back!
"- Turn this session into a Runbook
 - use this title: 'Peering Request Assessment Procedure'
 - use the following Description: "Standard procedure our Peering Managers use to evaluate peering requests from an ASN"

... and AI Advisor will create said runbook for you to keep hacking on.

You didn't give it a name or a description? AI Advisor will figure it out for you based on the content of your session.

Lastlt -- useful advice for the social Runbook writer

• Your NOC team most likely has existing wiki-based or google docs-based procedures.
  Why don't you just pick a couple of them, copy paste them into Runbooks and try them on for size? You'd be amazed how little tweaking these actually need!
• AI is a muscle: build habit around always turning a fruitful AI Advisor session into a runbook.
  
  

Today we're releasing one of AI Advisor's first Write features: a feature that allows it to create objects in your Kentik Portal configuration.

When AI Advisor launched, its initial scope was to help network operators understand and gain insights on their network data faster, whether during a routine investigation or planning exercise or troubleshooting a critical network outage. It was intentionally limited in scope to reading network data, with no ability to make changes. Today marks the first release of a new family of AI Advisor capabilities to help you configure Kentik itself and accelerate onboarding.

Let's take a look at it!

How does it work ?

Let's just ask AI Advisor, shall we?

So all we have to do is prompt AI Advisor to create a site by submitting its main attributes – to double-check which attributes we can set at creation time, let's just ask it again.

Starting with a simple example, note how it will always ask for permission to create, edit, or delete any object in Kentik Portal via a Human in the Loop (HITL) prompt.

What about batch creating sites?

While creating Sites with AI Advisor  in Kentik Portal is neat, what we really want it to do is speed up onboarding (i.e. to create multiple sites in one go).

Good news: AI Advisor can do that!

All we have to do is submit the content of a CSV file that has a row for each site. Here's an example with three sites and a header row that names the fields:

"site name","address_street","address_zipcode","address_country_2_letter","address_region","site_type","site_market","peeringdb_fac"

"[test] CDG Telehouse 2","137 boulevard Voltaire","75011","FR","Île de France","Connectivity","test_site_market","53"

"[test] CDG Equinix PA3","114 rue Ambroise Croizat","93200","FR","Île de France","Connectivity","test_site_market","717"

"[test] LYS Free Pro Lyon Rock","60 Avenue Rockfeller","69008","FR","Rhone Alpes","Connectivity","test_site_market","6976"

This results in the successful creation of three sites, with a single HITL confirmation prompt to confirm.

Taking site creation to the next level: Combining AI Advisor tools

Let's imagine we have all our sites registered in PeeringDB as Facilities. The good news is that AI Advisor can access a tool (to be announced in a separate article) with access to the entire up-to-date PeeringDB data.

So we can ask questions such as:

...and follow up with a request to create them in Kentik.

And voila!

Customers love to talk to us about AI traffic. It's not surprising: generative AI applications like ChatGPT, Claude, and Gemini are not-so-secretly reshaping your network’s bandwidth and traffic dynamics. And it has been frustratingly common for AI traffic to get dumped into generic "unclassified" buckets, making basic capacity planning and performance optimization an uphill battle. That's why we’re thrilled to announce AI Platforms as a dedicated category within Kentik’s OTT Service Tracking workflow! Kentik now identifies and classifies traffic from 35+ top generative AI services across 28 providers—including OpenAI, Anthropic, Google, Microsoft, Meta, and Perplexity—giving you granular, real-time visibility into the exact AI workloads crossing your network.

Classifying AI Platforms and Services

By extending our True Origin engine and intelligent classification to the AI ecosystem, you can now track top AI services and providers by bitrates across every connectivity type (transit, interconnect, peering, embedded cache, etc.), drill deep into flow data via Data Explorer, and capacity plan before edge bottlenecks happen.

• Visibility Across Services and Providers: In the OTT Service Tracking workflow, you can pinpoint top AI platforms and providers, compare traffic bitrates, delivery methods, and inbound delivery paths.
• Granular Deep-Dives in Data Explorer: In Data Explorer, you can slice flow data by OTT Service Category = AI Platforms, group by service/provider, and evaluate average, 95th-percentile, or peak traffic across specific interfaces, source CDNs, and ASNs.
• Ask Questions via AI Advisor: Ask AI Advisor which AI services grew fastest this month or perform delivery path analysis based on a specific provider.

Check out our announcement blog post for a further deep dive into this new capability. 

If you're an existing customer of Service Provider Analytics, log in to the Kentik portal, navigate to Service Provider > OTT Service Tracking, and select the AI Platforms category to explore your live data today.

We are thrilled to drop a powerful batch of pre-configured Alert Policy Templates designed to level up your network defense, compliance posture, and threat visibility in a flash! Whether you are defending high-capacity service provider backbones, managing complex enterprise environments, or squashing aggressive DDoS vectors, we've got you covered.

Here is everything you need to know about what’s new, why it matters, and how you can tune these shiny new templates to fit your environment like a glove!

⚡ What’s New?

We’ve added 10 brand-new out-of-the-box policy templates targeting high-impact security risks, advanced carpet bombing tactics, and specialized outbound threats:

🛡️ Outbound Security & DDoS Vectors (Built for Service Providers & Complex Enterprise Networks)

Outbound threats are notoriously tricky for large-scale environments. Unmonitored outbound floods can quickly degrade upstream peering links, harm your IP reputation, or lead to costly transit overages. We’ve added dedicated templates specifically engineered for these topologies:

• DDoS: Outbound Volumetric UDP Flood
  Catches internal source IPs or interface blocks generating abnormal outbound UDP traffic volumes. Crucial for service providers to spot compromised subscriber hosts or internal systems participating in outbound reflection/DDoS attacks before they disrupt transit capacity.
• DDoS: Outbound TCP SYN Flood
  Detects sudden spikes in outbound TCP packets with only the SYN flag set originating from your internal IP space. Protects your brand reputation by catching compromised hosts launching outbound SYN floods.
• Security: Internal Vertical IP Scanning
  Spots lateral movement and reconnaissance across complex networks by alerting when a single internal source IP attempts to sweep across an unusually high number of unique destination IPs.
• Security: Threat Feed Compromised Hosts
  Flags internal network assets actively communicating with external threat infrastructure mapped directly against Spamhaus Botnet C&C nodes and malicious hosts.

🌐 Advanced Carpet Bombing Defense

Modern DDoS attacks don't always target a single IP with massive traffic—they scatter traffic across whole subnets to bypass traditional single-target thresholds. These templates give you multi-layered coverage against distributed attacks:

• DDoS: Carpet Bombing CIDR Aggregation
  Identifies horizontal carpet bombing attacks spread across broad subnets, aggregating volumetric anomalies at the /24 routing prefix level.
• DDoS: Carpet Bombing Port Fragmentation
  Detects fragmented, high-intensity stateless traffic (UDP, ICMP, reflection vectors) aimed at a wide array of destination IPs across a single target service port.
• DDoS: Carpet Bombing Interface Impact
  Acts as an essential safety net by tracking traffic anomalies distributed across an entire downstream customer or internal interface block.

🔒 Geo-Compliance & Sanction Monitoring

• Security: Embargoed Country Traffic (Tier 1)
  Monitors bidirectional traffic touching comprehensively embargoed nations and disputed territories to immediately flag high-risk compliance violations.
• Security: Sanctioned Country Traffic (Tier 2) & Regime-Targeted Traffic (Tier 3)
  Provides granular compliance tracking for high-risk, sanctioned, or UN-embargoed jurisdictions across secondary tiers.

🎯 Why This Matters to You

• Instant Protection, Zero Setup Hassle: No need to build complex flow filters or mathematical baseline models from scratch. These templates come with industry-tested baselines and static thresholds.
• Protect Your Brand & Transit Capacity: For Service Providers and Enterprise Edge networks, catching outbound malicious floods ensures your IP space stays off global blocklists and preserves upstream provider SLAs.
• Defend Against Stealthy Distributed DDoS: By aggregating traffic across /24 subnets, service ports, and entire interface blocks, you can stop carpet bombing campaigns that traditionally slip under single-IP alert radars.
• Automated Regulatory Compliance: Maintain strict, automated compliance oversight against international sanction lists without setting up manual geo-fencing rules.

🛠️ How to Enable & Tune Policies for Your Network

By default, these templates are imported in a disabled state so you can safely review and tune them before going live.

Step 1: Enable the Template

1. Head over to Alerting > Manage Alert Policies > Alert Policy Templates in the Kentik portal.
2. Search for the template name (e.g., DDoS: Outbound Volumetric UDP Flood or DDoS: Carpet Bombing CIDR Aggregation).
3. Then click the “Create policy from template” icon to add the alert policy to your account.

Step 2: Tailor & Tune to Your Environment

Every network has its own unique baseline. Here is how you can make these templates fit seamlessly:

Adjust Static & Baseline Thresholds:

• For high-volume service provider backbones, you can scale up static packet/bit thresholds to match your transit capacities.
• For tight enterprise environments, lower the required percentage jump above historical baselines.

Refine Traffic Filters & Boundaries:

• Ensure your network boundary tags (e.g., internal vs external, or inside vs outside) are accurately defined so outbound flood and lateral scanning policies evaluate traffic correctly.

Attach Notifications & Automated Mitigations:

• Link your team's preferred notification channels (Slack, PagerDuty, Webhooks, or Email) under the policy's Notifications section.
• For DDoS templates, attach Mitigation Associations if you want Kentik Protect to automatically trigger RTBH, BGP Flowspec, or third-party mitigation platforms upon activation

Deploying a fleet of Universal Agents should be fast to automate and safe to hand off, and provisioning tokens make it both. Deploying Universal Agents at scale should be easy to automate and safe to delegate. Provisioning tokens make both possible.

Today we're introducing provisioning tokens for the Universal Agent, a controlled way to register agents through the API. Each token is scoped to a single organization, capped to the number of agents you plan to deploy, and set to expire on a schedule you choose. This lets partner teams and systems integrators deploy agents without portal access or long-lived credentials. Agents register themselves on first boot, and you choose whether they come online automatically or wait for an admin to authorize them.

Bring a whole fleet online without the portal: Create one token, deploy your agents, and let them register and authorize themselves over the API.

• Let partners deploy into a customer org safely: Each token belongs to a single organization and a short time window, so you decide how many agents can join and for how long.
• Script the path from install to running capabilities: Register an agent, authorize it, and turn on capabilities like Flow Proxy and SNMP/ST in one automated run.
• Keep tokens low risk: Set a usage count, give the token a short expiry, and revoke it once your agents are in.

What's changed in the install flow

The Deploy Agent command in Settings » Universal Agents now bundles your company ID and a provisioning token. When the agent starts, it reads those values (K_COMPANY_ID and K_REGISTER_PROVISIONING_TOKEN) and registers on its own. With an auto-approve token, the agent comes online with a status of Up and nobody has to open the portal to authorize it. If you prefer a checkpoint, an approval-required token leaves each agent Not Authorized until an admin clicks Authorize.

What's new

Provisioning tokens are short-lived, organization-scoped credentials you create through the kagent API, or with the generate-provisioning-token.sh helper in the kagent-helm repository. Each token specifies how many agents can register and when the token expires, allowing you to generate credentials just before deployment instead of storing a long-lived secret.

The same token-based flow works whether you install on standalone Linux or Docker or deploy with the kagent-helm chart on Kubernetes. In every case, the agent picks up the token from an environment variable and registers itself, and you can update the token value later without reinstalling the agent.

Once an agent is registered, you can finish onboarding without the portal. Authorize the agent, enable capabilities by name (kproxy, ktraffic, ranger, kdns), and apply runtime configuration, all through the kagent API. US deployments use grpc.api.kentik.com and EU deployments use grpc.api.kentik.eu.

Why it matters

For a proof of value, this removes a major source of friction. A partner or system integrator can deploy agents into a prospect's organization and have them register and start reporting, without waiting for portal access to be granted. The onboarding steps that used to be manual are now scriptable, so the same process covers one Docker host or a Helm-managed fleet.

You also keep control of exposure. Because a token is tied to one organization, capped by a usage count, and set to expire on a schedule you choose, an agent can only ever join the organization that issued its token. There is no way to move a registered agent from one organization into another, so identities stay clean when you stage in your own org before deploying to a customer's.

Get started

Ready to onboard agents without the portal bottleneck? Open Settings » Universal Agents » Deploy Agent to copy an install command that already includes your company ID and a provisioning token. To create tokens inside an automation script, call the kagent provisioning-tokens API directly, or use the generate-provisioning-token.sh helper in the kagent-helm chart if you deploy on Kubernetes. The Universal Agents guide in our Knowledge Base has the full walkthrough for registration, authorization, and capability configuration.

Since we released our AI Advisor agent, we've been noticing a steady and consistent increase of its usage throughout our user base. When discussing with our customers to understand how they use it, we usually notice a couple things:

• More often than not, a few champions within the company use AI Advisor in a rather advanced fashion, chaining prompts that leverage different data-sets;
• The rest of the users mostly use AI Advisor in a one-shot pattern of question, answer, then move on.

Some of our key conclusions are

1. AI (Advisor) is a muscle: unless you keep exercising it and attempt new prompts, it is hard for users to wrap their heads around what AI Advisor can do that they haven't yet discovered
2. Emulation is key to adoption: constant exposure to successful/fruitful AI Advisor sessions is a big factor for internal adoption, and helps users develop a sense of the "field of the possibles" in terms of its usage
3. Sometimes (often) you need to share things with non Kentik users: Whether attaching investigation context for post-incident reporting, or sharing a network planning exercise with others in the organization, we see many needs to be able to create a sharable, portable artifact that is better than "copy & paste."

For that reason, we're adding a couple features for users to share sessions recorded as PDF.

Export AI Advisor chat sessions as PDF

Title says it all: with this function, users can now download any chat session, current or past as a PDF file and share it with other users.

When using AI Advisor in the chat popover mode, you'll notice these series of icons in the title bar, one of them will download the current chat session as a PDF

When using AI Advisor in Full screen mode, 

In both cases, a green toast will let you know when your export is ready with a link to save it as a PDF

Cranking it up a notch: Scheduled Export Subscriptions

This is when things get interesting: building on this foundation, we added a capability for AI Advisor to run offline, on a schedule.
First off head to Company Settings > Reports Subscriptions

AI Advisor

which will give you access to configuration options for your scheduled AI Advisor Report

• Naming the PDF file exported
• Email recipients to configure it for (TO, CC, BCC)
• Scheduling options (daily, weekly, monthly, last day of the month)
• A field for the prompt you want AI Advisor to run and export as a PDF

Here's an idea of how we've seen this feature being used: 

1. Schedule a report to be run every Monday morning and set to your inbox
2. Configure the report to rely on the following prompt: 

"Give me a summary of anything critical that has happened over the past weekend, only display a table of summary action items, each one with their level of priority"

Here's an extract of a sample report you could receive in your inbox after a busy weekend

...another example, derived from this one:

• Network Config Changes made over the weekend can be seen as riskier because of only On-Call staff being available to review them
• Sometimes these changes are made in emergency to temporarily solve a customer issue and need to be reviewed on Monday when all the engineering staff is present
• Kentik's NMS offering now by default includes Config Back and Diff'ing for devices enrolled in it, meaning AI Advisor knows about any change made at anytime, by anyone.

What about getting a weekend config change summary on Monday delivered to the Engineering team's inbox to review ?

A scheduled prompt like this one would do the trick

"Show me a summary of all device config changes that have happened over the weekend on all devices, including who made the change

Which would yield a PDF report similar to the one below

How do I make the best use of AI Advisor Scheduled Reports?

This feature really shines when used in conjunction with our AI Runbooks (see the AI Advisor release announcement): with Runbooks, our users can instruct AI Advisor to follow a specific procedure, featuring

• Natural language instructions that mirror your own operating procedures
• A step by step detailed reasoning containing what data-sets to pull into an investigation: traffic analysis queries, NMS metrics, Syslog and Trap event entries, on-demand synthetic tests, configuration backups diffs and even run show commands
• Title and Description metadata, leveraged by AI Advisor to know when to dynamically summon them

Concretely, if you're a Claude Code user, you can think of these as Claude Skills.

These capabilities now can get leveraged offline with AI Advisor Subscription Reports with prompts such as:

Execute the "NTP and Syslog audit" Runbook

In that example, AI Advisor would fetch the Runbook and execute the instructions in it, turning it into a powerful audit tool that will be summoned regularly, sending your Engineering/Operations team a report with actions for them to review and apply.

You'll notice a name change in your Universal Agent settings: Flow Proxy is now Flow Proxy (Edge Processing). The engine, configuration, and behavior are identical. Nothing breaks, nothing migrates. We're updating the name because Flow Proxy is growing into a collection of modes, and we want the labels to be clear about what each one does.

• Nothing changes operationally. Your existing Flow Proxy capability continues to decode, enrich, and sample flow at the edge exactly as it does today.
• The name tells you what it does. "Edge Processing" makes it explicit that this mode handles decoding and enrichment locally before forwarding to Kentik.
• A new collection mode is coming alongside it. Flow Proxy (Forwarding), a lightweight forwarding engine, is entering limited release for select customers. The name change keeps the two engines distinct.

What's new?

Flow Proxy (Edge Processing) is the engine you already run. It decodes, enriches (SNMP/rDNS), and samples flow at the edge before forwarding to Kentik. Same binary, same config, same behavior. The label in the Universal Agent UI now reads "Flow Proxy (Edge Processing)" instead of "Flow Proxy."

Flow Proxy (Forwarding) is a new, separate capability entering limited release. It captures raw flow and ships it to Kentik with minimal local processing, using roughly 10x less compute than edge decoding. SaaS-side enrichment only available in Edge Processing today is in active development for Forwarding Mode to complement it. This is available to select customers today; broader availability will follow.

What this means for Flow Proxy users

If you run Flow Proxy today, here's what to expect going forward:

1. Now: You'll see the updated name in your Universal Agent settings. No action required.
2. Soon: Flow Proxy (Forwarding) becomes available more broadly as a separate capability for select customers who want lightweight collection without edge enrichment.
3. Next: We're building a unified Flow Proxy experience that combines both engines into a single capability with a mode selector. Instead of managing two separate capabilities on your agents, you'll pick a delivery mode from one place. Fewer capabilities to configure, fewer to monitor, and a clear path to switch between engines as your needs change.

Here is an early view into a prototype we've been working on for mode selection (this is early work and subject to change):

If you run Kproxy (legacy) as a standalone agent today you should still be planning to migrate to a Universal Agent Flow Proxy by the May 1, 2027 deprecation date as previously announced to avoid running unmaintained agents and to benefit from our latest innovations. 

No action required

No action is needed. The name update is already live in the Universal Agent for all customers. We will be posting a follow up announcement once the unified Flow Proxy experience is live.