<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Claude on Kinoko's TIL Log</title><link>https://kinoko-tech-blog-theta.vercel.app/tags/claude/</link><description>Recent content in Claude on Kinoko's TIL Log</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>pippimotta@gmail.com (Kinoko)</managingEditor><webMaster>pippimotta@gmail.com (Kinoko)</webMaster><copyright>&amp;copy; Brewed by Kinoko</copyright><lastBuildDate>Sat, 06 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kinoko-tech-blog-theta.vercel.app/tags/claude/index.xml" rel="self" type="application/rss+xml"/><item><title>Managed agents</title><link>https://kinoko-tech-blog-theta.vercel.app/posts/managed-agents/</link><pubDate>Sat, 06 Jun 2026 00:00:00 +0000</pubDate><author>pippimotta@gmail.com (Kinoko)</author><guid>https://kinoko-tech-blog-theta.vercel.app/posts/managed-agents/</guid><description>&lt;h2 id="the-point"&gt;The Point&lt;/h2&gt;
&lt;p&gt;Claude Managed Agents separate &amp;ldquo;behavior definition&amp;rdquo; (Agent) and &amp;ldquo;execution environment definition&amp;rdquo; (Environment) into create-once resources. Each task only needs a Session to combine them, and the orchestration loop plus state management are all handled server-side by Anthropic.&lt;/p&gt;
&lt;h2 id="explanation"&gt;Explanation&lt;/h2&gt;
&lt;p&gt;An Agent stores the model, system prompt, tools, and MCPs. An Environment stores the sandbox template (packages, networking). Both are create-once / reuse-by-ID resources. A Session is the runtime instance of Agent + Environment &amp;ndash; the server side runs the tool call loop, persists conversation history and sandbox filesystem. Your app only needs to subscribe to the event stream or webhook; you do not need to write your own agent loop. This design decouples &amp;ldquo;what Claude should do&amp;rdquo; from &amp;ldquo;where it runs,&amp;rdquo; similar to how K8s separates Deployment spec from Node/namespace management.&lt;/p&gt;</description><content:encoded><![CDATA[<h2 id="the-point">The Point</h2>
<p>Claude Managed Agents separate &ldquo;behavior definition&rdquo; (Agent) and &ldquo;execution environment definition&rdquo; (Environment) into create-once resources. Each task only needs a Session to combine them, and the orchestration loop plus state management are all handled server-side by Anthropic.</p>
<h2 id="explanation">Explanation</h2>
<p>An Agent stores the model, system prompt, tools, and MCPs. An Environment stores the sandbox template (packages, networking). Both are create-once / reuse-by-ID resources. A Session is the runtime instance of Agent + Environment &ndash; the server side runs the tool call loop, persists conversation history and sandbox filesystem. Your app only needs to subscribe to the event stream or webhook; you do not need to write your own agent loop. This design decouples &ldquo;what Claude should do&rdquo; from &ldquo;where it runs,&rdquo; similar to how K8s separates Deployment spec from Node/namespace management.</p>
<h2 id="knowledge-sugar">Knowledge Sugar</h2>
<p><strong>Comparison with self-managed</strong>: when you build an agent yourself with the Messages API, you maintain the <code>messages[]</code> array, set up sandboxes, write error recovery, and manage context window overflow. Managed Agents offload all of this infra &ndash; you go from &ldquo;the person writing the loop&rdquo; to &ldquo;the person subscribing to results.&rdquo;</p>
<p><strong>Docker analogy</strong>: Environment is like a Docker image; each Session&rsquo;s sandbox is like running <code>docker run</code> from that image. Sessions start fresh between each other, but within a Session things are stateful (filesystem + conversation history persist).</p>
<p><strong>Agent versioning</strong>: the Agent config is a versioned resource. You can pin a session to a specific version for staged rollout without always running the latest.</p>
<p><strong>Event types</strong>: events produced by a Session follow the sequence <code>thinking</code>, <code>tool_use</code>, <code>tool_result</code>. When the task finishes naturally, it emits <code>session.status_idle</code>. A Session can receive multiple rounds of events &ndash; it is not one-shot.</p>
<p><strong>Multi-agent gotcha</strong>: in a multi-agent session, all agents share the same sandbox filesystem (agents can pass intermediate artifacts via files), but conversation context is isolated per-agent thread. The isolation boundary is context, not filesystem.</p>
]]></content:encoded></item></channel></rss>