<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Sedai.io</title>
    <description>The latest articles on DEV Community by Sedai.io (@sedai).</description>
    <link>https://dev.to/sedai</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F937836%2Fe0f9ca08-90c5-46ca-bd95-ade5bda2fab4.png</url>
      <title>DEV Community: Sedai.io</title>
      <link>https://dev.to/sedai</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/sedai"/>
    <language>en</language>
    <item>
      <title>How Much Isolation Do AI Agents Actually Need?</title>
      <dc:creator>Sedai.io</dc:creator>
      <pubDate>Wed, 08 Jul 2026 16:41:34 +0000</pubDate>
      <link>https://dev.to/sedai/how-much-isolation-do-ai-agents-actually-need-1ho8</link>
      <guid>https://dev.to/sedai/how-much-isolation-do-ai-agents-actually-need-1ho8</guid>
      <description>&lt;p&gt;By Suresh Mathew, Sedai CEO&lt;/p&gt;

&lt;p&gt;When a tenant-isolation check failed in Asana's MCP server, roughly 1,000 companies using Asana's AI integration could access each other's project data for five weeks straight. &lt;/p&gt;

&lt;p&gt;Failures like that are why AWS, Microsoft, Google, and Anthropic recently rebuilt their agent runtimes the same way: every session gets its own isolated environment, and the session, not the request, is what the platform schedules, secures, and bills for. &lt;/p&gt;

&lt;p&gt;But none of them agree on how strong that isolation should be, because stronger isolation costs speed and money.&lt;/p&gt;

&lt;p&gt;So I asked our engineering leaders: how much isolation do AI agents actually need to keep data safe?&lt;/p&gt;

&lt;h2&gt;
  
  
  Picking One Isolation Level Is the Wrong Question
&lt;/h2&gt;

&lt;p&gt;Benjamin Thomas (Co-Founder &amp;amp; CTO)&lt;/p&gt;

&lt;p&gt;I don't think you can pick one isolation level globally. Isolation strength should follow the trust level of what's running in the session. If an agent is executing arbitrary model-generated code with network access and credentials in scope, I want VM-level isolation, Firecracker-style, and I'll take the cold start. &lt;/p&gt;

&lt;p&gt;That cost is also more manageable than the framing suggests, since you can start with the lighter VM at session initiation and escalate to heavier isolation only when the workload calls for it. Which really means the problem isn't the sandbox but the routing layer. &lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;"Isolation strength should follow the trust level of what's running in the session." &lt;br&gt;
— Benjamin Thomas, Co-Founder &amp;amp; CTO&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Something has to look at each incoming session and decide its trust tier, placement, and lifecycle continuously rather than as a one-time config. That kind of workload-aware decisioning is where I'd expect the real gains to show up, both on cost and on blast radius.&lt;/p&gt;

&lt;p&gt;The other wrinkle is that not all sessions are individual. Once you have shared sessions within a team, or long-running ones that outlive a single user's involvement, the question shifts from “What can escape the sandbox?” to “Who owns the session right now?”&lt;/p&gt;

&lt;p&gt;The Asana case is exactly that: isolation held but the identity binding didn't. For shared and long-lived sessions, the session must be a security principal in its own right, not just a compute unit with a timeout. And the routing layer needs to carry that identity context along with everything else.&lt;/p&gt;

&lt;h2&gt;
  
  
  Your Sandbox Wont Save Your Work
&lt;/h2&gt;

&lt;p&gt;Aby Jacob (VP of Engineering)&lt;/p&gt;

&lt;p&gt;The sandbox is a security boundary, not a durability boundary, and many agentic workloads will fail if/when developers conflate the two. &lt;/p&gt;

&lt;p&gt;While the session is increasingly becoming the preferred unit of compute, it seems durability and recovery are intentionally outside of its scope. A sandbox was never meant to remember, just execute. &lt;/p&gt;

&lt;p&gt;For example, when a microVM crashes halfway through an agent task, everything inside it disappears including working files, runtime environment, partially completed routines and cached data. The session ID may still exist, but it now points to an empty container.  &lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;"The sandbox is a security boundary, not a durability boundary." &lt;br&gt;
— Aby Jacob, VP of Engineering&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The platform won't recover any of this, so we should design as if a crash is guaranteed: persist state outside the sandbox after every turn, make the environment reproducible from code or scripts, and make every tool call idempotent so a retry doesn't cause unintended side effects. &lt;/p&gt;

&lt;p&gt;Resilient agents should externalise their state, treat the sandbox as ephemeral, and design every transaction to tolerate retries and partial failures. &lt;/p&gt;

&lt;p&gt;An additional benefit of this architecture is portability. Once state lives outside the sandbox, the execution environment becomes a replaceable commodity that can be rented from any compatible provider, significantly reducing vendor lock-in.&lt;/p&gt;

&lt;h2&gt;
  
  
  Session Isolation Costs Less Than You Think
&lt;/h2&gt;

&lt;p&gt;Shankar Jothi (VP of Engineering, ML)&lt;/p&gt;

&lt;p&gt;The isolation overhead people worry about is mostly a cold-start cost rather than a steady-state one (at least for compute-bound serving paths). You pay it when a session is first provisioned, and it fades once the environment is warm and requests route back to it. &lt;/p&gt;

&lt;p&gt;So the real variable isn't isolation itself, but how often you're establishing sessions — something lifecycle settings like idle timeouts directly influence. &lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;"The isolation overhead people worry about is mostly a cold-start cost rather than a steady-state one." &lt;br&gt;
— Shankar Jothi, VP of Engineering, ML&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;It's also worth being honest that this isn't measured as cleanly as it could be. Startup latency often gets folded into a single end-to-end number alongside inference time. The more useful practice is to decompose the path into the platform-managed portion and the application-defined portion, tracking those separately. That lets you reason about regressions instead of guessing at them.&lt;/p&gt;

&lt;p&gt;More broadly, this still feels like an early and evolving space. The primitives are converging, but the operational maturity around cost, portability, and observability is still being worked out. That's where I expect most of the interesting engineering to happen over the next year.&lt;/p&gt;

</description>
      <category>agents</category>
      <category>devops</category>
      <category>dataprivacy</category>
    </item>
    <item>
      <title>Tokenomics Guide</title>
      <dc:creator>Sedai.io</dc:creator>
      <pubDate>Thu, 02 Jul 2026 16:14:28 +0000</pubDate>
      <link>https://dev.to/sedai/tokenomics-guide-15ap</link>
      <guid>https://dev.to/sedai/tokenomics-guide-15ap</guid>
      <description>&lt;p&gt;We wrote a Guide to AI token consumption in 2026, including up-to-date pricing comparisons for the latest models. Read here: &lt;a href="https://sedai.io/blog/what-is-ai-tokenomics" rel="noopener noreferrer"&gt;https://sedai.io/blog/what-is-ai-tokenomics&lt;/a&gt;&lt;/p&gt;

</description>
      <category>tokenomics</category>
      <category>aiops</category>
      <category>finops</category>
    </item>
    <item>
      <title>The end of tokenmaxxing</title>
      <dc:creator>Sedai.io</dc:creator>
      <pubDate>Fri, 26 Jun 2026 16:42:45 +0000</pubDate>
      <link>https://dev.to/sedai/the-end-of-tokenmaxxing-5g00</link>
      <guid>https://dev.to/sedai/the-end-of-tokenmaxxing-5g00</guid>
      <description>&lt;p&gt;The "tokenmaxxing" era is officially over, according to Sedai CEO Suresh Mathew. The new era of tokenomics has begun.&lt;/p&gt;

&lt;p&gt;Read Suresh's article: &lt;a href="https://sedai.io/blog/tokenmaxxing-ending-era-tokenomics-has-begun" rel="noopener noreferrer"&gt;https://sedai.io/blog/tokenmaxxing-ending-era-tokenomics-has-begun&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Tokenmaxxing is the idea that more AI token consumption = more productivity. Earlier this year, companies like Meta, Amazon, and Microsoft set internal targets for token usage. &lt;/p&gt;

&lt;p&gt;But while AI spending skyrocketed, the results didn't follow.&lt;/p&gt;

&lt;p&gt;Suresh proposes a new way to measure the value of AI, for this new era of tokenomics. It's a fantastic article for Eng, FinOps, and Finance leaders.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>productivity</category>
    </item>
    <item>
      <title>Is the era of cheap AI over?</title>
      <dc:creator>Sedai.io</dc:creator>
      <pubDate>Thu, 28 May 2026 18:39:11 +0000</pubDate>
      <link>https://dev.to/sedai/is-the-era-of-cheap-ai-over-4lo0</link>
      <guid>https://dev.to/sedai/is-the-era-of-cheap-ai-over-4lo0</guid>
      <description>&lt;p&gt;For years, we haven't paid the real cost for AI models. But that's about to change. &lt;/p&gt;

&lt;p&gt;Our team explains how eng leaders can control the rising costs, in this article: &lt;a href="https://sedai.io/blog/is-the-era-of-cheap-ai-over" rel="noopener noreferrer"&gt;https://sedai.io/blog/is-the-era-of-cheap-ai-over&lt;/a&gt; &lt;/p&gt;

</description>
      <category>llm</category>
      <category>agents</category>
      <category>aiops</category>
      <category>finops</category>
    </item>
    <item>
      <title>"Who Touched Prod?"</title>
      <dc:creator>Sedai.io</dc:creator>
      <pubDate>Thu, 07 May 2026 15:43:59 +0000</pubDate>
      <link>https://dev.to/sedai/who-touched-prod-1egf</link>
      <guid>https://dev.to/sedai/who-touched-prod-1egf</guid>
      <description>&lt;p&gt;This is what it feels like to cause a prod issue&lt;/p&gt;

</description>
      <category>devops</category>
      <category>sre</category>
      <category>cloud</category>
    </item>
    <item>
      <title>Podcast Livestream w/ Ilan Rabinovitch, SVP Product at Datadog</title>
      <dc:creator>Sedai.io</dc:creator>
      <pubDate>Wed, 12 Oct 2022 18:32:43 +0000</pubDate>
      <link>https://dev.to/sedai/livestream-w-ilan-rabinovitch-svp-product-at-datadog-409n</link>
      <guid>https://dev.to/sedai/livestream-w-ilan-rabinovitch-svp-product-at-datadog-409n</guid>
      <description>&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F76daorjq3d1v9lycwv9m.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F76daorjq3d1v9lycwv9m.png" alt=" " width="800" height="450"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We're incredibly excited to launch our new podcast tomorrow Thursday, October 13 with our first episode featuring a very ✨ special guest ✨, Ilan Rabinovitch, SVP of Product at Datadog.&lt;/p&gt;

&lt;p&gt;Sedai would like to extend a personal invitation to the community on dev.to to join this special livestream of Episode 1 as we discuss The Future of APM and Cloud Operations. In this episode, we'll explore the different application performance challenges companies face today with the rise of microservice architectures, containers and serverless computing. We'll discuss the strengths and limits of the observability paradigm, and how autonomous systems and AIOps have emerged to streamline and scale operations for complex modern applications.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://www.sedai.io/lp/beyond-automation-ep1-ilan-rabinovitch" rel="noopener noreferrer"&gt;Register to join us live tomorrow Thursday, October 13 at 11AM PT / 2PM ET!&lt;br&gt;
&lt;/a&gt;&lt;/p&gt;

</description>
      <category>sre</category>
      <category>devops</category>
      <category>apm</category>
      <category>aws</category>
    </item>
  </channel>
</rss>
