<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Bizbox</title>
    <description>The latest articles on DEV Community by Bizbox (@citro).</description>
    <link>https://dev.to/citro</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3911387%2F685160a2-5e56-4b44-a4f9-a7ea4cb9f9cc.png</url>
      <title>DEV Community: Bizbox</title>
      <link>https://dev.to/citro</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/citro"/>
    <language>en</language>
    <item>
      <title>Bizbox Build Log: May 2–8, 2026</title>
      <dc:creator>Bizbox</dc:creator>
      <pubDate>Thu, 07 May 2026 02:18:58 +0000</pubDate>
      <link>https://dev.to/citro/bizbox-build-log-may-2-8-2026-hd1</link>
      <guid>https://dev.to/citro/bizbox-build-log-may-2-8-2026-hd1</guid>
      <description>&lt;p&gt;Four releases, nine PRs merged, and one clear theme this week: making Bizbox agents more capable and trustworthy in multi-turn execution contexts.&lt;/p&gt;

&lt;h2&gt;
  
  
  Shipped this week
&lt;/h2&gt;

&lt;h3&gt;
  
  
  Company AI Builder (Phases 0–4)
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/20" rel="noopener noreferrer"&gt;#20&lt;/a&gt; landed the full Company AI Builder feature — a curated set of mutation tools delivered via a proposal-approval flow. Phase 0 shipped read-only spike work (sessions, settings, OpenAI-compat interface, six read tools, UI). This update extends with Phases 1–4: proposal-store infrastructure, mutation tools behind proposals, and the approval surface for company owners.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Trade-off:&lt;/strong&gt; Mutation tools are gated by human approval for now. We chose safety and trust before convenience. Future iterations will tune the guardrails based on real operator feedback.&lt;/p&gt;

&lt;h3&gt;
  
  
  Artifact validation and schema hardening
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/27" rel="noopener noreferrer"&gt;#27&lt;/a&gt; introduced stricter validation for "artifact" work products — enforcing that artifact work products always have attachment-backed metadata and a &lt;code&gt;createdByRunId&lt;/code&gt;. New schema validators, runtime type guards, and tighter integration mean artifact handling is now fail-fast instead of fail-silent.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why it matters:&lt;/strong&gt; Agents produce artifacts (deliverables, documents, code outputs). Loose validation meant broken artifact references could propagate through the system. This change catches those errors at the boundary.&lt;/p&gt;

&lt;h3&gt;
  
  
  Artifact persistence and UI updates for issue-backed runs
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/25" rel="noopener noreferrer"&gt;#25&lt;/a&gt; adds support for collecting output artifacts from adapter executions (especially OpenClaw Gateway adapters), introduces new types and logic for artifact management, and exposes utilities for artifact-related work products.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Open challenge:&lt;/strong&gt; Artifact handling is still evolving. We're learning what metadata needs to travel with artifacts, how to version them, and what the UI should surface. Feedback welcome.&lt;/p&gt;

&lt;h3&gt;
  
  
  Agent thread chat with optimistic UI
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/21" rel="noopener noreferrer"&gt;#21&lt;/a&gt; adds a direct communication channel between operators and agents. Users can now message agents from the agent detail page, with optimistic UI updates for a snappier feel.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Decision:&lt;/strong&gt; We chose optimistic updates over waiting for server confirmation. It makes the UI feel faster. The trade-off: rare cases where the server rejects a message won't be obvious until you refresh. We're watching for confusion signals.&lt;/p&gt;

&lt;h3&gt;
  
  
  Routine execution recovery logic
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/22" rel="noopener noreferrer"&gt;#22&lt;/a&gt; fixes how Bizbox handles &lt;code&gt;routine_execution&lt;/code&gt; issues in &lt;code&gt;blocked&lt;/code&gt; state. Previously, the recovery logic treated blocked routines as failures and tried to resume them prematurely. Now, &lt;code&gt;blocked&lt;/code&gt; is recognized as a healthy, parked wait state.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why this was broken:&lt;/strong&gt; Routines often block on human approval or child issue completion. The old logic didn't distinguish "blocked and waiting" from "blocked and stuck." This change codifies the difference.&lt;/p&gt;

&lt;h3&gt;
  
  
  Upstream merge and OpenTelemetry metrics
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/16" rel="noopener noreferrer"&gt;#16&lt;/a&gt; merged upstream PaperClip changes from April 30, 2026 (assisted by Claude Sonnet 4.6).&lt;/p&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/14" rel="noopener noreferrer"&gt;#14&lt;/a&gt; adds OpenTelemetry metrics, starting with &lt;code&gt;bizbox.issues.human_comments_total&lt;/code&gt; — a signal for human intervention frequency.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Trade-off:&lt;/strong&gt; We're starting with one metric to validate the integration pattern. More will follow once we've confirmed the collector setup works in production.&lt;/p&gt;

&lt;h3&gt;
  
  
  agentParams refactor and regression fix
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/24" rel="noopener noreferrer"&gt;#24&lt;/a&gt; fixes a regression introduced in &lt;code&gt;v0.0.6&lt;/code&gt; where the OpenClaw gateway adapter changed the outbound agent request shape. The fix refactors &lt;code&gt;agentParams&lt;/code&gt; handling and removes an unused function that was masking the real issue.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Lesson:&lt;/strong&gt; Request shape changes in adapters are easy to miss when tests don't cover the boundary. We added a test to catch this pattern in the future.&lt;/p&gt;

&lt;h3&gt;
  
  
  Workflow cleanup
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/zesthq/bizbox/pull/23" rel="noopener noreferrer"&gt;#23&lt;/a&gt; removes the &lt;code&gt;sync-upstream&lt;/code&gt; workflow. We're switching to manual upstream merges (with AI assistance) for now.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why:&lt;/strong&gt; Automated upstream sync introduced more conflicts than it saved in merge time. Manual merges with AI assistance give us control without the constant breakage.&lt;/p&gt;

&lt;h2&gt;
  
  
  Decisions
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Mutation tools behind proposals:&lt;/strong&gt; We're prioritizing trust and transparency over convenience. Operators see and approve changes before agents make them.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Artifact validation is fail-fast:&lt;/strong&gt; Better to catch broken artifacts early than let them propagate.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Blocked routine state is healthy:&lt;/strong&gt; Routines can wait. Not every blocked issue is a failure.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Manual upstream merges:&lt;/strong&gt; Automation failed here. Human-in-the-loop merges with AI assistance work better for our repo.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Trade-offs
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Proposal flow adds friction:&lt;/strong&gt; Every mutation requires approval. This is intentional for now, but we know it slows down agents. Future work: smart approval defaults based on context and trust signals.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Optimistic UI updates hide rare server rejections:&lt;/strong&gt; We chose speed over certainty. Watching for user confusion.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;One OpenTelemetry metric to start:&lt;/strong&gt; We're validating the pattern before adding dozens of metrics. Risk: we might miss important signals early.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Open challenges
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Artifact versioning and metadata:&lt;/strong&gt; What needs to travel with an artifact? How do we version it? What should the UI surface? Still figuring this out.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Approval UX for high-frequency mutations:&lt;/strong&gt; Approving every change works for low-frequency operations. It won't scale to high-frequency agent work. Need smarter defaults.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Upstream merge strategy:&lt;/strong&gt; Manual merges with AI assistance work for now, but they don't scale. We need a better long-term approach.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Releases
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;a href="https://github.com/zesthq/bizbox/releases/tag/v0.0.9" rel="noopener noreferrer"&gt;v0.0.9&lt;/a&gt; — May 6, 2026&lt;/li&gt;
&lt;li&gt;
&lt;a href="https://github.com/zesthq/bizbox/releases/tag/v0.0.8" rel="noopener noreferrer"&gt;v0.0.8&lt;/a&gt; — May 5, 2026&lt;/li&gt;
&lt;li&gt;
&lt;a href="https://github.com/zesthq/bizbox/releases/tag/v0.0.7" rel="noopener noreferrer"&gt;v0.0.7&lt;/a&gt; — May 5, 2026&lt;/li&gt;
&lt;li&gt;
&lt;a href="https://github.com/zesthq/bizbox/releases/tag/v0.0.6" rel="noopener noreferrer"&gt;v0.0.6&lt;/a&gt; — May 5, 2026&lt;/li&gt;
&lt;/ul&gt;




&lt;p&gt;&lt;em&gt;This Build Log is grounded in real repo activity. Every claim links to a PR, issue, release, or ADR. No internal-only context, no invented features, no marketing fluff.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Questions? Join the discussion on &lt;a href="https://github.com/zesthq/bizbox" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>bizbox</category>
      <category>buildlog</category>
      <category>buildinpublic</category>
      <category>ai</category>
    </item>
  </channel>
</rss>
