Mert

AI agents are being built as if the network is a perfect, low‑latency, lossless abstraction… but it isn’t. And as these systems scale, the real failures won’t come from model quality, but from latency, packet loss, protocol behavior, and the messy reality of distributed systems instead. If we want agents that actually work in production, networking has to become a first‑class design concern again.

The Part of the AI Conversation That’s Missing

As of now, the AI world is tightly focused on bigger models, longer context windows, agent frameworks, orchestration layers, and clever prompting. That’s perfectly fine, all interesting. But none of those things matter if the network underneath can’t reliably deliver data.

AI agents all run across:

• Multi-cloud fabrics

• edge devices

• unpredictable wireless links

• overloaded paths

• real-world latency

And even then, most agent architectures are designed as if the network is a solved problem, but it isn’t and never was.

The Actual Failure Modes Aren’t “AI Issues”, They’re Network Problems

Here are the patterns that continue to show up in modern distributed systems, now amplified by AI workloads:

Latency Amplification

Agents that depend on synchronous calls to remote interference endpoints collapse whenever RTT spikes. A small jump, say 40ms to 120 ms, can turn a responsive agent into a stalled one.

Retry Storms

Agents retry due to their assumption that the service is slow, not the network. Multiply that across dozens of agents, and you get a self-inflicted outage.

Partial observability

Your dashboard can say that everything is green, but your packet capture says otherwise. Retransmits, duplicate ACKs, microbursts, all the concepts that explain behavior, rarely show up in Layer-7-only observability.

Protocol mismatch

HTTP/2 and gRPC work fine until you introduce:

• MTU fragmentation

• middleboxes

• head-of-line blocking

• asymmetric routing

Then your ‘fast’ protocol becomes bottlenecked.

Edge constraints

Everyone wants ‘AI at the edge,’ but nobody talks about:

• limited bandwidth

• inconsistent connectivity

• noisy RF environments

• small computing budgets

Agents can’t reliably count on shipping huge context windows or raw telemetry upstream.

Practical Advice for Anyone Deploying Agents

Observability Has to Go Below Layer 7 Again

Modern observability stacks are great at, logs, traces, and service metrics. But they’re blind to the things that actually break distributed systems, which are:

• MTU issues

What is MTU?

Maximum Transmission Unit (MTU) is the size of the largest protocol data unit that can be communicated in a single network layer transaction. If your AI’s context window data exceeds this without proper fragmentation handling, you see “mysterious” packet loss.

• packet loss
• bufferbloat
• link flaps
• retransmit storms
• NIC queue saturation

If you want agents that behave predictably, you need visibility into the layers where unpredictability thrives.

This doesn’t mean you have to capture full PCAPs everywhere; even lightweight NIC counters and synthetic probes can reveal the truth just as easily.

Why Rust Keeps Showing Up in These Conversations

Rust isn’t just a “fast” language; it has you think like a systems engineer with its core concepts:

• ownership
• memory layout
• buffer lifetimes
• concurrency (without data races)

That mindset is essential whenever you’re building telemetry collectors, edge inference runtimes, protocol parsers, or agent‑side networking components.

Rust gives you the tools to build small, reliable pieces of infrastructure that agents depend on.

Where This Is All Heading

Here’s what I expect to see over the next few years:

• Network‑aware agents will outperform everything else out there.
• Observability will shift down the stack, closer to the packet and NIC levels.
• Hybrid inference (local and remote) will become the default.
• Protocol engineering will matter again, and efficiency will beat sheer force.

The teams that understand networking will create the agents that thrive.

Final Thought

Have you run into an ‘AI problem’ that turned out to be a networking issue in disguise? I’d love to hear your stories (and how you debugged them) in the comments below.

AI agents are being built as if the network is a perfect, low‑latency, lossless abstraction… but it isn’t. And as these systems scale, the real failures won’t come from model quality, but from latency, packet loss, protocol behavior, and the messy reality of distributed systems instead. If we want agents that actually work in production, networking has to become a first‑class design concern again.

The Part of the AI Conversation That’s Missing

As of now, the AI world is tightly focused on bigger models, longer context windows, agent frameworks, orchestration layers, and clever prompting. That’s perfectly fine, all interesting. But none of those things matter if the network underneath can’t reliably deliver data.

AI agents all run across:

• Multi-cloud fabrics

• edge devices

• unpredictable wireless links

• overloaded paths

• real-world latency

And even then, most agent architectures are designed as if the network is a solved problem, but it isn’t and never was.

The Actual Failure Modes Aren’t “AI Issues”, They’re Network Problems

Here are the patterns that continue to show up in modern distributed systems, now amplified by AI workloads:

Latency Amplification

Agents that depend on synchronous calls to remote interference endpoints collapse whenever RTT spikes. A small jump, say 40ms to 120 ms, can turn a responsive agent into a stalled one.

Retry Storms

Agents retry due to their assumption that the service is slow, not the network. Multiply that across dozens of agents, and you get a self-inflicted outage.

Partial observability

Your dashboard can say that everything is green, but your packet capture says otherwise. Retransmits, duplicate ACKs, microbursts, all the concepts that explain behavior, rarely show up in Layer-7-only observability.

Protocol mismatch

HTTP/2 and gRPC work fine until you introduce:

• MTU fragmentation

• middleboxes

• head-of-line blocking

• asymmetric routing

Then your ‘fast’ protocol becomes bottlenecked.

Edge constraints

Everyone wants ‘AI at the edge,’ but nobody talks about:

• limited bandwidth

• inconsistent connectivity

• noisy RF environments

• small computing budgets

Agents can’t reliably count on shipping huge context windows or raw telemetry upstream.

Practical Advice for Anyone Deploying Agents

Observability Has to Go Below Layer 7 Again

Modern observability stacks are great at, logs, traces, and service metrics. But they’re blind to the things that actually break distributed systems, which are:

• MTU issues

What is MTU?

Maximum Transmission Unit (MTU) is the size of the largest protocol data unit that can be communicated in a single network layer transaction. If your AI’s context window data exceeds this without proper fragmentation handling, you see “mysterious” packet loss.

• packet loss
• bufferbloat
• link flaps
• retransmit storms
• NIC queue saturation

If you want agents that behave predictably, you need visibility into the layers where unpredictability thrives.

This doesn’t mean you have to capture full PCAPs everywhere; even lightweight NIC counters and synthetic probes can reveal the truth just as easily.

Why Rust Keeps Showing Up in These Conversations

Rust isn’t just a “fast” language; it has you think like a systems engineer with its core concepts:

• ownership
• memory layout
• buffer lifetimes
• concurrency (without data races)

That mindset is essential whenever you’re building telemetry collectors, edge inference runtimes, protocol parsers, or agent‑side networking components.

Rust gives you the tools to build small, reliable pieces of infrastructure that agents depend on.

Where This Is All Heading

Here’s what I expect to see over the next few years:

• Network‑aware agents will outperform everything else out there.
• Observability will shift down the stack, closer to the packet and NIC levels.
• Hybrid inference (local and remote) will become the default.
• Protocol engineering will matter again, and efficiency will beat sheer force.

The teams that understand networking will create the agents that thrive.

Final Thought

Have you run into an ‘AI problem’ that turned out to be a networking issue in disguise? I’d love to hear your stories (and how you debugged them) in the comments below.

The problem: one webhook per document balloons deploy traffic

When a Sanity editor publishes ten blog posts in a row, the default webhook setup fires ten separate POST requests to your Next.js revalidate endpoint. Each triggers an ISR purge. If you’re on Vercel’s Pro plan, that’s ten function invocations, ten cold starts, and ten separate cache invalidations that race each other. I’ve seen this pattern push deploy times past two minutes on a 200-page site, purely from webhook churn.

The naive solution is to add a 30-second debounce in Sanity’s webhook config. That helps, but it doesn’t solve the core issue: Next.js On-Demand Revalidation expects you to name every path or tag you want to purge. If your blog index depends on all posts, you end up either revalidating /blog once per post (redundant) or writing brittle logic to figure out which paths changed.

Use revalidateTag and a single Sanity webhook

Instead of per-document webhooks, I register one Sanity webhook that POSTs a _type and optional _id payload to a single Next.js route handler. The handler revalidates a tag, not a path. Here’s the setup.

First, the route handler at app/api/revalidate/route.ts:

// app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';
import { parseBody } from 'next-sanity/webhook';

const SANITY_REVALIDATE_SECRET = process.env.SANITY_REVALIDATE_SECRET;

export async function POST(req: NextRequest) {
  const secret = req.nextUrl.searchParams.get('secret');
  if (secret !== SANITY_REVALIDATE_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await parseBody<{ _type: string; _id?: string }>(req);
  if (!body?._type) {
    return NextResponse.json({ message: 'Missing _type' }, { status: 400 });
  }

  const tags = [`sanity:${body._type}`];
  if (body._id) tags.push(`sanity:${body._id}`);

  tags.forEach((tag) => revalidateTag(tag));

  return NextResponse.json({
    revalidated: true,
    tags,
    now: Date.now(),
  });
}

The webhook URL in Sanity Studio’s Manage → Webhooks panel is:

https://yourdomain.com/api/revalidate?secret=YOUR_SECRET

Payload is JSON:

{
  "_type": "{{_type}}",
  "_id": "{{_id}}"
}

Trigger on Create, Update, Delete for all document types.

Tag data fetches by document type, not by path

Now, any Server Component that fetches Sanity data must declare the tag in the fetch options. For a blog index:

// app/blog/page.tsx
import { client } from '@/sanity/client';

export default async function BlogIndexPage() {
  const posts = await client.fetch<Post[]>(
    `*[_type == "post" && !(_id in path("drafts.**"))] | order(publishedAt desc) [0...20] {
      _id, title, slug, publishedAt, "author": author->name
    }`,
    {},
    {
      next: {
        tags: ['sanity:post'],
      },
    }
  );

  return (
    <div>
      {posts.map((p) => (
        <article key={p._id}>
          <h2>{p.title}</h2>
        </article>
      ))}
    </div>
  );
}

When an editor publishes a new post, the webhook fires once, revalidates sanity:post, and Next.js purges every fetch tagged with that label. No per-path logic. No race conditions.

For a single post page, I tag both the type and the ID:

// app/blog/[slug]/page.tsx
import { client } from '@/sanity/client';

export default async function PostPage({ params }: { params: { slug: string } }) {
  const post = await client.fetch<Post>(
    `*[_type == "post" && slug.current == $slug][0] {
      _id, title, body, publishedAt
    }`,
    { slug: params.slug },
    {
      next: {
        tags: ['sanity:post', `sanity:${post._id}`],
      },
    }
  );

  return <article>{post.title}</article>;
}

This ensures that if an editor updates a specific post, only that post’s page and the index purge. Other posts remain cached.

Why this cuts deploy noise by 70%

Before this pattern, my typical 150-page site with 80 blog posts would fire 80+ webhook requests during a bulk publish. Each request took 200–400 ms on cold starts. Total webhook processing time: ~25 seconds. Build queue would back up if multiple editors were publishing concurrently.

After switching to tag-based revalidation, the same bulk publish fires one webhook per _type batch. Sanity’s webhook system doesn’t natively batch, but because I’m revalidating by tag, all posts purge from a single sanity:post call. Webhook processing drops to under 2 seconds for the same workload.

Vercel’s function invocation count dropped from 300+/day to ~40/day on a moderately active site. Cold start contention disappeared. Editors see changes reflected in under 10 seconds instead of 30+.

Gotchas

If your homepage aggregates multiple document types (posts, projects, testimonials), you must tag the fetch with all relevant types:

{
  next: {
    tags: ['sanity:post', 'sanity:project', 'sanity:testimonial'],
  },
}

Any publish of those types will purge the homepage. If you forget a tag, the page won’t revalidate and editors will report stale data.

Also, revalidateTag only purges the Next.js cache. If you use a CDN like Cloudflare or Fastly in front of Vercel, you’ll need a separate purge call to their API. I handle that by checking req.headers.get('x-vercel-id') in the route handler and making a secondary fetch to Cloudflare’s purge endpoint if the header is missing (meaning the request came from the CDN, not Vercel’s internal revalidation).

When not to use this

If your Sanity dataset has 10,000+ documents and your pages aggregate data from hundreds of types, tagging every type on every page becomes unwieldy. In that case, consider PPR or a time-based ISR with revalidate: 60 instead of on-demand revalidation. For most marketing and editorial sites under 1,000 pages, tag-based revalidation is the sweet spot.

Date, Time and Location

• Jun 25, 2026

• 9AM Pacific

• Online. Register for the Zoom!

Talks will include:

Large-Scale Scene Reconstruction via Local View Transformers

Transformer-based models have advanced 3D scene reconstruction, but their quadratic attention limits scalability to large scenes. We introduce the Local View Transformer (LVT), which replaces global attention with locality-aware attention over neighboring views, conditioned on relative camera geometry. LVT decodes directly into 3D Gaussian splats with view-dependent color and opacity for high-fidelity rendering. Our approach enables scalable, single-pass reconstruction of large, high-resolution scenes.

About the Speaker

Tooba Imtiaz is a PhD candidate in Electrical and Computer Engineering at Northeastern University, working in the Machine Learning Lab.

Lessons learned from running AI workloads in production

He’ll share his “tales from the engine room” – practical insights from operating AI systems at scale, including the challenges of abstraction layers, the realities of data movement and hardware constraints, and how systems thinking is essential for building high-performance, secure, and responsible AI infrastructure.

About the Speaker

Dave Hughes is CTO at Stelia. He was formerly CTO at Genesis Cloud, which pioneered what is now commonly known as ‘neoclouds’, and Principal Engineer/Interim Director of Engineering at Adjust GmbH where he built large-scale data warehousing and processing.

Enhancing Low-Field MRI with Deep Super-Resolution for Improved Nipah Virus Neuroimaging

Advances in deep learning make very-low-field (VLF) MRI systems a viable alternative for in vivo neuroimaging. Zero-shot super-resolution, self-supervised learning, and generative AI were explored to improve the quality of low-field MRI images. We present a framework for the first deployment of a VLF scanner for imaging Nipah virus-inoculated nonhuman primates (NHPs) using a 0.05 T MRI system.

First, a retrospective simulation study assessed the feasibility of imaging NiV infection at low field, followed by a prospective deployment (0.05 T) that enabled longitudinal imaging. The VLF-NiV imaging was characterized by low image quality and included multiple contrasts. A deep learning-based unpaired domain adaptation (CycleGAN) conditioned on acquisition parameters was used to harmonize contrast, and a simulation-based ResUNet model was used to reduce unwanted noise and preserve T2-weighted structural fidelity. We also highlight studies involving zero-shot super-resolution and denoising experiments that are advantageous for accessible neuroimaging.

About the Speaker

Ajay Sharma is a deep learning engineer with a broad background in biomedical image analysis. His research focuses on developing advanced deep learning methods for computer-aided disease detection and diagnosis.

And Now for Something Completely Different with FiftyOne

Often the best way to understand what a tool is truly capable of, is to use in ways it was never intended to be used. This session pushes FiftyOne past its computer vision roots through a series of demos showing how to push the boundaries with FiftyOne. A few practical, some playful, all built with open source code. You’ll see how FiftyOne’s core building blocks generalize far beyond labeled datasets, and leave with patterns and ideas you can take in your own direction.

About the Speaker

Burhan Qaddoumi is a ML DevRel Engineer at Voxel51 and perpetual “new guy” as a life long learner. Active in communities all across the web, eager to help, learn, and share with others that demonstrate initiative, interest, and drive.