<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:blyg="https://blygger.org/ns/0.1" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Protocols for Business SIG</title>
    <link>https://npc.here.now/protocolvision/blyg/</link>
    <description>Session notes and the running research log of the Protocol Institute's Protocols for Business SIG.</description>
    <lastBuildDate>Tue, 29 Sep 2026 08:09:01 GMT</lastBuildDate>
    <blyg:level>1</blyg:level>
    <blyg:manifest>https://npc.here.now/protocolvision/blyg/blyg.json</blyg:manifest>
    <item>
      <guid isPermaLink="false">blyg:6ce1weq7vetchvb4zq8yypn16s:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/f/6ce1weq7vetchvb4zq8yypn16s/</link>
      <title>Where we are, end of September 2026. We spent the…</title>
      <description><![CDATA[<p><strong>Where we are, end of September 2026.</strong></p>
<div class="blyg-tk-gen"><p>We spent the last few weeks giving the SIG's method a name we can test. We call it Business Protocol Management. A business finds the few protocols everything relies on, builds them into its systems as a hard core, and leaves people and agents free to work inside them. The <a href="https://npc.here.now/protocolvision/about/">About page</a> now says so.</p>
<p>The reading plan changed to match. <a href="https://npc.here.now/protocolvision/sessions/">Sessions</a> now shows six themes in the order we'll explore them: what agents are in practice, how nature coordinates, what systems emit, how to see hardness in real incidents, how to design the hard core, and how industries keep it alive. Most readings are primary sources from aviation, nuclear power, spaceflight and software operations, with business process re-engineering as the contrast. We still start with the Hugging Face incident on 2 November.</p>
<p>We also built a <a href="https://npc.here.now/protocolvision/sessions/map/">reading map</a> of 400 readings placed by what they say, with the year's readings marked. It grows with the group. Ask your AI assistant what the map is missing from your own experience, and it can add each reading to GitHub for us to review.</p>
<p>The <a href="https://npc.here.now/protocolvision/research/">Research page</a> ties our 2027 focus on AI-native data operations to the method and lists five open questions we'd like help with. By the end of next year we hope the method will be much more mature, shaped by what we read and build together.</p></div>]]></description>
      <pubDate>Tue, 29 Sep 2026 08:09:01 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>6ce1weq7vetchvb4zq8yypn16s</blyg:id>
      <blyg:kind>fragment</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-29T08:09:01Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6ce1weq7vetchvb4zq8yypn16s.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5k675cyvwhft8rp0wjah3jq30a:v2</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5k675cyvwhft8rp0wjah3jq30a/</link>
      <title>Kitcraft: rewritten from the workshop page and the feedback folder (evidence pack, facilitator retro) — AI Kitcraft, 21–22 September 2026</title>
      <description><![CDATA[<h1>AI Kitcraft, 21–22 September 2026</h1>
<div class="blyg-tk-gen"><p>Last week the SIG ran <a href="https://ai.protocolized.dev/kitcraft/">AI Kitcraft</a>, a hands-on AI tooling workshop at the 2026 Protocol Symposium, facilitated by Rafa and Sachin. It started from one premise: AI is in its <em>Kit phase</em>. Like every general-purpose technology before it, the real work happens in people's own local experiments long before it turns into firm-scale products, and the missing productivity everyone is waiting for is a sign of that stage. The workshop asked the next question: everyone uses AI their own way, so what happens when we need to work together?</p>
<p>Over four one-hour sessions, participants worked through <strong>Kit → Factory → Bridge</strong>, each with their own AI assistant working against one shared, <a href="https://github.com/protocolvision/workshop-kitkraft">public repository</a>:</p>
<ul>
<li><strong>Kit:</strong> list the AI setups you already use, and read everyone else's.</li>
<li><strong>Factory:</strong> make one of yours runnable by someone else, or by their assistant.</li>
<li><strong>Bridge:</strong> get one assistant to run several people's kits together, reliably.</li>
</ul>
<p><strong>What happened.</strong> Sixteen people joined the first session, fourteen of them participants. The workshop's own <a href="https://github.com/protocolvision/workshop-kitkraft/blob/main/workshop-dev/feedback/2026-09-evidence.md">evidence pack</a> shows the funnel narrowing at every stage: almost everyone wrote an inventory, and nine of twelve with a folder in the repo also wrote about how their setup relates to someone else's. That is the clearest sign people read each other's work. Just over half did factory work beyond the template, a quarter opened a bridge, and two wrote a show-and-tell. About seven people were still there in the last session, and each had built something of their own.</p>
<p><strong>What worked.</strong> The framing, which focused on understanding the technology's current phase rather than on building a tool. The examples of what people had actually built. Working through a single shared repository, with a context tank, glossary, and resources that participants could ask questions of.</p>
<p><strong>What didn't.</strong> Discord and GitHub were gates for people who don't already live in them. Expertise ranged from first-time GitHub users to experienced programmers. Four sessions in two days, in a crowded symposium week, was too compressed. The first session carried too much theory, which left too little time for choosing a project. The first exercise had a bug: assistants surveyed participants instead of reading their own history. And recording depended on manual commands, so only two of the four plenaries were captured.</p>
<p><strong>The bridge stayed open, and that is the finding.</strong> Individual tooling is getting easy, and getting several people's setups to work together is where the difficulty is. That is the same question our <a href="https://npc.here.now/protocolvision/research/">research</a> asks about agents in organizations.</p>
<p><strong>Next time.</strong> Show-and-tell first, then theory, then more show-and-tell. Inventory, then choose a project, then build it, at one session a day over a calmer week. Plan on about three facilitators for ten attendees, because learning AI is closer to an apprenticeship than a course. Grow through an apprenticeship ladder: come to one workshop, then help facilitate the next. The full <a href="https://github.com/protocolvision/workshop-kitkraft/blob/main/workshop-dev/feedback/2026-09-facilitator-retro.md">facilitator retrospective</a> is in the repo.</p></div>
<p>Sources: the <a href="https://ai.protocolized.dev/kitcraft/">workshop page</a> and the workshop repository's <a href="https://github.com/protocolvision/workshop-kitkraft/tree/main/workshop-dev/feedback">feedback folder</a> (evidence pack generated 23 September 2026, and the facilitator retrospective).</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:58:32 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5k675cyvwhft8rp0wjah3jq30a</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>2</blyg:version>
      <blyg:created>2026-09-27T04:56:28Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5k675cyvwhft8rp0wjah3jq30a.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:2txmsk12amtvq11jeqgkvdkqmw:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/2txmsk12amtvq11jeqgkvdkqmw/</link>
      <title>Session notes now live on a blyg</title>
      <description><![CDATA[<h1>Session notes now live on a blyg</h1>
<div class="blyg-tk-gen"><p>From now on, the SIG's session notes and research log are published here, on a blyg: a small publication built on the <a href="https://blygger.org/">Blygger protocol</a>, developed at the Protocol Institute. It is plain files and an RSS feed on our own site. There is no platform in the middle, and you can <a href="https://npc.here.now/protocolvision/blyg/feed.xml">follow it</a> with any feed reader.</p>
<p>What's here to start:</p>
<ul>
<li><strong>All 39 archived sessions</strong>, from February 2023 to this month, imported from the Protocol Institute meeting archive. Each one links back to its source, and six link to the raw notes from the session recording. The summaries were written by c3po, the Institute's session pipeline, and are marked as machine-generated.</li>
<li><strong>The research log</strong>, which carries the working thesis for our 2027 research and changes as we learn. Edits appear as new versions of the same item rather than new posts, and the changelog keeps the history.</li>
</ul>
<p>Members with write access to the repository can publish too: a commit is a publish. Every change is checked against the protocol before it goes out.</p></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:56:28 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>2txmsk12amtvq11jeqgkvdkqmw</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:56:28Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/2txmsk12amtvq11jeqgkvdkqmw.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:3efd9prsmabbqqnppqgbt8qnz7:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/3efd9prsmabbqqnppqgbt8qnz7/</link>
      <title>New website for the SIG</title>
      <description><![CDATA[<h1>New website for the SIG</h1>
<div class="blyg-tk-gen"><p>The Protocols for Business SIG has a new home at <a href="https://npc.here.now/protocolvision/">npc.here.now/protocolvision</a>. It has four sections:</p>
<ul>
<li><strong><a href="https://npc.here.now/protocolvision/about/">About</a>:</strong> our method, protocol vision, which means looking at an organization through its protocols rather than its org chart. Also where the group came from, who facilitates it, and our work so far.</li>
<li><strong><a href="https://npc.here.now/protocolvision/sessions/">Sessions</a>:</strong> a new syllabus of 26 primary sources, every other Monday at 15:30 UTC from 2 November 2026, with a quote from each reading. It opens with what OpenAI and Anthropic reported about agent swarms this year. Joining details and a calendar you can subscribe to are there too.</li>
<li><strong><a href="https://npc.here.now/protocolvision/research/">Research</a>:</strong> the premises behind our 2027 focus on AI-native data operations (abundant cognition, distributed agency, mediation) and the case studies that test them.</li>
<li><strong><a href="https://npc.here.now/protocolvision/play/">Play</a>:</strong> protocol watching, workshops, and a swarm simulation we are still exploring.</li>
</ul>
<p>The site is built from a public repository, so anyone can suggest changes. It also publishes a plain summary for language models (<code>llms.txt</code>) and the full session schedule as data (<code>sessions.json</code>), so an assistant can tell you when the next session is and what we're reading.</p></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:56:28 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>3efd9prsmabbqqnppqgbt8qnz7</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:56:28Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/3efd9prsmabbqqnppqgbt8qnz7.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5k675cyvwhft8rp0wjah3jq30a:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5k675cyvwhft8rp0wjah3jq30a/</link>
      <title>AI Kitcraft, 21–22 September 2026</title>
      <description><![CDATA[<h1>AI Kitcraft, 21–22 September 2026</h1>
<div class="blyg-tk-gen"><p>Last week the SIG ran <a href="https://ai.protocolized.dev/kitcraft/">AI Kitcraft</a>, a hands-on AI tooling workshop at the 2026 Protocol Symposium, facilitated by Rafa and Sachin. It started from one premise: AI is in its <em>Kit phase</em>. Like every general-purpose technology before it, the real work happens in people's own local experiments long before it turns into firm-scale products, and the missing productivity everyone is waiting for is a sign of that stage. The workshop asked the next question: everyone uses AI their own way, so what happens when we need to work together?</p>
<p>Over four one-hour sessions, participants worked through <strong>Kit → Factory → Bridge</strong>, each with their own AI assistant working against one shared, <a href="https://github.com/protocolvision/workshop-kitkraft">public repository</a>:</p>
<ul>
<li><strong>Kit:</strong> list the AI setups you already use, and read everyone else's.</li>
<li><strong>Factory:</strong> make one of yours runnable by someone else, or by their assistant.</li>
<li><strong>Bridge:</strong> get one assistant to run several people's kits together, reliably.</li>
</ul>
<p><strong>What happened.</strong> Sixteen people joined the first session, fourteen of them participants. The workshop's own <a href="https://github.com/protocolvision/workshop-kitkraft/blob/main/workshop-dev/feedback/2026-09-evidence.md">evidence pack</a> shows the funnel narrowing at every stage: almost everyone wrote an inventory, and nine of twelve with a folder in the repo also wrote about how their setup relates to someone else's. That is the clearest sign people read each other's work. Just over half did factory work beyond the template, a quarter opened a bridge, and two wrote a show-and-tell. About seven people were still there in the last session, and each had built something of their own.</p>
<p><strong>What worked.</strong> The framing, which focused on understanding the technology's current phase rather than on building a tool. The examples of what people had actually built. Working through a single shared repository, with a context tank, glossary, and resources that participants could ask questions of.</p>
<p><strong>What didn't.</strong> Discord and GitHub were gates for people who don't already live in them. Expertise ranged from first-time GitHub users to experienced programmers. Four sessions in two days, in a crowded symposium week, was too compressed. The first session carried too much theory, which left too little time for choosing a project. The first exercise had a bug: assistants surveyed participants instead of reading their own history. And recording depended on manual commands, so only two of the four plenaries were captured.</p>
<p><strong>The bridge stayed open, and that is the finding.</strong> Individual tooling is getting easy, and getting several people's setups to work together is where the difficulty is. That is the same question our <a href="https://npc.here.now/protocolvision/research/">research</a> asks about agents in organizations.</p>
<p><strong>Next time.</strong> Show-and-tell first, then theory, then more show-and-tell. Inventory, then choose a project, then build it, at one session a day over a calmer week. Plan on about three facilitators for ten attendees, because learning AI is closer to an apprenticeship than a course. Grow through an apprenticeship ladder: come to one workshop, then help facilitate the next. The full <a href="https://github.com/protocolvision/workshop-kitkraft/blob/main/workshop-dev/feedback/2026-09-facilitator-retro.md">facilitator retrospective</a> is in the repo.</p></div>
<p>Sources: the <a href="https://ai.protocolized.dev/kitcraft/">workshop page</a> and the workshop repository's <a href="https://github.com/protocolvision/workshop-kitkraft/tree/main/workshop-dev/feedback">feedback folder</a> (evidence pack generated 23 September 2026, and the facilitator retrospective).</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:56:28 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5k675cyvwhft8rp0wjah3jq30a</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:56:28Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5k675cyvwhft8rp0wjah3jq30a.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5n4k2tw5h82v1qds6a07925bkb:v3</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5n4k2tw5h82v1qds6a07925bkb/</link>
      <title>Research log: full archive imported (39 sessions) — Research log: AI Native Data Operations</title>
      <description><![CDATA[<h1>Research log: AI Native Data Operations</h1>
<p>The working thesis behind the group's 2027 research, revised as sessions, cases, and protocol watching add evidence. Earlier versions stay in this item's changelog.</p>
<h2>Premises</h2>
<p>We treat these as observations that could turn out partial or wrong.</p>
<blockquote class="blyg-transclusion" data-blyg-id="7rgdqqjes9xcj6ny9ab1d8g2j7" data-blyg-version="1"><p><strong>Premise: Abundant cognition.</strong></p>
<div class="blyg-tk-gen"><p>Reading and writing both get cheap. Processing unstructured data (PDFs, rate sheets, forms) and producing software cost a fraction of what they did.</p></div></blockquote>
<blockquote class="blyg-transclusion" data-blyg-id="1pm8hn6z29mahf3bse2ng721ss" data-blyg-version="1"><p><strong>Premise: Distributed agency.</strong></p>
<div class="blyg-tk-gen"><p>Models act, and they run as many instances at once. Swarms of agents show up wherever work is done.</p></div></blockquote>
<blockquote class="blyg-transclusion" data-blyg-id="6xz12yg4hsgw589ta7d070hdvq" data-blyg-version="1"><p><strong>Premise: Mediation.</strong></p>
<div class="blyg-tk-gen"><p>Information increasingly flows through models: people and agents find, read, and exchange it by way of LLMs and the protocols that connect them.</p></div></blockquote>
<h2>Log</h2>
<div class="blyg-tk-gen"><ul>
<li><strong>27 September 2026.</strong> Blyg started. Ten sessions from the past year imported from the Protocol Institute meeting archive as a baseline.</li>
<li><strong>27 September 2026.</strong> First outside corroboration: Pat Grady's (Sequoia) 24 September talk to the Boston College investment committee frames this wave as a revolution in computation, not communication, which supports <em>abundant cognition</em>. It dates long-horizon agents to November 2025 (<em>distributed agency</em>) and describes AI-native firms moving toward a "network of agents" for internal information flow (<em>mediation</em>). It says nothing about coordination between many agents, which is where this project goes further.</li>
<li><strong>27 September 2026.</strong> Imported the rest of the archive: all 39 sessions since February 2023 are now on the blyg, six of them with raw recording notes.</li>
</ul></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:59 GMT</pubDate>
      <dc:creator>Rafael Fernández</dc:creator>
      <blyg:id>5n4k2tw5h82v1qds6a07925bkb</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>3</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5n4k2tw5h82v1qds6a07925bkb.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:76fv9amnt4bzbc9d498vz3bkjw:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/76fv9amnt4bzbc9d498vz3bkjw/</link>
      <title>SIGPfB Study Group: Protocols for Business Discussion</title>
      <description><![CDATA[<h1>SIGPfB Study Group: Protocols for Business Discussion</h1>
<p><em>Session of 26 February 2023.</em> Participants: rafa_0x, sachbenny, timber1997, nicolascero, thewanderingeditor, zhgnv, scottwerner.</p>
<div class="blyg-tk-gen"><p>The SIGPfB study group convened to discuss protocols for business, with Rafa leading by sharing key resources on token economics, protocol consulting, and related tools. The meeting centered on refining the group's approach and objectives, with participants questioning whether the initial focus on protocol literacy was sufficiently ambitious or concrete. Sachbenny, Timber, and the Wandering Editor pushed for the group to define specific tasks and interventions rather than remaining at the theoretical level. A key framing emerged from Rafa's observation that AI infrastructure operates more like utilities (AWS/Azure) than traditional SaaS, fundamentally changing business model considerations. The group also discussed balancing the role of the Protocol Institute in guiding versus enabling community-led development, with recognition that their initial judgments would likely be imperfect but necessary to move forward.</p>
<p><strong>Key points</strong></p>
<ul>
<li>AI should be understood closer to cloud utilities (AWS/Azure) than traditional SaaS, requiring different infrastructure management approaches.</li>
<li>Protocol literacy alone is insufficient as an outcome; the group needs to define concrete tasks and steps to achieve desired outcomes rather than just building knowledge.</li>
<li>There's tension between the group taking the lead on developing interventions versus equipping others to do so, requiring careful balance.</li>
<li>The group acknowledged their initial approach is exploratory with uncertain judgment, but emphasized the importance of starting somewhere and iterating.</li>
<li>Scott Werner's coding approach emphasizes allowing AI models to generate ideas and then refining, rather than prescriptive upfront specifications.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2023-02-26-sigpfb-study-group-protocols-for-business-discussion">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2023-02-26-sigpfb-study-group-protocols-for-business-discussion/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>76fv9amnt4bzbc9d498vz3bkjw</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/76fv9amnt4bzbc9d498vz3bkjw.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:6vf7c79wvvdakq3aj2jf9j2x78:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/6vf7c79wvvdakq3aj2jf9j2x78/</link>
      <title>Protocols for Business: AI in Legal Practice and Knowledge Transfer</title>
      <description><![CDATA[<h1>Protocols for Business: AI in Legal Practice and Knowledge Transfer</h1>
<p><em>Session of 26 August 2024.</em> Participants: rafa_0x, jdbb.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed how AI is reshaping legal work at an organization led by Jeff. Rather than autonomous drafting, AI serves as an editor and thought partner—handling redlining, clause rewrites, and document research while Jeff maintains ultimate responsibility and judgment. The tool reduced outside counsel usage from ~5 hours to ~30 minutes per issue by handling basics so Jeff could arrive with sharper questions. However, a critical constraint emerged: the public training corpus on many legal topics is deeply imprecise (~80% unreliable), causing AI to deliver confident but incorrect answers repeatedly.</p>
<p><strong>Key points</strong></p>
<ul>
<li>AI makes 'mud' (ambiguous, imprecise legal concepts) cheap to produce, but the training corpus on many legal topics is ~80% imprecise or wrong, causing confident but incorrect outputs that require human re-education each session.</li>
<li>The core structural risk is not automation of legal work itself, but the loss of junior lawyer mentoring opportunities—legal is fundamentally a mentoring profession where judgment development depends on apprenticeship.</li>
<li>Accountability cannot be decentralized: bar association licensing, malpractice liability, and executive signature authority remain concentrated control points precisely because AI has no accountability constraint.</li>
<li>A fractional GC model works for early-stage startups (10-20 people), but beyond that scale, a full-time accountable legal person becomes structurally necessary.</li>
<li>Multiple frontier models with concordance analysis (running the same question across different AI systems) emerges as a risk mitigation strategy for high-stakes legal questions.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2024-08-26-protocols-for-business-ai-in-legal-practice-and-knowled">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/4f5e98797937c03d2c113a70b532dc5daad5e40a/sigs/sigpfb/2024-08-26-protocols-for-business-ai-in-legal-practice-and-knowled/index.html">PI website commit 4f5e987</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>6vf7c79wvvdakq3aj2jf9j2x78</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6vf7c79wvvdakq3aj2jf9j2x78.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:07vp7d0d4s259epxv8114s1fsv:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/07vp7d0d4s259epxv8114s1fsv/</link>
      <title>SIGPfB Optional Meeting - Water Protocols and Agent Framework Discussion</title>
      <description><![CDATA[<h1>SIGPfB Optional Meeting - Water Protocols and Agent Framework Discussion</h1>
<p><em>Session of 16 March 2025.</em> Participants: rafa_0x, drevius., timber1997.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group convened on March 16, 2025 to discuss developments in water data management protocols and explore conceptual frameworks for agent-based systems. Rafa shared links to the Water Protocols repository and Version 3 documentation for team review. A key discussion point emerged around the nature of agents, with Rafa proposing that agents function as 'lenses'—a metaphor suggesting they provide specific perspectives or interaction points through which users engage with broader systems. This concept was illustrated through an analogy comparing agents to putting on glasses to see better. The group also identified potential for developing bonus articles around their technical work. Drevius contributed thoughts on the ongoing conversation, while Timber suggested leveraging diagram analysis and documentation as content opportunities.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Agents function as lenses through which we interact with and perceive systems, providing a specific perspective or framework for engagement.</li>
<li>Water Protocols Version 3 has been released and is available for review in the shared documentation.</li>
<li>The group identified opportunities for creating supplementary content (bonus articles) based on their technical discussions.</li>
<li>The conversation involved visual diagram analysis with requests for detailed unpacking and clarification of complex concepts.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-03-16-sigpfb-optional-meeting-water-protocols-and-agent-frame">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-03-16-sigpfb-optional-meeting-water-protocols-and-agent-frame/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>07vp7d0d4s259epxv8114s1fsv</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/07vp7d0d4s259epxv8114s1fsv.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5xjs9gmcnfzc13tkpad6c7ecta:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5xjs9gmcnfzc13tkpad6c7ecta/</link>
      <title>SIGPfB Warm-up Call: Tensions, Metrics, and Non-Events</title>
      <description><![CDATA[<h1>SIGPfB Warm-up Call: Tensions, Metrics, and Non-Events</h1>
<p><em>Session of 30 June 2025.</em> Participants: timber1997, _vgr, stevebeans., anurajenp, thewanderingeditor.</p>
<div class="blyg-tk-gen"><p>This warm-up call for the SIGPfB group introduced a working document exploring protocols for business, focusing on tensions, metrics, and decision-making tradeoffs. The discussion centered on how conflicts and tradeoffs are managed: timber1997 argued that explicitly flagging conflict creates stable long-term equilibria rather than temporary detentes vulnerable to power shifts. The group explored how single dominant metrics (like square footage or fuel efficiency) drive individual optimization that can undermine system-level values. A major theme emerged around psychological asymmetries in motivation: stevebeans_, with support from Claude AI analysis, identified that people experience greater satisfaction watching positive metrics climb than in maintaining absence of negative outcomes. The conversation touched on the difficulty of accounting for non-events—prevented harms and avoided conflicts—which lack the clear visibility of actual events, requiring proxy measurements instead. Throughout, participants questioned what gets optimized versus what should be zero, and what tradeoffs are being made implicitly when choosing metrics.</p>
<p><strong>Key points</strong></p>
<ul>
<li>A 'tension' represents an actively contested tradeoff where compromise equilibrium is subject to renegotiation based on power dynamics, whereas temporary detentes without explicit conflict acknowledgment are unstable.</li>
<li>People are psychologically motivated by watching good numbers increase (e.g., fuel efficiency) more than by preventing bad outcomes (e.g., zero injuries), even when the metrics are logically equivalent frames.</li>
<li>Dominant metrics can destroy less legible values: optimizing for square footage in construction individually maximizes lot usage but erodes privacy and spatial quality at the system level.</li>
<li>Non-events (accidents avoided, conflicts prevented) are notoriously difficult to track and account for compared to observable events, requiring proxy measurements like successful flight hours.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-06-30-sigpfb-warm-up-call-tensions-metrics-and-non-events">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/7ba36904c9b9d6a34173db26d95963762f1b07c2/sigs/sigpfb/2025-06-30-sigpfb-warm-up-call-tensions-metrics-and-non-events/index.html">PI website commit 7ba3690</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5xjs9gmcnfzc13tkpad6c7ecta</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5xjs9gmcnfzc13tkpad6c7ecta.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:26w74wk62bs9rnncpvhmf2hddw:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/26w74wk62bs9rnncpvhmf2hddw/</link>
      <title>SIGPfB Meeting: Collaborative Book Project on Organizational Tensions</title>
      <description><![CDATA[<h1>SIGPfB Meeting: Collaborative Book Project on Organizational Tensions</h1>
<p><em>Session of 14 July 2025.</em> Participants: timber1997, rafa_0x.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed an ambitious collaborative book project on organizational tensions and protocols for business. Timber1997 proposed transforming ongoing group discussions into an open book treating organizations as networks of tension knots, building on Gareth Morgan's organizational theory framework. Rafa_0x outlined a practical methodology leveraging LLMs: overproduce diverse content types (meeting syntheses, essays, tweets, curated comments) and overcurate through tensions analysis to identify new metaphorical lenses. The group would practice this iteratively before documenting the methodology and its outcomes. Key discussions included using NotebookLM for synthesis and deliberately narrowing scope by starting with just 1-2 case study rows to avoid the consensus bottleneck that participants acknowledged as time-intensive.</p>
<p><strong>Key points</strong></p>
<ul>
<li>LLMs can facilitate collective writing by overproducing content (meeting syntheses, essays, comments) and overcurating it through tensions analysis lenses.</li>
<li>The group proposes an iterative approach: practice the methodology extensively, then document 'how we do it' and the outcomes of this perspective.</li>
<li>Project scope management is critical; participants suggested starting with just 1-2 rows for the first case study rather than attempting comprehensive consensus.</li>
<li>Timber proposed extending Gareth Morgan's 'Images of Organization' by treating organizations as networks of tension knots, though participants felt the initial scope was too ambitious.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-07-14-sigpfb-meeting-collaborative-book-project-on-organizati">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-07-14-sigpfb-meeting-collaborative-book-project-on-organizati/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>26w74wk62bs9rnncpvhmf2hddw</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/26w74wk62bs9rnncpvhmf2hddw.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:337bj2a8g6cdhnr6ntmn1rpwpw:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/337bj2a8g6cdhnr6ntmn1rpwpw/</link>
      <title>SIGPfB Async Discussion: In-Stream vs. In-Structure Tension Management</title>
      <description><![CDATA[<h1>SIGPfB Async Discussion: In-Stream vs. In-Structure Tension Management</h1>
<p><em>Session of 28 July 2025.</em> Participants: timber1997, _vgr, rafa_0x, plague_year.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group held an async discussion on a preprint paper about managing tensions in business protocols. Due to quorum issues, participants engaged asynchronously with two guiding prompts about why certain tensions are managed in-stream versus in-structure, and risks of managing tensions in the wrong medium.</p>
<p><strong>Key points</strong></p>
<ul>
<li>In-structure protocols evolve in step-changes but have continuous effects, while in-stream protocols evolve incrementally and are enacted discretely based on individual interactions.</li>
<li>In-stream tension management (coaching, apprenticeships) is often invisible in documentation but critically valuable for network deepening, whereas in-structure expertise proves valuable for cross-network transitions.</li>
<li>Crypto's rigid permission model for structural changes forces greater reliance on tactical in-stream maneuvering, making informal management practices unusually important.</li>
<li>Attempting to implement in-stream technologies (like LLM chatbots) as rigid structures is a category failure that likely dooms adoption; they work better as discretionary tools.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-07-28-sigpfb-async-discussion-in-stream-vs-in-structure-tensi">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-07-28-sigpfb-async-discussion-in-stream-vs-in-structure-tensi/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>337bj2a8g6cdhnr6ntmn1rpwpw</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/337bj2a8g6cdhnr6ntmn1rpwpw.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:6dsf3bgar0an6g3dsh3kd1w2cf:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/6dsf3bgar0an6g3dsh3kd1w2cf/</link>
      <title>SIGPfB: LLM Adoption Capability Maturity Models and Protocol Evolution</title>
      <description><![CDATA[<h1>SIGPfB: LLM Adoption Capability Maturity Models and Protocol Evolution</h1>
<p><em>Session of 11 August 2025.</em> Participants: timber1997, _vgr, rafa_0x, sachbenny, anurajenp.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group engaged in an extended discussion about developing a comprehensive Capability Maturity Model (CMM++) specifically designed to describe how organizations mature in their adoption and integration of Large Language Models. Rather than treating LLM adoption as a generic management trend, participants analyzed how protocols and practices must evolve at different organizational maturity levels, using a framework that captures technical capability, political dimensions, and business unbundling/disruption dynamics.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Organizations are adapting workflows to match LLM capabilities rather than forcing LLMs into existing processes—teams switching from PowerPoint to memos because LLMs excel at memo generation rather than slide design.</li>
<li>A CMM++ framework should include political dimensions and (un)bundling dynamics beyond traditional capability maturity, with each level defining key tensions, emerging protocols, and organizational states.</li>
<li>Levels 1-3 represent an 'uncanny valley' where organizations appear to be using AI but haven't fundamentally transformed, while levels 4-6 represent genuine discontinuous organizational performance shifts similar to continuous deployment adoption.</li>
<li>Regulatory frameworks (state strength vs. law strength) will determine whether organizations face predatory pricing pressure, state control, or compliance-driven maturation in AI model selection and deployment.</li>
<li>Political alignment among human participants within organizations matters more than AI alignment itself, as it determines which AI models are adopted and how organizational culture constrains AI tool selection.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-08-11-llm-adoption-capability-maturity-models-and-protocol-ev">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-08-11-llm-adoption-capability-maturity-models-and-protocol-ev/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>6dsf3bgar0an6g3dsh3kd1w2cf</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6dsf3bgar0an6g3dsh3kd1w2cf.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:1ad6we5t3t1gb0q5azqf6f4w3t:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/1ad6we5t3t1gb0q5azqf6f4w3t/</link>
      <title>Planetary Thinking for CMMs: LLM Maturity Levels and Political Frameworks</title>
      <description><![CDATA[<h1>Planetary Thinking for CMMs: LLM Maturity Levels and Political Frameworks</h1>
<p><em>Session of 25 August 2025.</em> Participants: sachbenny, rafa_0x, timber1997, drevius..</p>
<div class="blyg-tk-gen"><p>The SIGPfB group applied Yuk Hui's philosophical framework to understand how Large Language Models mature through five distinct levels, from toys to planetary-scale intelligence infrastructure. Rather than treating LLM adoption as a monolithic phenomenon, participants mapped different political dynamics at each level: personal copyright anxieties (Level 1), union-style institutional resistance (Level 2), standards wars and regulation battles (Level 3), competitive adoption cycles (Level 4), and finally planetary infrastructure requiring reimagined governance (Level 5). The discussion drew parallels to historical technologies like shipping containers, nuclear energy, and cloud computing to illustrate how tools eventually become ambient infrastructure that reshape business, law, and geopolitics.</p>
<p><strong>Key points</strong></p>
<ul>
<li>LLMs progress through distinct maturity levels with different political manifestations: Level 1 (personal politics, copyright debates) → Level 5 (planetary infrastructure requiring new governance models and potentially legal entity status).</li>
<li>Technology adoption is non-linear across domains; self-driving cars already function at infrastructure level (Level 4-5) while business copywriting remains at tool stage (Level 2), suggesting different regulatory and business approaches are needed simultaneously.</li>
<li>At Level 5 maturity, LLMs may become so embedded in infrastructure that they require legal frameworks similar to those proposed for rivers and natural entities, with organizations becoming their own digitized entities that users interface with directly.</li>
<li>Market incentives create opposing pressures: lagging players will advocate for commons-based LLMs while leaders push for monopolistic control, potentially triggering LLM nationalization similar to nuclear energy or GPS.</li>
<li>Current unauthorized employee AI use (44% of workers uploading sensitive data to public platforms) reveals a critical gap between organizational policy and actual adoption, foreshadowing Level 3-4 institutional tensions.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-08-25-planetary-thinking-for-cmms-llm-maturity-levels-and-pol">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-08-25-planetary-thinking-for-cmms-llm-maturity-levels-and-pol/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>1ad6we5t3t1gb0q5azqf6f4w3t</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/1ad6we5t3t1gb0q5azqf6f4w3t.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:7mffk19ykqyqc54qs4vnnkw938:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/7mffk19ykqyqc54qs4vnnkw938/</link>
      <title>SIGPfB August 27-29: LLM Failure Modes and Business Strategy</title>
      <description><![CDATA[<h1>SIGPfB August 27-29: LLM Failure Modes and Business Strategy</h1>
<p><em>Session of 27 August 2025.</em> Participants: sachbenny, rafa_0x, timber1997.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group conducted a working session exploring failure modes of large language models in business applications. The discussion identified specific failure patterns such as 'clank-o-mation' (context window loss), 'bug overload' (recursive error stacking), and 'humanwashing' (flawed automation). Notably, the group recognized these LLM failures as isomorphic to traditional team failures—when organizations lose track of execution goals or compound errors through misdiagnosis.</p>
<p><strong>Key points</strong></p>
<ul>
<li>LLM failures mirror traditional team failures: getting lost in execution and becoming buried under compounding half-hazard solutions (the 'Frankenstein' problem).</li>
<li>Machine-readability emerged as a dual-edge strategic capability: becoming illegible to machines offers protection, while hyper-legibility enables dominance in LLM integration ecosystems.</li>
<li>The evidence suggests younger workers' skill overlap with LLM capabilities makes them more vulnerable to replacement, creating a strategic imperative around how workers position themselves.</li>
<li>Two distinct business models have viability: remaining an offline niche with proprietary secrets, or optimizing for maximum machine-legibility to capture digital demand at scale.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-08-27-sigpfb-august-27-29-llm-failure-modes-and-business-stra">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-08-27-sigpfb-august-27-29-llm-failure-modes-and-business-stra/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>7mffk19ykqyqc54qs4vnnkw938</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/7mffk19ykqyqc54qs4vnnkw938.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:2c6dqfpj57n1tcn9nm23kg9j6x:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/2c6dqfpj57n1tcn9nm23kg9j6x/</link>
      <title>AI's Sacred Cow: Technology's Challenge to Pre-AI Knowledge Work</title>
      <description><![CDATA[<h1>AI's Sacred Cow: Technology's Challenge to Pre-AI Knowledge Work</h1>
<p><em>Session of 8 September 2025.</em> Participants: timber1997, sachbenny, rafa_0x, drevius., stevebeans., amitashu, xxaudemarsxx, kpats, _vgr.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group explored which core commitments of pre-AI knowledge work are most directly challenged by AI adoption—what constitutes AI's 'sacred cow.' Through case studies spanning spreadsheets, PowerPoint, procedural generation in games, and even air conditioning, participants identified recurring patterns: technologies systematically overturn beliefs about what requires human effort, specialized skill, or centralized control. The group observed that sacred cows often intertwine with craftmanship, professional identity, and power dynamics. In finance, spreadsheets inverted the bottleneck from recalculation to decision-making; in presentation software, visual design shifted from expensive specialists to democratized capability.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Technology adoption patterns show consistent inversion: static→fluid, central power→individual execution, production→editorializing. Sacred cows are often tied to power dynamics and perceived craftmanship.</li>
<li>AI adoption presents a barrier: mediocre output is now on-tap, making effort an unreliable signal of quality. This creates psychological resistance ('using this technology is cheating') even as it enables higher throughput.</li>
<li>Post-LLM knowledge work rewards scanning, synthesis, and evaluation skills over rote production. Broad reading and contextual judgment become more valuable than time spent on execution.</li>
<li>The work transformation manifests as bimodal: either workers become editors/curators of AI output, or they face commodification. The 'job' shifts from producing work to detecting and refining AI-generated options.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-09-08-ai-s-sacred-cow-technology-s-challenge-to-pre-ai-knowle">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-09-08-ai-s-sacred-cow-technology-s-challenge-to-pre-ai-knowle/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>2c6dqfpj57n1tcn9nm23kg9j6x</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/2c6dqfpj57n1tcn9nm23kg9j6x.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:7acj823ngyq1kvqp5enscxgz8a:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/7acj823ngyq1kvqp5enscxgz8a/</link>
      <title>AI's Impact on Individual vs. Organizational Capability and Business Scaling</title>
      <description><![CDATA[<h1>AI's Impact on Individual vs. Organizational Capability and Business Scaling</h1>
<p><em>Session of 22 September 2025.</em> Participants: timber1997, sachbenny, rafa_0x, stevebeans., thewanderingeditor, oneiromancer2665.</p>
<div class="blyg-tk-gen"><p>The group discussed a reading about how AI empowers individuals to rival collective organizations. While participants agreed this is happening now, they challenged the article's assumption that this represents a stable equilibrium. Rafa noted that scaling capability is accessible to mediocre practitioners ('slopsunami'), creating secondary negative consequences the piece ignores. The discussion surfaced the 'LeBron effect'—where organizations funnel resources to superstars until the team levels up—which creates retention risks and potential single points of failure.</p>
<p><strong>Key points</strong></p>
<ul>
<li>While AI currently empowers individuals to rival organizations, this is likely an unstable equilibrium—as capability spreads, networking effects will reassert organizational advantages and create new coordination problems.</li>
<li>The article's analysis assumes competence in scaling, but most accessible AI scaling will be mediocre ('slopsunami'), creating secondary consequences the original piece omits.</li>
<li>Organizations face a dilemma: superstars powered by AI create single points of failure and retention risk, while overcompensating for this creates its own failure modes.</li>
<li>Viable businesses with natural scaling caps (40-60mm ARR range) may become more attractive, and private equity may pursue opportunities to automate and revamp low-margin businesses rather than pursuing venture-style hypergrowth.</li>
<li>Protected labor markets, legacy infrastructure, and regulatory friction (like French labor law) may accidentally become competitive moats against AI disruption, at least temporarily.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-09-22-ai-s-impact-on-individual-vs-organizational-capability">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-09-22-ai-s-impact-on-individual-vs-organizational-capability/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>7acj823ngyq1kvqp5enscxgz8a</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/7acj823ngyq1kvqp5enscxgz8a.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5wrgcekv18bqrhjernymhja94a:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5wrgcekv18bqrhjernymhja94a/</link>
      <title>SIGPfB: Protocols for Business Discussion - AI Adoption and Protocol Design</title>
      <description><![CDATA[<h1>SIGPfB: Protocols for Business Discussion - AI Adoption and Protocol Design</h1>
<p><em>Session of 20 October 2025.</em> Participants: rafa_0x, sachbenny, oneiromancer2665, timber1997, thewanderingeditor, ccarella, _vgr, drevius..</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed the intersection of protocol design and AI adoption in business contexts. The meeting opened with a proposal to publish a case study on protocolized practices for HBR-style articles, with objectives including an AI Adoption Workshop rerun and exploration of organizational design for SIGs. The core discussion centered on how protocols function as constraint systems that create stability through impossibilities and rigidity, drawing parallels to how protocols should address AI adoption risks.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Protocols function by converting smooth behavior spaces into striated ones through constraints and impossibilities, which should be viewed as features rather than bugs for stability and predictability.</li>
<li>Sincere disclosure of LLM use is a foundational norm that companies should adopt, though current incentive structures (engagement metrics) may discourage transparency in practice.</li>
<li>Society tends to over-correct after acute AI failures while neglecting chronic risks; the chronic vs. acute framework should guide response strategies to avoid unnecessary rigid controls.</li>
<li>Management is uniquely vulnerable to accepting low-quality LLM outputs because there is less organizational pressure to escalate poor upward communication compared to downward communication.</li>
<li>Workplace norms, coaching, and triangulation practices are more immediately effective than policy-based approaches for responsible AI adoption, though policies may need to backstop these cultural measures.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-10-20-protocols-for-business-discussion-ai-adoption-and-proto">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-10-20-protocols-for-business-discussion-ai-adoption-and-proto/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5wrgcekv18bqrhjernymhja94a</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5wrgcekv18bqrhjernymhja94a.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:43dezzfzy2n2cczmdeb0cr4shc:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/43dezzfzy2n2cczmdeb0cr4shc/</link>
      <title>SIGPfB Optional Discussion: Time Estimation Chaos &amp; Protocol Development Approach</title>
      <description><![CDATA[<h1>SIGPfB Optional Discussion: Time Estimation Chaos &amp; Protocol Development Approach</h1>
<p><em>Session of 24 November 2025.</em> Participants: rafa_0x, drevius., timber1997, sachbenny.</p>
<div class="blyg-tk-gen"><p>Rafa opened the discussion by proposing a return to basics on the Time Estimation Chaos topic to enable meaningful analysis and protocol development. Drevius responded with a pragmatic framework emphasizing that item 3 (tension definition and protocol solutions) offers the best return on investment, while the Fat vs. Lean concept hasn't yet resonated. He advocated for producing small, practical tools through terse, dense documentation rather than exploring broad conceptual worldviews. Drevius offered to create a cohesive visual design system (consistent colors and fonts) for the PBR series, similar to what was done for the tensions article, to ensure professional consistency across outputs.</p>
<p><strong>Key points</strong></p>
<ul>
<li>The group should return to foundational concepts around Time Estimation Chaos to enable deeper understanding and discussion, rather than building on incomplete prior work.</li>
<li>Drevius advocates for practical, small-scale tools over broad worldview changes, and emphasizes that tight, well-scoped outputs (terse prose and dense diagrams) will produce stronger results than meandering discussions.</li>
<li>A consistent visual design system (color palette, fonts, diagram style) should be established for the PBR series to ensure coherent documentation across case studies.</li>
<li>Focusing on nailing case studies and the PBR medium first will organically reveal what to do with the work long-term, making upfront specification of distant goals unnecessary.</li>
<li>The group should be willing to cut ideas that don't serve the core work, following a principle from fiction writing of 'killing your darlings' when needed.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-11-24-sigpfb-optional-discussion-time-estimation-chaos-protoc">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-11-24-sigpfb-optional-discussion-time-estimation-chaos-protoc/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>43dezzfzy2n2cczmdeb0cr4shc</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/43dezzfzy2n2cczmdeb0cr4shc.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:6hjkrqtnp7qywf7gpzqwfpxm6d:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/6hjkrqtnp7qywf7gpzqwfpxm6d/</link>
      <title>Protocols for Business: LLM Governance and Organizational Decision-Making</title>
      <description><![CDATA[<h1>Protocols for Business: LLM Governance and Organizational Decision-Making</h1>
<p><em>Session of 1 December 2025.</em> Participants: rafa_0x, timber1997, ggnore999, sachbenny, drevius..</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed emerging protocols for managing LLM usage in organizations, building on the conceptual framework of multisig governance. The conversation centered on how multisigs function as decision-tempo stabilizers that counteract rapid iteration cycles, preventing catastrophic variance in critical decisions. Participants explored which organizational activities should mandate LLM involvement—particularly legal review, knowledge acquisition, and communications—versus which activities should prohibit LLM use, such as deploying systems the organization doesn't fully understand.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Multisig systems function as 'counterpoint protocols' that deliberately slow decision tempo to prevent catastrophic variance in critical smart contract decisions, contrasting with Lean's MVP acceleration model.</li>
<li>Organizations should mandate LLM usage for legal review, learning unfamiliar topics, and communications guidance—while prohibiting deployment of systems the organization doesn't understand.</li>
<li>The critical distinction is that all non-confidential content should go through LLM processing, but not all processed content should reach publication or production, requiring governance layers between review and deployment.</li>
<li>LLM-in-the-loop signing processes where prompts and reviews are mandatory (though not binding) can force beneficial tempo downshifts while maintaining organizational flexibility.</li>
<li>Clear policies are needed to prevent confidential personnel or company information from being uploaded to personal LLMs, while keeping non-confidential information LLM-accessible.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-12-01-protocols-for-business-llm-governance-and-organizationa">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-12-01-protocols-for-business-llm-governance-and-organizationa/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>6hjkrqtnp7qywf7gpzqwfpxm6d</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6hjkrqtnp7qywf7gpzqwfpxm6d.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:53kaq2sn8rf43f4pej2rf9r4t2:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/53kaq2sn8rf43f4pej2rf9r4t2/</link>
      <title>SIGPfB Dec 29th Meeting: Protocol Thinking as Design Framework</title>
      <description><![CDATA[<h1>SIGPfB Dec 29th Meeting: Protocol Thinking as Design Framework</h1>
<p><em>Session of 29 December 2025.</em> Participants: rafa_0x, timber1997.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group met to refine their framing of protocols in business contexts. A core tension emerged: how to shift readers from abstract protocol theory to embodied recognition of protocols everywhere. The group settled on speed/time as a powerful oblique lens—when one business wheel accelerates (e.g., Slack adoption), it can create dead time and coordination strain elsewhere, revealing implicit protocols that were previously invisible. They identified Boom Supersonic's calendar-versus-communication misalignment as the anchor case, with Y2K and version control as supporting examples. A critical insight was audience clarity: the stated target is senior executives, but the actual primary reader is likely the analyst or staff layer adjacent to leadership. The group concluded that effective writing must alternate between 2–3 sentences of conceptual work and a return to vivid, grounded examples to maintain reader engagement and legibility.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Protocol thinking is primarily about learning to see existing coordination structures; disruptive events (COVID, Y2K) make implicit constraints legible and turn them into explicit design objects.</li>
<li>Speed and temporal regime changes create protocol strain; the goal is to arm senior managers with a diagnostic lens to recognize where existing protocols fail under new scale/speed conditions.</li>
<li>Writing strategy must alternate between conceptual explanation and vivid concrete examples; the primary audience is mid-level analysts/staff who read carefully and then retell to executives, not executives reading directly.</li>
<li>Protocols function as safety and variance-management mechanisms; design trades are central—you gain new protection in one dimension at the cost of constraints in another.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-12-29-sigpfb-dec-29th-meeting-protocol-thinking-as-design-fra">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-12-29-sigpfb-dec-29th-meeting-protocol-thinking-as-design-fra/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>53kaq2sn8rf43f4pej2rf9r4t2</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/53kaq2sn8rf43f4pej2rf9r4t2.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:16gdj1jc4jntda17wmtsest0mp:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/16gdj1jc4jntda17wmtsest0mp/</link>
      <title>PfB SIG January 26, 2026: Vibe Code Updates</title>
      <description><![CDATA[<h1>PfB SIG January 26, 2026: Vibe Code Updates</h1>
<p><em>Session of 26 January 2026.</em> Participants: sachbenny, stevebeans., rafa_0x, zhgnv, timber1997, plague_year.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed advances in 'vibe coding'—using LLMs to generate code through constraint-driven, iterative workflows. Participants noted that vibe coding excels at failure delay but struggles with originality, as LLM-generated code tends to regress to median patterns present in training data. A critical reframe emerged: coding with LLMs is fundamentally project management work—orchestrating agents, subagents, and constraints rather than direct implementation. The group highlighted the importance of recognizing 'software-shaped problems' to avoid wasting effort on non-software solutions. Practical examples included local-memory approaches like Clawd Code and real-world applications like zhgnv's vibecoded wiki parser using MCPs. The discussion concluded with concerns about asymmetric pressure on open source maintainers from AI-generated contributions, drawing parallels to previous infrastructure challenges.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Vibe-coded projects tend to revert to mediocre, zeitgeist-aligned patterns because they reflect the model's training data rather than novel solutions.</li>
<li>Coding with LLMs is fundamentally closer to project management than traditional coding, requiring orchestration and constraint navigation rather than technical implementation.</li>
<li>Homebrew tooling and local-first approaches (like Clawd Code using local memory) are becoming more accessible, shifting what was previously hobby-programmer territory into mainstream capability.</li>
<li>The emerging 'agent setup' problem mirrors historical 'dev environment setup' friction, suggesting new tooling paradigms may introduce their own configuration overhead.</li>
<li>AI-generated contributions create asymmetric pressure on open source maintainers, potentially flooding commons with low-quality PRs.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-01-26-pfb-sig-january-26-2026-vibe-code-updates">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-01-26-pfb-sig-january-26-2026-vibe-code-updates/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>16gdj1jc4jntda17wmtsest0mp</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/16gdj1jc4jntda17wmtsest0mp.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:4dgkw6cvr1nv9sqv72s46tm8xc:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/4dgkw6cvr1nv9sqv72s46tm8xc/</link>
      <title>SIGPfB Orienteering: Protocols, AI Agents, and Business Optimization</title>
      <description><![CDATA[<h1>SIGPfB Orienteering: Protocols, AI Agents, and Business Optimization</h1>
<p><em>Session of 16 February 2026.</em> Participants: rafa_0x, timber1997.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group held an optional orienteering meeting to identify key themes for the protocols-for-business initiative. Rafa outlined six priority topics including the distinction between installation/deployment, reproducibility, annealing processes, AI assistance models, user-generated software, and runtime procurement. The group discussed a science fiction analogy about machine language programmers discovering spaceship optimizations that higher-level AI abstractions had missed over centuries of optimization, suggesting that excessive abstraction can obscure valuable opportunities. The meeting touched on practical concerns including reproducibility and the appropriate role of LLMs in business contexts, with Rafa beginning to explore where LLMs actually provide business value.</p>
<p><strong>Key points</strong></p>
<ul>
<li>There is a conceptual distinction between AI assistance (abstraction layers) and true agents that warrants exploration for business protocol design.</li>
<li>Low-level optimization opportunities may be missed when systems rely entirely on AI abstractions; domain-specific knowledge can uncover novel solutions that broad AI optimization misses.</li>
<li>Milestone Saves documentation has been established as a reference point for tracking progress in this working group.</li>
<li>The group is exploring where LLMs provide genuine business value versus where they add unnecessary abstraction layers.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-02-16-sigpfb-orienteering-protocols-ai-agents-and-business-op">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-02-16-sigpfb-orienteering-protocols-ai-agents-and-business-op/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>4dgkw6cvr1nv9sqv72s46tm8xc</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/4dgkw6cvr1nv9sqv72s46tm8xc.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:0z126y7nq330tefmbwjxnghbkg:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/0z126y7nq330tefmbwjxnghbkg/</link>
      <title>Study Group: Protocols for Business - AI Models, World Simulation, and Data Requirements</title>
      <description><![CDATA[<h1>Study Group: Protocols for Business - AI Models, World Simulation, and Data Requirements</h1>
<p><em>Session of 23 March 2026.</em> Participants: rafa_0x, timber1997, drevius..</p>
<div class="blyg-tk-gen"><p>The SIGPfB study group discussed emerging approaches to AI model architecture, particularly the shift toward video-anchored systems rather than text-based ones. Participants explored the implications of this shift, including massive increases in computational demands and the need for continued data labeling at scale. A key insight emerged from discussion of the fruit fly brain simulation: the specific arrangement of connections—not just their presence or distribution—encodes behavior, suggesting that precision in neural architecture matters fundamentally. The group also touched on philosophical implications around modeling systems that are deeply entangled with their broader context. The conversation concluded with observations about how different user groups—professional power users versus casual adopters—may require different engagement strategies, with high-immersion approaches potentially leading to burnout among professionals while passive approaches suit retail users better.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Video may be easier to obtain fresh and ongoing compared to non-polluted text data, but video-anchored AI systems would dramatically increase demand for compute and electronics.</li>
<li>The precise, specific arrangement of connections in neural networks—not merely their existence or statistical distribution—encodes behavior and computation, as demonstrated by fruit fly brain simulation.</li>
<li>Truly modeling complex systems like atoms requires understanding their full entanglement with the universe, suggesting world models must account for systemic interdependence.</li>
<li>Professional versus retail user dynamics in AI adoption mirror trading markets, where high-immersion power users face burnout while casual users may benefit more from passive approaches.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-03-23-study-group-protocols-for-business-ai-models-world-simu">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-03-23-study-group-protocols-for-business-ai-models-world-simu/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>0z126y7nq330tefmbwjxnghbkg</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/0z126y7nq330tefmbwjxnghbkg.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:7w846xayfbjm5xbsek2m99a4rr:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/7w846xayfbjm5xbsek2m99a4rr/</link>
      <title>Study Group: Protocols for Business - Business Models and System Design</title>
      <description><![CDATA[<h1>Study Group: Protocols for Business - Business Models and System Design</h1>
<p><em>Session of 6 April 2026.</em> Participants: rafa_0x, timber1997, sachbenny.</p>
<div class="blyg-tk-gen"><p>The SIGPfB study group examined protocols for business with focus on system design philosophy and business economics. The discussion centered on a FERNANDEZ Flow brochure and connections to autonomous worlds literature. Participants debated the transition from flexible to hardened systems, noting that jumping directly to hardened design upfront is problematic. A key insight emerged around business launch economics: as compute costs decrease and can be spent in smaller increments, the barrier to starting ventures may drop below the cost of traditional business planning. The group drew parallels to the "Bitter Lesson" in AI and discussed how right-sizing (similar to how Uber's bikes and scooters expanded the mobility market beyond taxi replacement) could enable new business categories rather than just replacing existing ones.</p>
<p><strong>Key points</strong></p>
<ul>
<li>There is a significant but difficult transition path from current 'soft' code-space to properly hardened systems, requiring careful design rather than rushing upfront hardening.</li>
<li>Launching businesses may become cheaper than writing business plans as compute becomes the primary capital expenditure, spent in smaller, faster increments.</li>
<li>Market expansion occurs not just through cost reduction but through right-sizing offerings to enable new categories of service (e.g., Uber bikes/scooters expanding total rides beyond traditional taxis).</li>
<li>Jay's work advocates for video-game-like environments where agents can be deployed, connecting to broader concepts in autonomous worlds.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-04-06-study-group-protocols-for-business-business-models-and">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-04-06-study-group-protocols-for-business-business-models-and/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>7w846xayfbjm5xbsek2m99a4rr</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/7w846xayfbjm5xbsek2m99a4rr.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:0x5k2qdy0naan8p1j8nhrpft7k:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/0x5k2qdy0naan8p1j8nhrpft7k/</link>
      <title>Study Group: Protocols for Business - API Design and Control Models</title>
      <description><![CDATA[<h1>Study Group: Protocols for Business - API Design and Control Models</h1>
<p><em>Session of 20 April 2026.</em> Participants: rafa_0x, sachbenny.</p>
<div class="blyg-tk-gen"><p>The study group examined API control architectures and protocol viability, with rafa_0x presenting a clarity pitch document for discussion. A key observation centered on the one-way nature of API control mechanisms, where ownership can modify parameters but users cannot, which rafa_0x considers a suboptimal design choice. This critique led to broader skepticism about whether MCP will remain a persistent protocol in future implementations.</p>
<p><strong>Key points</strong></p>
<ul>
<li>The API architecture discussed employs one-way control where only the owner can make changes while users cannot, which rafa_0x identifies as a design limitation.</li>
<li>Rafa_0x expresses skepticism about MCP's long-term persistence in the protocol landscape, suggesting it may not be a sustainable solution.</li>
<li>Spreadsheet-based systems provide valuable auditability and enable modeling-assumption review with sign-off on material decisions, with control distributed based on role (analyst discretion vs. clerk limitations).</li>
<li>There is a meaningful distinction in operational control between different stakeholder types—analysts retain decision-making authority while centralized data processing departments operate within constrained parameters.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-04-20-study-group-protocols-for-business-api-design-and-contr">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-04-20-study-group-protocols-for-business-api-design-and-contr/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>0x5k2qdy0naan8p1j8nhrpft7k</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/0x5k2qdy0naan8p1j8nhrpft7k.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:0kv43nwjjx8eprs3pzcz4tax0t:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/0kv43nwjjx8eprs3pzcz4tax0t/</link>
      <title>SIGPfB Study Group: AI, Robotics, and Technology Adoption Patterns</title>
      <description><![CDATA[<h1>SIGPfB Study Group: AI, Robotics, and Technology Adoption Patterns</h1>
<p><em>Session of 4 May 2026.</em> Participants: rafa_0x, drevius., sachbenny, bah.eth, stevebeans., anurajenp, plague_year, timber1997.</p>
<div class="blyg-tk-gen"><p>The SIGPfB study group discussed multiple interconnected topics centered on robotics and AI adoption. The group reviewed robotics projects and discussed securing funding for hardware. A significant portion of discussion focused on understanding AI/LLM adoption patterns by drawing historical parallels to phreaking and early telephone adoption, with participants noting that rural or marginalized internet populations may be early adopters because they experience greater time constraints that LLMs can address. The conversation explored how robot design and aesthetics impact perception, and highlighted emerging possibilities for robots that can autonomously find ways to fund themselves through local services while maintaining the ability to learn and acquire new capabilities. The group reviewed several projects and resources related to machine behavior and robot autonomy.</p>
<p><strong>Key points</strong></p>
<ul>
<li>LLM adoption may follow patterns similar to phreaking and early telephone adoption, with rural/marginalized internet populations adopting first due to experiencing greater time gaps.</li>
<li>Unlike spatial technologies (phones, cars), LLMs are fundamentally time-related technologies, making adoption driven by those who feel time constraints most acutely.</li>
<li>There is tension in the AI space with engineers repeatedly claiming users are 'using LLMs/agents wrong,' paralleling historical technology adoption friction.</li>
<li>Robots combining autonomous task-finding with useful local services (e.g., hiring themselves as DJs, acquiring necessary equipment) represent an emerging economic model worth exploring.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-05-04-sigpfb-study-group-ai-robotics-and-technology-adoption">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-05-04-sigpfb-study-group-ai-robotics-and-technology-adoption/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>0kv43nwjjx8eprs3pzcz4tax0t</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/0kv43nwjjx8eprs3pzcz4tax0t.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:32m41tjckjjv3pbz3qh09mqsef:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/32m41tjckjjv3pbz3qh09mqsef/</link>
      <title>Protocols for Business: Protocol Fiction Aesthetics and AI-Native Organization</title>
      <description><![CDATA[<h1>Protocols for Business: Protocol Fiction Aesthetics and AI-Native Organization</h1>
<p><em>Session of 18 May 2026.</em> Participants: rafa_0x, _vgr, sachbenny, timber1997, drwip, tomguarriello.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed the etymology of business terminology and explored why certain terms may not make intuitive sense upon scrutiny. The conversation then shifted to developing better communication frameworks for their complex protocol work. A key proposal emerged around using 'terraforming' as a unifying visual metaphor to explain various organizational concepts like factories, rooms, and agent spaces in more accessible ways.</p>
<p><strong>Key points</strong></p>
<ul>
<li>The term 'vertical integration' may derive from physical factory architecture (steam engine shafts) rather than supply chain concepts, though Ford's mines-to-cars integration is likely the actual origin.</li>
<li>A 'terraforming' visual metaphor was proposed to unify discussions of factories, rooms, and agent spaces as a more accessible framework for explaining complex protocols.</li>
<li>Content needs to be LLM-friendly and designed for non-readers, as modern attention spans are limited to tweet-length content, though the underlying reports are substantive.</li>
<li>The group is developing a 'New Nature' branding strategy to make their work accessible to mainstream audiences, positioning technology-created AI protocols as a new layer of natural laws.</li>
<li>AI-native companies and products represent a post-adoption reality where artificial beings operate within this new technological nature, similar to conclusions from distributed AI workshops.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-05-18-protocols-for-business-protocol-fiction-aesthetics-and">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-05-18-protocols-for-business-protocol-fiction-aesthetics-and/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>32m41tjckjjv3pbz3qh09mqsef</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/32m41tjckjjv3pbz3qh09mqsef.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:3nh9rqbg2m07a8p6wb2307mrj6:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/3nh9rqbg2m07a8p6wb2307mrj6/</link>
      <title>Protocols for Business Summer 2026 Direction Discussion</title>
      <description><![CDATA[<h1>Protocols for Business Summer 2026 Direction Discussion</h1>
<p><em>Session of 1 June 2026.</em> Participants: rafa_0x, timber1997, tomguarriello, sachbenny.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group convened on June 1, 2026, to discuss their summer 2026 strategic direction. The meeting focused on accelerating the publication of their blog and CMM documentation on the Protocolized platform, which participants identified as an important checkpoint for their initiatives. Sachbenny advocated for this publication and shared a draft blog document for review. During the discussion, rafa_0x acknowledged Sachin's significant theoretical contributions to the group, particularly his development of concepts such as 'archival time' and 'Kits,' which appear to be central to their protocol work.</p>
<p><strong>Key points</strong></p>
<ul>
<li>The group prioritized publishing the blog and CMM documentation on Protocolized as a checkpoint for their summer initiatives.</li>
<li>Sachin (sachbenny) has emerged as a leading theorist in the group, having coined key concepts including 'archival time' and 'Kits' within protocol theory.</li>
<li>The meeting involved reviewing draft blog content and ensuring alignment on publication across platforms.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-06-01-protocols-for-business-summer-2026-direction-discussion">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/ebea6909f173c8ffc3c0f2806c0f3818c97c3199/sigs/sigpfb/2026-06-01-protocols-for-business-summer-2026-direction-discussion/index.html">PI website commit ebea690</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>3nh9rqbg2m07a8p6wb2307mrj6</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/3nh9rqbg2m07a8p6wb2307mrj6.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:4wxjkf0dt9q97jmkgsw24bayt4:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/4wxjkf0dt9q97jmkgsw24bayt4/</link>
      <title>SIGPfB Branding Discussion and Rebrand Decision</title>
      <description><![CDATA[<h1>SIGPfB Branding Discussion and Rebrand Decision</h1>
<p><em>Session of 22 June 2026.</em> Participants: timber1997.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed rebranding efforts for P4B (Protocols for Business), with timber1997 presenting positive feedback received on the name "Glue Factory" as a potential rebrand candidate. The proposed name was noted as appropriately positioned to convey an agency-style brand identity rather than a large consulting firm aesthetic, which appears to be the desired direction. The participant expressed personal support for the Glue Factory option while acknowledging that consensus exists around the necessity for P4B to undergo rebranding. The final decision on the rebrand was deferred to leadership.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Glue Factory has received positive feedback from multiple stakeholders as a potential rebrand name for P4B.</li>
<li>The proposed name Glue Factory conveys an agency-style brand positioning rather than a large consulting firm approach, which aligns with the group's intended image.</li>
<li>There is consensus that P4B requires a rebrand, with final decision authority resting with leadership.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-06-22-sigpfb-branding-discussion-and-rebrand-decision">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/e4620f8e369aa111d453ff8cd9ea4f38b3eba7f7/sigs/sigpfb/2026-06-22-sigpfb-branding-discussion-and-rebrand-decision/index.html">PI website commit e4620f8</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>4wxjkf0dt9q97jmkgsw24bayt4</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/4wxjkf0dt9q97jmkgsw24bayt4.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:6e9jaz2mmhne7yqgaswt6pdmtd:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/6e9jaz2mmhne7yqgaswt6pdmtd/</link>
      <title>Protocols for Business SIG: Field Journalism in Drone Warfare Era</title>
      <description><![CDATA[<h1>Protocols for Business SIG: Field Journalism in Drone Warfare Era</h1>
<p><em>Session of 13 July 2026.</em> Participants: rafa_0x.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group held a logistics meeting to onboard Bel, a war correspondent with 15 years covering global conflicts including Yemen, Syria, Libya, Ukraine, Gaza, and Lebanon. The meeting was conducted via Google Meet due to Discord's high friction for external guests (requiring account creation and CAPTCHAs). The primary discussion centered on how drone warfare, particularly FPV drones, has fundamentally altered field protocols and behavioral practices for journalists in conflict zones. Unlike traditional artillery threats, FPV drones create a persistent vertical threat requiring constant awareness of appearance from above, necessitating new vehicle selection strategies, pre-planned exit routes, and tactical use of terrain and netting for concealment.</p>
<p><strong>Key points</strong></p>
<ul>
<li>FPV drones fundamentally changed field journalist behavior by creating a persistent threat from above, requiring constant consideration of vertical visibility and establishing new hiding/exit route protocols distinct from traditional artillery zone survival tactics.</li>
<li>Platform friction significantly impacts external participation; Discord's account creation and CAPTCHA requirements made it unsuitable for guest access, leading to a recommendation to use Zoom or Google Meet for future sessions.</li>
<li>Drone warfare has introduced new tactical factors including vehicle camouflage choices (civilian 'rubbish cars' vs. armored vehicles), weather-dependent safety planning, and use of fiber-optic netting corridors as cover.</li>
<li>Harmonica presents a middle-ground deliberative tool between shallow scalable surveys (Google Forms) and deep but hard-to-scale facilitated workshops (Miro), with Artem available to customize it for the group's needs.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-07-13-protocols-for-business-sig-field-journalism-in-drone-wa">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/549b9d6f02b9c417b75075ad623cca4227e7a4c8/sigs/sigpfb/2026-07-13-protocols-for-business-sig-field-journalism-in-drone-wa/index.html">PI website commit 549b9d6</a> · <a href="https://pub-fb4a559f683a4e3b876823eb2bfe12a3.r2.dev/recordings/SIG-P4B/2026-07-13/1082444651946049567_1382801113224581240_1783956687020/summary.md">raw recording notes</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread and recording.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>6e9jaz2mmhne7yqgaswt6pdmtd</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6e9jaz2mmhne7yqgaswt6pdmtd.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5eqnqf0tchv9f8cpp67nscgxn9:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5eqnqf0tchv9f8cpp67nscgxn9/</link>
      <title>Protocols for Business: QWERTY + SIG Ops Planning</title>
      <description><![CDATA[<h1>Protocols for Business: QWERTY + SIG Ops Planning</h1>
<p><em>Session of 26 July 2026.</em> Participants: rafa_0x.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group meeting focused on reading and discussing David's 1985 AER article about the history of the QWERTY typewriter standard. The group examined how Christopher Latham Sholes, a Milwaukee printer with mechanical inclinations, became instrumental in typewriter development despite being only the fifty-second person to invent one. Key discussion points included the surprisingly small market penetration of QWERTY machines in the 1880s (under 5,000 units nationwide) and the critical role that hardware design played in determining technology adoption patterns. Concurrently, the group was also coordinating on a water project report outline and broader SIG operations planning.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Christopher Latham Sholes, the fifty-second typewriter inventor, played a pivotal role in establishing the QWERTY standard despite being a printer and mechanical tinkerer rather than a primary innovator.</li>
<li>The QWERTY typewriter market was extremely limited in the early 1880s, with fewer than 5,000 machines in the entire United States stock, suggesting slow initial adoption.</li>
<li>The discussion highlights how contingent historical outcomes in technology can be, with hardware specifications playing a critical but underexamined role in market dominance.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-07-26-protocols-for-business-qwerty-sig-ops-planning">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/549b9d6f02b9c417b75075ad623cca4227e7a4c8/sigs/sigpfb/2026-07-26-protocols-for-business-qwerty-sig-ops-planning/index.html">PI website commit 549b9d6</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5eqnqf0tchv9f8cpp67nscgxn9</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5eqnqf0tchv9f8cpp67nscgxn9.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:57y3nk7mzn31675n3jhjp2qvpx:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/57y3nk7mzn31675n3jhjp2qvpx/</link>
      <title>SIG-P4B 2026-07-27</title>
      <description><![CDATA[<h1>SIG-P4B 2026-07-27</h1>
<p><em>Session of 27 July 2026.</em> Participants: Sachin, rafa (UTC+1), Javier Chavez / UTC -6, 🙊Andre Comeau.</p>
<div class="blyg-tk-gen"><p>The session used the QWERTY keyboard case to explore path dependence, non-ergodic outcomes, and the "sufficiency" of suboptimal-but-good-enough general-purpose technologies. Discussion turned to whether QWERTY's lock-in argument still holds today given voice dictation, LLMs, and touchscreens. The latter half shifted to group logistics: networking/weak-ties initiatives, a possible rebrand away from "Protocols for Business," and a water-industry pro bono report on data discovery.</p>
<p><strong>Key points</strong></p>
<ul>
<li><strong>Sachin (general-purpose tech &amp; convergence):</strong> For a general-purpose technology, it's hard to call outcomes non-ergodic because such technologies are vast and distributed and tend to converge on an equilibrium or a couple of dominant solutions.</li>
<li><strong>rafa (sufficiency of suboptimal tech):</strong> Linked this to a prior discussion of the "unreasonable sufficiency of protocols" — general-purpose technologies (scissors, paper clips) don't need to be optimal; a "lowest level of functionality" that is good enough gets embedded in society and persists. He speculated there may be a rule (perhaps provable) that adopted standards are always magnitudes suboptimal relative to potential, yet aren't displaced — only "liberated."</li>
<li><strong>Javier (hardware and incentives to standardize):</strong> Wondered whether a standard that lasts must precede hardware; noted the QWERTY setup and drew an analogy to a recently released OpenAI hardware device. Raised the key incentive question: if there's an edge/alpha in <em>not</em> conforming to a rule set, what incentivizes standardization at all? From an efficiency view, the "optimal" result would be everyone adopting the most efficient method (e.g., courtroom stenographers' approach), but that no longer makes sense given voice dictation.</li>
<li><strong>How to unseat an incumbent standard (rafa's prompt):</strong> rafa referenced Sachin's writing on an <strong>annealing process</strong> — you must inject as much energy as inertia has consumed to reset a standard.</li>
<li><strong>Has QWERTY's lock-in argument aged badly? (Sachin):</strong> The 1985 paper turned out to be substantially wrong in the long run — QWERTY is no longer a contested space. Alternatives abound: regional-language keyboards (type in English, convert to regional), voice notes, and touchscreens. He framed QWERTY as an <strong>"ossified chain"</strong> that AI and iPhone touchscreens "liberated," creating new standards for both keyboards and how we talk to computers.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-07-27-sig-p4b-2026-07-27">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/549b9d6f02b9c417b75075ad623cca4227e7a4c8/sigs/sigpfb/2026-07-27-sig-p4b-2026-07-27/index.html">PI website commit 549b9d6</a> · <a href="https://pub-fb4a559f683a4e3b876823eb2bfe12a3.r2.dev/recordings/SIG-P4B/2026-07-27/1082444651946049567_1382801113224581240_1785168048741/summary.md">raw recording notes</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread and recording.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>57y3nk7mzn31675n3jhjp2qvpx</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/57y3nk7mzn31675n3jhjp2qvpx.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:67y187wptkhksfvfhkx5e27bzp:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/67y187wptkhksfvfhkx5e27bzp/</link>
      <title>SIG-P4B 2026-07-30</title>
      <description><![CDATA[<h1>SIG-P4B 2026-07-30</h1>
<p><em>Session of 30 July 2026.</em> Participants: rafa (UTC+1), PAtwater.</p>
<div class="blyg-tk-gen"><p>rafa interviewed PAtwater to develop an anchoring story for a report on why water-rate data standardization is valuable, why it's painful, and why past standardization efforts stalled. PAtwater walked through his early career (hand-scraping ~200 utilities' water rates as an intern), the purpose of rate benchmarking, the failed/fizzled standardization initiatives in California, and the structural reasons standardization never fully took hold. The arc lands on a thesis: standardizing at the data-extraction level is a dead end, but new AI tooling (à la "Maxwell's" approach) could lower the cost of compliance enough to unlock the long-promised value.</p>
<p><strong>Key points</strong></p>
<ul>
<li><strong>PAtwater:</strong> ~a decade in water data. First job was an internship at a large water utility hand-scraping the water rates of ~200 Southern California utilities over a summer — cheaper than paying a consultant (~$50–100k) for a periodic survey.</li>
<li><strong>rafa</strong> reframed the core driver as strategic scenario planning (3% vs 5% vs 10% increases) more than individual customer complaints — PAtwater largely agreed. Rate hikes of ~6% vs 3% feel dramatic to the public even though they're not "2x or 10x."</li>
<li><strong>California Water Data Consortium</strong> (created ~5–7 years ago); a <strong>water reporting project</strong> started ~2022 aimed at harmonizing standards — produced a report and "fizzled."</li>
<li><strong>Open Water Rate Specification</strong> (~2017–2018): won a state open-data challenge, proved the concept, could flexibly represent full rate structures, was used in a Cal-Nevada water rate survey with several hundred utilities specified. But it never usurped existing alternatives; the GitHub repo is ~7 years out of date.</li>
<li><strong>The "original sin":</strong> the system (dating to ~2006) asked for narrow inputs (the "10,000 gallons" figure), then accreted individually-reasonable questions over decades into an unusable, ossified form. rafa's analogy: they built a spreadsheet of hard-coded values instead of one with formulas.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-07-30-sig-p4b-2026-07-30">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/549b9d6f02b9c417b75075ad623cca4227e7a4c8/sigs/sigpfb/2026-07-30-sig-p4b-2026-07-30/index.html">PI website commit 549b9d6</a> · <a href="https://pub-fb4a559f683a4e3b876823eb2bfe12a3.r2.dev/recordings/SIG-P4B/2026-07-30/1082444651946049567_1442955803471646792_1785435382631/summary.md">raw recording notes</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread and recording.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>67y187wptkhksfvfhkx5e27bzp</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/67y187wptkhksfvfhkx5e27bzp.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:6rzya010fe05p47vmav49bgew6:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/6rzya010fe05p47vmav49bgew6/</link>
      <title>SIG-P4B 2026-08-13</title>
      <description><![CDATA[<h1>SIG-P4B 2026-08-13</h1>
<p><em>Session of 13 August 2026.</em> Participants: rafa (UTC+1), Andre Comeau.</p>
<div class="blyg-tk-gen"><p>This was a one-on-one working session between rafa and Andre Comeau to scope a potential "Protocols for Business" case study focused on the construction bidding/estimating pipeline. rafa presented findings from experiments run with his father-in-law (Virgil), a former heavy-civil construction CEO, showing that an LLM could reproduce a bid estimate within ~10% and even flag design errors from solicitation PDFs. The conversation examined why this analysis isn't already automated, identified the core bottleneck (canonical drawings live in non-machine-readable PDFs), and mapped the industry incentive structure that keeps the status quo in place. They ended by discussing how to structure the project, funding, and roles.</p>
<p><strong>Key points</strong></p>
<ul>
<li><strong>The experiment (rafa):</strong> rafa fed a solicitation bid PDF to an LLM (referenced as "Opus five or whatever") and, in ~30 min of runtime (~1 hour with probing/adversarial analysis and blind agent reviews), produced numbers within 10% of a full organizational bid produced by Virgil's team. He also had the model generate a "takeoff analysis." Andre confirmed "takeoff analysis" is a real, standard industry term (not just Michigan-specific).</li>
<li><strong>Takeoff analysis defined:</strong> A table comparing the design engineer's requested materials vs. the actual planned/likely materials, and both against the contractor's read of the visual plans and real-world conditions.</li>
<li><strong>Where value really sits (rafa relaying Virgil):</strong> The final bid number is largely deterministic (driven by subcontractor and material/equipment prices where risk is passed to others). The estimator's real leverage is in the accuracy of quantities and pricing for maximum profit opportunity.</li>
<li><strong>Finding design errors = profit (rafa):</strong> When given a different spec, the model found a design error. This is commercially valuable because contractors often make money via change orders when they catch design errors.</li>
<li><strong>The four core questions rafa raised:</strong> (1) Why isn't someone in the office already running PDFs through ChatGPT? (2) Why doesn't existing bidding software do this analysis? (3) Why doesn't solicitation-bid software (e.g. BidNet) do it? (4) Why is this analysis done off PDFs instead of raw CAD data?</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-08-13-sig-p4b-2026-08-13">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/830dfb64c1f130bc80e5ebbfa0431117a09e196e/sigs/sigpfb/2026-08-13-sig-p4b-2026-08-13/index.html">PI website commit 830dfb6</a> · <a href="https://pub-fb4a559f683a4e3b876823eb2bfe12a3.r2.dev/recordings/SIG-P4B/2026-08-13/1082444651946049567_1382801113224581240_1786627950219/summary.md">raw recording notes</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread and recording.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:52:49 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>6rzya010fe05p47vmav49bgew6</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:52:49Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6rzya010fe05p47vmav49bgew6.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5n4k2tw5h82v1qds6a07925bkb:v2</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5n4k2tw5h82v1qds6a07925bkb/</link>
      <title>Research log: first outside corroboration (Grady, 24 Sep 2026) — Research log: AI Native Data Operations</title>
      <description><![CDATA[<h1>Research log: AI Native Data Operations</h1>
<p>The working thesis behind the group's 2027 research, revised as sessions, cases, and protocol watching add evidence. Earlier versions stay in this item's changelog.</p>
<h2>Premises</h2>
<p>We treat these as observations that could turn out partial or wrong.</p>
<blockquote class="blyg-transclusion" data-blyg-id="7rgdqqjes9xcj6ny9ab1d8g2j7" data-blyg-version="1"><p><strong>Premise: Abundant cognition.</strong></p>
<div class="blyg-tk-gen"><p>Reading and writing both get cheap. Processing unstructured data (PDFs, rate sheets, forms) and producing software cost a fraction of what they did.</p></div></blockquote>
<blockquote class="blyg-transclusion" data-blyg-id="1pm8hn6z29mahf3bse2ng721ss" data-blyg-version="1"><p><strong>Premise: Distributed agency.</strong></p>
<div class="blyg-tk-gen"><p>Models act, and they run as many instances at once. Swarms of agents show up wherever work is done.</p></div></blockquote>
<blockquote class="blyg-transclusion" data-blyg-id="6xz12yg4hsgw589ta7d070hdvq" data-blyg-version="1"><p><strong>Premise: Mediation.</strong></p>
<div class="blyg-tk-gen"><p>Information increasingly flows through models: people and agents find, read, and exchange it by way of LLMs and the protocols that connect them.</p></div></blockquote>
<h2>Log</h2>
<div class="blyg-tk-gen"><ul>
<li><strong>27 September 2026.</strong> Blyg started. Ten sessions from the past year imported from the Protocol Institute meeting archive as a baseline.</li>
<li><strong>27 September 2026.</strong> First outside corroboration: Pat Grady's (Sequoia) 24 September talk to the Boston College investment committee frames this wave as a revolution in computation, not communication, which supports <em>abundant cognition</em>. It dates long-horizon agents to November 2025 (<em>distributed agency</em>) and describes AI-native firms moving toward a "network of agents" for internal information flow (<em>mediation</em>). It says nothing about coordination between many agents, which is where this project goes further.</li>
<li><strong>27 September 2026.</strong> Imported the rest of the archive: all 39 sessions since February 2023 are now on the blyg, six of them with raw recording notes.</li>
</ul></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:39 GMT</pubDate>
      <dc:creator>Rafael Fernández</dc:creator>
      <blyg:id>5n4k2tw5h82v1qds6a07925bkb</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>2</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5n4k2tw5h82v1qds6a07925bkb.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:7rgdqqjes9xcj6ny9ab1d8g2j7:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/f/7rgdqqjes9xcj6ny9ab1d8g2j7/</link>
      <title>Premise: Abundant cognition. Reading and writing both get cheap. Processing…</title>
      <description><![CDATA[<p><strong>Premise: Abundant cognition.</strong></p>
<div class="blyg-tk-gen"><p>Reading and writing both get cheap. Processing unstructured data (PDFs, rate sheets, forms) and producing software cost a fraction of what they did.</p></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Rafael Fernández</dc:creator>
      <blyg:id>7rgdqqjes9xcj6ny9ab1d8g2j7</blyg:id>
      <blyg:kind>fragment</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/7rgdqqjes9xcj6ny9ab1d8g2j7.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:1pm8hn6z29mahf3bse2ng721ss:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/f/1pm8hn6z29mahf3bse2ng721ss/</link>
      <title>Premise: Distributed agency. Models act, and they run as many…</title>
      <description><![CDATA[<p><strong>Premise: Distributed agency.</strong></p>
<div class="blyg-tk-gen"><p>Models act, and they run as many instances at once. Swarms of agents show up wherever work is done.</p></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Rafael Fernández</dc:creator>
      <blyg:id>1pm8hn6z29mahf3bse2ng721ss</blyg:id>
      <blyg:kind>fragment</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/1pm8hn6z29mahf3bse2ng721ss.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:6xz12yg4hsgw589ta7d070hdvq:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/f/6xz12yg4hsgw589ta7d070hdvq/</link>
      <title>Premise: Mediation. Information increasingly flows through models: people and agents…</title>
      <description><![CDATA[<p><strong>Premise: Mediation.</strong></p>
<div class="blyg-tk-gen"><p>Information increasingly flows through models: people and agents find, read, and exchange it by way of LLMs and the protocols that connect them.</p></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Rafael Fernández</dc:creator>
      <blyg:id>6xz12yg4hsgw589ta7d070hdvq</blyg:id>
      <blyg:kind>fragment</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/6xz12yg4hsgw589ta7d070hdvq.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5n4k2tw5h82v1qds6a07925bkb:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5n4k2tw5h82v1qds6a07925bkb/</link>
      <title>Research log: AI Native Data Operations</title>
      <description><![CDATA[<h1>Research log: AI Native Data Operations</h1>
<p>The working thesis behind the group's 2027 research, revised as sessions, cases, and protocol watching add evidence. Earlier versions stay in this item's changelog.</p>
<h2>Premises</h2>
<p>We treat these as observations that could turn out partial or wrong.</p>
<blockquote class="blyg-transclusion" data-blyg-id="7rgdqqjes9xcj6ny9ab1d8g2j7" data-blyg-version="1"><p><strong>Premise: Abundant cognition.</strong></p>
<div class="blyg-tk-gen"><p>Reading and writing both get cheap. Processing unstructured data (PDFs, rate sheets, forms) and producing software cost a fraction of what they did.</p></div></blockquote>
<blockquote class="blyg-transclusion" data-blyg-id="1pm8hn6z29mahf3bse2ng721ss" data-blyg-version="1"><p><strong>Premise: Distributed agency.</strong></p>
<div class="blyg-tk-gen"><p>Models act, and they run as many instances at once. Swarms of agents show up wherever work is done.</p></div></blockquote>
<blockquote class="blyg-transclusion" data-blyg-id="6xz12yg4hsgw589ta7d070hdvq" data-blyg-version="1"><p><strong>Premise: Mediation.</strong></p>
<div class="blyg-tk-gen"><p>Information increasingly flows through models: people and agents find, read, and exchange it by way of LLMs and the protocols that connect them.</p></div></blockquote>
<h2>Log</h2>
<div class="blyg-tk-gen"><ul>
<li><strong>27 September 2026.</strong> Blyg started. Ten sessions from the past year imported from the Protocol Institute meeting archive as a baseline.</li>
<li><strong>27 September 2026.</strong> First outside corroboration: Pat Grady's (Sequoia) 24 September talk to the Boston College investment committee frames this wave as a revolution in computation, not communication, which supports <em>abundant cognition</em>. It dates long-horizon agents to November 2025 (<em>distributed agency</em>) and describes AI-native firms moving toward a "network of agents" for internal information flow (<em>mediation</em>). It says nothing about coordination between many agents, which is where this project goes further.</li>
<li><strong>27 September 2026.</strong> Imported the rest of the archive: all 39 sessions since February 2023 are now on the blyg, six of them with raw recording notes.</li>
</ul></div>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Rafael Fernández</dc:creator>
      <blyg:id>5n4k2tw5h82v1qds6a07925bkb</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5n4k2tw5h82v1qds6a07925bkb.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5b3vcnpvrqd545ae6ekrn72sq6:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5b3vcnpvrqd545ae6ekrn72sq6/</link>
      <title>Boom Case Study: Innovation Speed, Supply Chain Friction, and AI-Generated Content</title>
      <description><![CDATA[<h1>Boom Case Study: Innovation Speed, Supply Chain Friction, and AI-Generated Content</h1>
<p><em>Session of 6 October 2025.</em> Participants: timber1997, rafa_0x, sachbenny, thewanderingeditor.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed the Boom case study, focusing on tensions between rapid innovation cycles and slower traditional supply chains. Key concerns emerged around whether innovation capability could be constrained by industry supply chain inflexibility, and whether removing friction introduces hidden long-tail risks through error propagation. The conversation explored how businesses need to restructure supply chains to match R&amp;D velocity.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Generation-native businesses face a critical constraint where R&amp;D velocity outpaces manufacturing flexibility, requiring backward propagation of supply chains to remain viable.</li>
<li>Removing friction from processes may amplify small errors at scale, creating long-tail risks that traditional risk management doesn't account for.</li>
<li>AI-generated text exhibits detectable patterns of 'agreeableness' optimized for skimming rather than critical engagement, requiring conscious awareness from readers.</li>
<li>Regulatory and legal frameworks may need to shift from rule-based compliance to intent-based evaluation as AI and automation outpace static law.</li>
<li>Micro-managers and traditional leaders are beginning to shift their risk tolerance and management approaches in response to AI capabilities, though not always consciously.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-10-06-boom-case-study-innovation-speed-supply-chain-friction">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-10-06-boom-case-study-innovation-speed-supply-chain-friction/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5b3vcnpvrqd545ae6ekrn72sq6</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5b3vcnpvrqd545ae6ekrn72sq6.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:0kpdm445aex86567menm3h4dbe:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/0kpdm445aex86567menm3h4dbe/</link>
      <title>Forward-Deployed Engineers (FDEs): Business Model, Role Evolution, and Market Implications</title>
      <description><![CDATA[<h1>Forward-Deployed Engineers (FDEs): Business Model, Role Evolution, and Market Implications</h1>
<p><em>Session of 3 November 2025.</em> Participants: rafa_0x, sachbenny, thewanderingeditor, timber1997, holajorge, mihir0k, stevebeans., oneiromancer2665.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed the emerging role of Forward-Deployed Engineers (FDEs) and its implications for software business models. The conversation revealed that FDEs primarily conduct information processing and context collection for customers rather than traditional implementation work, reversing the product-driven approach that has dominated Silicon Valley. Participants noted that this model represents a return to customer-driven business practices, exemplified by Palantir's Foundry platform, and functions as an extended, machine-augmented version of Waterfall development. The role requires significant in-person engagement and trust-building, making it difficult to scale with traditional staffing approaches.</p>
<p><strong>Key points</strong></p>
<ul>
<li>FDE work is primarily information processing and context collection rather than interface customization, representing a shift from product-driven to customer-driven business models similar to Palantir's approach.</li>
<li>The FDE role resembles traditional service-based relationships (handymen, gardeners, consultants) and may evolve into a standalone consulting service comparable to Big Four consulting firms.</li>
<li>FDEs are uniquely positioned to 'break protocol' both internally and with clients, requiring significant in-person trust-building and contextual knowledge that creates high social barriers to scaling.</li>
<li>The rise of FDEs may indicate that Waterfall-style development could regain value in certain contexts, or represent an entirely new design space that challenges the Agile dominance of Silicon Valley.</li>
<li>AI models function as customer-driven collections of stable behavioral patterns rather than explicit problem-solving tools, enabling FDEs to bridge the gap between generalized AI capabilities and specific customer needs.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-11-03-forward-deployed-engineers-fdes-business-model-role-evo">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-11-03-forward-deployed-engineers-fdes-business-model-role-evo/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>0kpdm445aex86567menm3h4dbe</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/0kpdm445aex86567menm3h4dbe.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:4pt890bzhkdr656am70z60s5zh:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/4pt890bzhkdr656am70z60s5zh/</link>
      <title>Fat vs Lean: Tempo Management and Organizational Protocols</title>
      <description><![CDATA[<h1>Fat vs Lean: Tempo Management and Organizational Protocols</h1>
<p><em>Session of 17 November 2025.</em> Participants: sachbenny, timber1997, ggnore999, rafa_0x, stevebeans., waveywaves., drevius., ncc1031.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group convened to discuss how organizations manage the tension between 'fat' (high-entropy organizational surplus with undirected potential) and 'lean' (streamlined, directed efficiency). Rafa introduced the concept that true organizational fat is necessarily disorganized and multidirectional to maintain readiness across diverse, long-term strategic challenges—unlike simple inventory surplus. The group identified that firms serving stable, long-term clients (military, government, institutional investors) have successfully maintained fatness and volatility resistance, while those pursuing lean strategies struggle with rapid environmental change. A critical insight emerged: many organizations lack self-awareness about whether they are actually fat or lean, creating hidden risks.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Organizational 'fat' requires high-entropy disorganization and directionless potentiality to maintain readiness across multiple strategic directions, with high maintenance costs at higher organizational levels.</li>
<li>Many organizations are unaware of their actual lean or fat status, creating existential risk; conversely, some may survive despite unintended fat due to client stability.</li>
<li>Institutions with stable, long-term clients (military, government, enterprise) successfully maintain fatness, while lean management ideology inadvertently moved these sectors toward vulnerability.</li>
<li>Organizational Ontological Primacy may serve as a more measurable protocol than Time to Mediocrity for managing AI-first organizations' trustworthiness tensions.</li>
<li>Formal ontologies rarely translate from technical to management levels due to organizational messiness and politics, yet implicit ontologies already exist embedded in protocols like accounting hierarchies and legal structures.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-11-17-fat-vs-lean-tempo-management-and-organizational-protoco">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-11-17-fat-vs-lean-tempo-management-and-organizational-protoco/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>4pt890bzhkdr656am70z60s5zh</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/4pt890bzhkdr656am70z60s5zh.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:19fybcsdxsd1spxbw3awsgkftp:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/19fybcsdxsd1spxbw3awsgkftp/</link>
      <title>Protocols for Business: LLM Impact on Version Control and Business Processes</title>
      <description><![CDATA[<h1>Protocols for Business: LLM Impact on Version Control and Business Processes</h1>
<p><em>Session of 8 December 2025.</em> Participants: timber1997, rafa_0x, sachbenny.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group discussed fundamental challenges LLMs present to core business protocols, particularly around version control, traceability, and historical record-keeping. Timber1997 identified that LLMs are ineffective at handling sequences and maintaining version narratives, while rafa_0x highlighted missing traceability and checkpoints as key problems. The group explored a counterintuitive insight: when reproduction costs are near-zero, the traditional need for 'undo' functionality diminishes, even if perfect reproduction is impossible.</p>
<p><strong>Key points</strong></p>
<ul>
<li>LLMs struggle with version control and maintaining sequential traceability, which are fundamental to business protocols but not fully protected from AI impact.</li>
<li>When reproduction costs approach zero (even if exact reproduction is impossible), traditional 'undo' functionality becomes less critical, enabling strategies like full codebase refactoring.</li>
<li>Organizations need to adapt code auditing and planning policies specifically to account for LLM-assisted development, rather than implementing generic LLM usage policies.</li>
<li>The discussion shifted from LLM adoption resistance to examining how auditing, planning, and governance policies should evolve in response to widespread employee LLM usage.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2025-12-08-protocols-for-business-llm-impact-on-version-control-an">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2025-12-08-protocols-for-business-llm-impact-on-version-control-an/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>19fybcsdxsd1spxbw3awsgkftp</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/19fybcsdxsd1spxbw3awsgkftp.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:3v13qvjz1e2sjggwsp5j9dxk3k:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/3v13qvjz1e2sjggwsp5j9dxk3k/</link>
      <title>SIGPfB Meeting: Enterprise AI Protocols, Data Curation, and Research Archetypes</title>
      <description><![CDATA[<h1>SIGPfB Meeting: Enterprise AI Protocols, Data Curation, and Research Archetypes</h1>
<p><em>Session of 12 January 2026.</em> Participants: rafa_0x, timber1997, sachbenny, drevius., .unipuff.</p>
<div class="blyg-tk-gen"><p>The SIGPfB group convened to discuss enterprise AI protocols and business applications. Participants analyzed the hidden complexity of data curation in AI systems, noting that memory costs and software layers create enormous expenses for bespoke LLM development, with only marginal gains justifying custom stacks as standardized solutions mature. The group debated systemic risk from model rollouts at scale and discussed the vulnerability of deeply integrated AI systems. They refined their working framework for protocol-focused work into three main categories: Protocol Consulting (client-facing advisory), Protocol Design (technical protocol specifications like auction models), and Protocol Engineering (implementation work like AI orchestration layers). Discussion shifted toward AI agents functioning as analysts and researchers. Late in the thread, participant .unipuff revealed convergence with their PhD thesis research on research archetypes, proposing a typology based on cognitive modes and styles (Naturalists with vertical cognition, Engineers and Managers with horizontal cognition) rather than operational functions alone, suggesting important complementarities across research approaches.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Data curation after collection involves numerous software layers and represents a major cost center for enterprise AI vendors, similar to hidden complexity in everyday technology like microwaves.</li>
<li>Bespoke LLM stacks have enormous marginal costs, but marginal gains may justify investment; eventually standardized phenotypical stacks will emerge with diminishing returns to customization.</li>
<li>The group's framework distinguishing Protocol Consulting, Design, and Engineering converges with academic research on research archetypes based on cognitive modes (vertical vs. horizontal) rather than operational distinctions alone.</li>
<li>Research archetypes are epistemically important and function through tensions and complementarities rather than simple trade-offs between different cognitive styles and work environments.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-01-12-sigpfb-meeting-enterprise-ai-protocols-data-curation-an">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-01-12-sigpfb-meeting-enterprise-ai-protocols-data-curation-an/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>3v13qvjz1e2sjggwsp5j9dxk3k</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/3v13qvjz1e2sjggwsp5j9dxk3k.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:2q8rqdnhn99zyzbhryh22d7xaj:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/2q8rqdnhn99zyzbhryh22d7xaj/</link>
      <title>SIGPfB Study Group: Auction Protocols and Transaction Mechanisms</title>
      <description><![CDATA[<h1>SIGPfB Study Group: Auction Protocols and Transaction Mechanisms</h1>
<p><em>Session of 9 February 2026.</em> Participants: rafa_0x, timber1997, sachbenny, thewanderingeditor, zhgnv.</p>
<div class="blyg-tk-gen"><p>The SIGPfB study group convened to examine auction protocols as transaction mechanisms in business contexts. The session moved from management protocols to transaction protocols, using examples like GitHub's implementation on Git and Google Ads built on Vickrey Auctions. Participants discussed where auctions shape industries (spectrum pricing, airport allocation) and explored the design space concealed by the term 'auction.' A critical insight emerged around interface power—auctions function effectively with sufficient buyer/seller volume but risk manipulation when participant groups are limited. The group noted that specific auction implementations may be fragile even as the broader family of auction mechanisms remains robust, drawing parallels to voting mechanism limitations. Participants also shared vibecoding experiments and tools, including government accountability research and custom slash commands for audit purposes.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Auction protocols mediate business between untrusted parties and serve as foundations for major products (Git, Google Ads), representing a critical design space often obscured by the umbrella term 'auction.'</li>
<li>The interface to participate in auctions holds significant power; auctions work best with sufficient volume of sellers and buyers, but risk becoming rigged when supplier groups are limited.</li>
<li>Specific auction implementations may be weak protocols despite 'Auctions' as a family being strong, with sensitivities requiring protocol adoption shifts—similar to limitations seen in voting mechanisms like plurality voting.</li>
<li>Auction mechanisms and voting mechanisms share structural similarities in their scaling limitations and may represent a family of related mechanism design problems.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-02-09-sigpfb-study-group-auction-protocols-and-transaction-me">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-02-09-sigpfb-study-group-auction-protocols-and-transaction-me/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>2q8rqdnhn99zyzbhryh22d7xaj</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/2q8rqdnhn99zyzbhryh22d7xaj.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:2hdjvdxf8gc0gpxnv4kx8ncmwn:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/2hdjvdxf8gc0gpxnv4kx8ncmwn/</link>
      <title>SIGPfB Study Group: Water Data Management Protocols &amp; Tensions Analysis</title>
      <description><![CDATA[<h1>SIGPfB Study Group: Water Data Management Protocols &amp; Tensions Analysis</h1>
<p><em>Session of 9 March 2026.</em> Participants: rafa_0x, timber1997, sachbenny, anurajenp, plague_year, drevius., matt_ms, thewanderingeditor.</p>
<div class="blyg-tk-gen"><p>The SIGPfB study group convened to develop protocols for water data management in California, with rafa_0x leading analysis of structural tensions in protocol design. The group identified Speed vs. Defensibility as the primary tension—showing how friction in approval processes (e.g., inability to freely edit submitted reports) and political need for coalition alignment actually support thoroughness and defensibility. Multiple case studies were examined: California water governance (AB1755), healthcare data sharing (HIPAA/21st Century Cures Act), and transit standards (GTFS), revealing that standards adoption succeeds through conditional funding mechanisms rather than mandates, provided scope stays narrow.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Political defensibility and blame containment drive protocol design more than pure efficiency—shared exposure surfaces and reconciliation friction slow commitments until coalitions align on 'the number' and 'the story'.</li>
<li>States successfully mandate standards through conditional funding mechanisms (e.g., highway funding tied to drinking age laws) rather than direct regulation, creating adoption cascades when scope is narrow and implementation burden is low.</li>
<li>The shift from non-sharing to data sharing in healthcare came not from technical standards but from inverting legal risk models—making withholding data more costly than sharing it (Information Blocking Rule).</li>
<li>Monstrous Protocols (high-variance systems with genuine practitioner disagreement) are valuable training grounds for developing 'variance literacy' and 'adjacency mapping' skills essential for frontier protocol work.</li>
<li>A generalizable 'Tensions' skill or framework developed from California water governance could be applied across domains like government reporting, corporate compliance, and other information-sharing systems.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-03-09-sigpfb-study-group-water-data-management-protocols-tens">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/f48390cd7948bcdd0514ecd2cd8ef88d0a477843/sigs/sigpfb/2026-03-09-sigpfb-study-group-water-data-management-protocols-tens/index.html">PI website commit f48390c</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>2hdjvdxf8gc0gpxnv4kx8ncmwn</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/2hdjvdxf8gc0gpxnv4kx8ncmwn.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:3mpej1k3yt54vejk725k3h1g6a:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/3mpej1k3yt54vejk725k3h1g6a/</link>
      <title>Protocols for Business - Benchmarking and Projects</title>
      <description><![CDATA[<h1>Protocols for Business - Benchmarking and Projects</h1>
<p><em>Session of 15 June 2026.</em> Participants: rafa_0x.</p>
<div class="blyg-tk-gen"><p>The Protocols for Business SIGPfB group held a meeting on June 15, 2026, focused on benchmarking and projects. The meeting organizer, rafa_0x, announced the meeting start time across two major time zones to accommodate participants. During the brief transcript captured, two main items were noted: an ongoing radiology study and a scheduled demo presentation. A participant was called out as being on the agenda to present the demo.</p>
<p><strong>Key points</strong></p>
<ul>
<li>A radiology study is currently in progress within the SIGPfB group's work.</li>
<li>The meeting was scheduled across multiple time zones (5:30pm CET / 11:30am EST), indicating international participation.</li>
<li>A demo was planned as part of the meeting agenda with specific presenters identified.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-06-15-protocols-for-business-benchmarking-and-projects">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/e4620f8e369aa111d453ff8cd9ea4f38b3eba7f7/sigs/sigpfb/2026-06-15-protocols-for-business-benchmarking-and-projects/index.html">PI website commit e4620f8</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>3mpej1k3yt54vejk725k3h1g6a</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/3mpej1k3yt54vejk725k3h1g6a.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:5jcnr5p3g36vharsk5rkza3sr4:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/5jcnr5p3g36vharsk5rkza3sr4/</link>
      <title>SIG-P4B 2026-08-10</title>
      <description><![CDATA[<h1>SIG-P4B 2026-08-10</h1>
<p><em>Session of 10 August 2026.</em> Participants: durgadas, rafa (UTC+1), NicolasCero, Timber, Sachin, Matthew Bright UTC-7, Javier Chavez / UTC -6, Andre Comeau.</p>
<div class="blyg-tk-gen"><p>The session had two overlapping strands that were, unfortunately, largely spoken over each other in the recording: (1) a group discussion of the "Standardization of Time" article as part of an ongoing theme on how technologies get socially adopted and how that relates to protocol development and ossification (last week's session covered QWERTY), and (2) two show-and-tell presentations — durgadas on his "proof of coordination" standards work and NicolasCero on a web-app tool for co-creating AI-adoption protocols for cultural organizations. The transcript is heavily interleaved (multiple speakers overlapping), so some points are fragmentary; those are flagged below.</p>
<p><strong>Reading.</strong> "The Standardization of Time" (linked in the session chat; author not stated in the transcript). From the discussion it appears to be a historical/sociological article — participants noted it was likely published in the 1980s and covers time zones, the telegraph and railways, and atomic clocks. Matthew connects it to David Landes' book <em>Revolution in Time</em> on the Swiss watch industry as roughly contemporary material.</p>
<p><strong>Key points</strong></p>
<ul>
<li><strong>Rafa</strong> framed the recurring theme: understanding social adoption processes of technologies (currently happening with AI) and how adoption relates to protocol development and ossification.</li>
<li><strong>Sachin:</strong> Noted a coming change (~2030) in how a second is defined via atomic clocks — further subdivision — but argued there's no implication for <em>human</em> perception of time (humans don't sense below ~1 second; ~1/10 second visual limit). Suggested finer division is "more advantageous for machines."</li>
<li><strong>Sachin:</strong> Drew the article's parallel that time was socialized through institutions (telegraph, railway) and factories imposing working hours; workers then argued for better-defined hours (ten-hour day ~1848, later eight-hour day). Once adopted, standards become invisible "reality."</li>
<li><strong>Sachin:</strong> Contrasted this with newer tech like LLMs, where top-down institutional mandates on adoption have largely failed or met political opposition; people can't even agree on defining terms like AGI. Noted media increasingly use "superintelligence" as an unverifiable, pre-emptive socialization of an idea.</li>
<li><strong>Rafa:</strong> Was disappointed the paper didn't speculate about where time-standardization is heading beyond time zones. Argued the paper underestimates the "centrality of the <em>now</em>" — a <em>present-local</em> (not geographically local) mode of coordinating actions relative to the present moment, exemplified by constant chat-based "in five minutes?" negotiation. Acknowledged this view may be biased by living online.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-08-10-sig-p4b-2026-08-10">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/830dfb64c1f130bc80e5ebbfa0431117a09e196e/sigs/sigpfb/2026-08-10-sig-p4b-2026-08-10/index.html">PI website commit 830dfb6</a> · <a href="https://pub-fb4a559f683a4e3b876823eb2bfe12a3.r2.dev/recordings/SIG-P4B/2026-08-10/1082444651946049567_1382801113224581240_1786375832557/summary.md">raw recording notes</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread and recording.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>5jcnr5p3g36vharsk5rkza3sr4</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/5jcnr5p3g36vharsk5rkza3sr4.json</blyg:item>
    </item>
    <item>
      <guid isPermaLink="false">blyg:7ek3b5v2pgty346pmph6yz221h:v1</guid>
      <link>https://npc.here.now/protocolvision/blyg/t/7ek3b5v2pgty346pmph6yz221h/</link>
      <title>Community Scale AI: Protocols, Infrastructure, and Local Stewardship</title>
      <description><![CDATA[<h1>Community Scale AI: Protocols, Infrastructure, and Local Stewardship</h1>
<p><em>Session of 7 September 2026.</em> Participants: rafa_0x, borismann, timber1997, jacobsayles.</p>
<div class="blyg-tk-gen"><p>The SIGPfB meeting focused on designing community-scale AI infrastructure that prioritizes local stewardship and human-centered interfaces over traditional software disruption. Boris, Jacob, and Rafa outlined a four-phase architecture: Phase 1 establishes a membership base with OpenAI-compatible API access; Phase 2 introduces a shared data commons and context harness; Phase 3 enables local clients with CRDT-based data mirroring; and Phase 4 creates a federated network where members run their own nodes over open protocols. The technical implementation uses infrastructure-as-code with Proxmox, Ansible, and AT Protocol, with public repositories at zSpace Society.</p>
<p><strong>Key points</strong></p>
<ul>
<li>Self-hosting is only the easy part; the real challenge is building multiplayer systems that serve communities rather than individuals, requiring human support baked into the stewardship model from the start.</li>
<li>Open source models lag frontier AI by roughly six months but are 'more than good enough' for community-scale applications, with a clear path to running inference locally via CRDTs and local clients.</li>
<li>The solution to increasingly automated systems is paradoxically human-centered: chat-first interfaces, community context pipelines, and accessibility to non-technical users as the primary litmus test.</li>
<li>A federated protocol-based approach (Phase 4) enables members to run their own nodes and leave at any time, avoiding platform lock-in while maintaining collaborative shared models over open protocols.</li>
<li>The model is being validated through Jacob's 84-unit housing co-op and tested for replication in other communities (Salmon Arm, Vancouver coworking spaces), suggesting broader applicability beyond tech communities.</li>
</ul></div>
<p>Source: <a href="https://protocol-institute.org/sigs/sigpfb/2026-09-07-community-scale-ai-protocols-infrastructure-and-local-s">Protocol Institute meeting archive</a> · <a href="https://github.com/Protocol-Institute/website/blob/5f7307f90cb99ffe5f1dce580507dfdc8725769b/sigs/sigpfb/2026-09-07-community-scale-ai-protocols-infrastructure-and-local-s/index.html">PI website commit 5f7307f</a> · <a href="https://pub-fb4a559f683a4e3b876823eb2bfe12a3.r2.dev/recordings/SIG-P4B/2026-09-07/1082444651946049567_1382801113224581240_1788795133956/summary.md">raw recording notes</a>. Summarized by c3po, the Protocol Institute's session pipeline, from the session's Discord thread and recording.</p>]]></description>
      <pubDate>Sun, 27 Sep 2026 04:43:37 GMT</pubDate>
      <dc:creator>Protocols for Business SIG</dc:creator>
      <blyg:id>7ek3b5v2pgty346pmph6yz221h</blyg:id>
      <blyg:kind>thread</blyg:kind>
      <blyg:version>1</blyg:version>
      <blyg:created>2026-09-27T04:43:37Z</blyg:created>
      <blyg:item>https://npc.here.now/protocolvision/blyg/items/7ek3b5v2pgty346pmph6yz221h.json</blyg:item>
    </item>
  </channel>
</rss>
