<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>yaodub</title>
  <link>https://yaodub.com/</link>
  <atom:link href="https://yaodub.com/feed.xml" rel="self" type="application/rss+xml" />
  <description>Open tools for AI agents, and small games to stay honest.</description>
  <language>en</language>
  <item>
    <title>Cast: a living org chart for agents</title>
    <link>https://yaodub.com/blog/living-org-chart-for-agents/</link>
    <guid isPermaLink="true">https://yaodub.com/blog/living-org-chart-for-agents/</guid>
    <pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
    <description>I used to draw the whole agent org up front. What building it taught me: it grows better one approved connection at a time.</description>
    <content:encoded><![CDATA[<p>In the <a href="/blog/multiplayer-harness-for-ai-agents/">last post</a> I wrote about running a team of agents instead of piling every job onto one.</p>
<p>There was a catch I did not dwell on then. The way I first built it, you drew the whole org chart up front. Every person who could talk to an agent, granted ahead of time. Every agent-to-agent line, wired by hand.</p>
<p>This post is what running it taught me about that, and what I ended up changing.</p>
<h2>The map you don’t know yet</h2>
<p>Drawing the map up front works when the team is three agents and you know exactly who talks to whom.</p>
<p>It stops working the moment the team is real.</p>
<p>People show up you did not plan for. A coworker hears about your assistant and messages it. You spin up a new agent on a Saturday and it needs to ask an older one for help.</p>
<p>None of those edges were on the map, because the map was a guess.</p>
<p>I kept ending up in the same bind. Draw it too tight and I spent the week rewiring. Too loose and everything could talk to everything. Neither sat right.</p>
<p>Cast 0.2.0 handled new people with pairing codes. Meet someone, generate a code, send it over, they redeem it. It worked, and it was busywork. Every introduction went through me by hand.</p>
<h2>A connection forms when someone knocks</h2>
<p>What I landed on in 0.3.0 was to change <em>when</em> an edge gets made: at first contact, instead of at setup.</p>
<p>Someone new messages your agent. Nothing silently opens. The message is <strong>held</strong>, and the agent turns to you and asks.</p>
<p>The ask lands in your own chat, with the message they sent, so you decide with the actual words in front of you. The sender just sees that their message is waiting.</p>
<p>Approve, and they are in. Reject, and the door stays shut.</p>
<p>Approving once creates a <strong>standing grant</strong>. The next message flows without asking you again, and you can revoke it later from the access tab.</p>
<h2>Agents knock the same way</h2>
<p>The same gate covers the agents themselves.</p>
<p>When one agent wants help from another and there is no line between them yet, the request is held exactly like a stranger’s first message. You say yes, and the org chart grows a line.</p>
<p>What builds up over the weeks is the map of who actually works with whom. Not the one I guessed at setup. Every line on it exists because someone needed it once and I approved it.</p>
<h2>You can still draw by hand</h2>
<p>Pre-wiring still works. When you already know two agents belong together, write the grant and they are connected from day one.</p>
<p>The difference is you no longer need the whole picture before you start. The chart begins as small as you like and fills in as the work arrives.</p>
<p>The org chart stopped being a diagram I maintain. It became a record of what my team actually does.</p>
<h2>Try it</h2>
<p>Cast v0.3.0 is up on <a href="https://github.com/yaodub/cast">GitHub</a>.</p>
<pre><code class="language-bash">git clone https://github.com/yaodub/cast
pnpm start
</code></pre>
<p>Coming from 0.2.0, the migration scripts under <code>scripts/migrations/0.2-to-0.3/</code> carry your paired users and grants over to the new model.</p>
<p>Still developer alpha, still rough in places. If something breaks, tell me.</p>
<hr>
<p><em>Originally published on the <a href="https://blog.getcast.dev/living-org-chart-for-agents/">Cast blog</a>.</em></p>
]]></content:encoded>
  </item>
  <item>
    <title>Cast: a multiplayer harness for AI agents</title>
    <link>https://yaodub.com/blog/multiplayer-harness-for-ai-agents/</link>
    <guid isPermaLink="true">https://yaodub.com/blog/multiplayer-harness-for-ai-agents/</guid>
    <pubDate>Tue, 09 Jun 2026 00:00:00 GMT</pubDate>
    <description>I stopped trying to make one agent do everything, and built a harness for running a team of them.</description>
    <content:encoded><![CDATA[<p>Building an AI agent for yourself has gotten easy enough for the average person.</p>
<p>AI models have gotten capable enough that all you need to do is write a prompt, give it some tools, and they are able to do real work. A lot of people run personal agents this way today.</p>
<p>The catch is that these agents are designed to work alone. That is fine for a personal helper. It is not how <strong>real work</strong> gets done.</p>
<p>Nothing substantial is a solo job. Humans split complex problems up and hand the pieces around.</p>
<p>Pile every job onto one agent and it gets worse at each job.</p>
<p>The setup breaks down the moment more than one human operator is involved: these systems are not built for multiple people talking to the same agent.</p>
<p>Agents work best when they are able to work as a team.</p>
<h2>I started with OpenClaw</h2>
<p>OpenClaw seemed like a good place to start: a single always-on agent running in the background, reachable on your usual chat apps.</p>
<p>It can technically run more than one agent. But the moment I tried to get several working together it buckled.</p>
<p>Contexts bloated. Getting them to coordinate effectively was a fight the whole way.</p>
<p>I spent a few weeks on it before accepting it would not get me there.</p>
<p>What I needed was a better harness. One that gave agents multi-user capabilities and let them work with other agents as well, for true multiplayer. That comes down to three things:</p>
<ul>
<li><strong>Real identity:</strong> the agent always knows who it is talking to.</li>
<li><strong>Isolation between people:</strong> one person’s history never leaks into another’s.</li>
<li><strong>Coordination between agents</strong> that holds up under real work.</li>
</ul>
<h2>One agent, a whole team</h2>
<p>With <a href="https://getcast.dev">Cast</a>, an agent is able to keep several conversations going at once without confusing them.</p>
<p>The agent knows you when you message: your history, the project you were stuck on last week.</p>
<p>Your coworker who messages the same agent gets their own history, not yours.</p>
<p>Everyone gets access to the agent’s memory and skills, but each conversation stays private.</p>
<p>You can take this further and set the same agent to adopt different postures depending on who is talking to it. It can be open and casual with your team and more careful with external users, while staying one agent underneath.</p>
<h2>Agents that ask each other for help</h2>
<p>These agents can also collaborate and ask other agents for help.</p>
<p>You decide who can ask whom, and about what; Cast helps you wire the connections, almost the way you would draw an org chart.</p>
<p>So your assistant never guesses who to hit up or ends up shouting a question at everyone.</p>
<p>When it asks a peer a question, it gets the answer back, not the other agent’s whole memory or its keys.</p>
<p>That is what keeps a team of agents from collapsing into a pile.</p>
<h2>Spin one up on a Saturday</h2>
<p>You could build out a whole operation this way: dream up a new agent on a Saturday afternoon, design it in chat, and onboard it that same evening.</p>
<p>Every agent sits behind the same fixed boundaries. By making the boundaries explicit, you can iterate on the agent design without worrying about it violating security policies.</p>
<p>That is the bet behind Cast.</p>
<p>Get the foundation right and the plumbing stops being something you have to fuss about, leaving you time to focus on the agent design.</p>
<p>What you get is not a toy agent that forgets you or a contraption that topples the moment things get complicated, but a real team of agents you can lean on, working for you and the people around you.</p>
<p>An agent should be small, light enough to rewrite on a whim. The foundation under it should be built to keep it on the rails.</p>
<h2>Try it</h2>
<p>Cast is in developer alpha, up on <a href="https://github.com/yaodub/cast">GitHub</a>. The Claude Code path works today:</p>
<pre><code class="language-bash">git clone https://github.com/yaodub/cast
pnpm start
</code></pre>
<p>I’m going to write about the choices behind it as I go. The next piece is on how a single agent holds a whole team’s conversations at once and never lets them touch.</p>
<p>It’s rough in plenty of places and missing more. If you try it and something breaks, tell me.</p>
<hr>
<p><em>Originally published on the <a href="https://blog.getcast.dev/multiplayer-harness-for-ai-agents/">Cast blog</a>.</em></p>
]]></content:encoded>
  </item>
</channel>
</rss>
