Bizbox Build Log — Week of 2026-05-30
Five substantive PRs merged this week (2026-05-23 through 2026-05-30), two releases shipped. The theme: the awaiting-human bridge grows up — two merged PRs lay the provider-agnostic infrastructure (company-scoped configuration and hardened lifecycle semantics), with the ClickUp transport adapter still in review. Plus: the first Google ADK agent adapter lands, and the production VMs get a resource bump to match real workloads.
Note on release tags: PRs #72, #74, and #76 merged to master on 2026-05-28 and are not yet in a tagged release at time of writing. PRs #70 and #73 shipped in v2026.525.0 and v2026.525.1 respectively.
Shipped This Week
🤖 Google ADK agent adapter
PR #72 · @DennisDenuto · merged 2026-05-28 · not yet in a tagged release
Bizbox can now create and manage agents backed by Google's Agent Development Kit (ADK). The new adapter package covers server execution, CLI formatting, stdout parsing, and UI config/build helpers. Google ADK is registered in the shared agent-type registry, adapter registry, and capability lookup — so it behaves like any other built-in adapter from the operator's perspective: create it, configure it, assign it to issues.
The adapter ships with server-level tests for event parsing and execution behaviour, and the agent loadout UI was updated to include Google ADK in the configuration and new-agent flows.
This is the first non-OpenClaw adapter to land in the core codebase. It opens the door to multi-runtime agent pipelines where different tasks can be routed to the best-fit execution environment.
🌉 Awaiting-human bridge: retry and reply dedupe
PR #76 · @ralphbibera · merged 2026-05-28 · not yet in a tagged release
The second of two merged awaiting-human bridge PRs this week (a third, the ClickUp transport adapter PR #78, is still in review). This PR finalises the bridge lifecycle. Key changes:
-
Interaction-scoped dedupe. Inbound events now deduplicate on
(interaction_id, external_event_id)rather than justexternal_event_id. The same external event can be safely ignored across bridge reopenings without false-positive suppression. - Free-text replies stay as comments. Plain replies from the human operator are now imported as issue comments and wake the agent, rather than being treated as approval signals. The bridge stays open until an explicit approval or rejection arrives.
- Retries create fresh rows. Bridge retries no longer reuse stale state; each retry starts clean, which eliminates a class of ghost-approval bugs.
-
Heartbeat compatibility. The heartbeat reconciler previously contained a hardcoded
clickup-chatreference for filtering legacy delivered interactions. That reference has been moved into the bridge service, keeping the reconciler provider-agnostic.
Migration 0076 consolidates the final inbound event schema and dedupe index in one place.
⚙️ Awaiting-human bridge: company-scoped configuration
PR #74 · @ralphbibera · merged 2026-05-28 · not yet in a tagged release
The first of the two merged bridge PRs this week adds the settings layer that makes the bridge multi-tenant. Before this, every company shared the same (or no) external channel for human approvals — settings were hardcoded or absent. Now:
- A new
company_awaiting_human_settingstable (migration0075) stores per-company provider config as JSONB. - The first supported provider is ClickUp, with workspace/channel routing and secret rotation.
- Zod validators cover PATCH requests; the
awaitingHumanSettingsServicehandles CRUD and secret rotation. - The schema is designed so future providers (Slack, Discord, etc.) can be added without changing the settings shape.
This is the infrastructure that makes the pure-plugin ClickUp adapter (PR #78, still open) meaningful: each company can now point the bridge at its own ClickUp workspace.
🖥️ VM resource upgrade: 4 GB memory, 4 CPUs
PR #73 · v2026.525.1 · @adPalafox · merged 2026-05-25
Both fly.toml and fly.private.toml now allocate 4 GB of memory and 4 shared CPUs per VM, up from 2 GB / 2 CPUs. The change reflects real production workloads: multi-agent runs with concurrent heartbeats were hitting memory pressure under the old allocation. The upgrade doubles headroom for parallel execution without changing any application code.
✅ ClickUp approval: non-approval replies treated as rejection
PR #70 · v2026.525.0 · @adPalafox · merged 2026-05-25
The ClickUp awaiting-human approval handler now has explicit semantics for every reply type:
-
Explicit negative reactions (
thumbsdown) immediately reject the interaction — no comment text is forwarded. - Non-approval free-text replies are treated as rejections, with the reply text forwarded as a comment into the related issue for context.
- Approval signals (positive reactions, explicit approval phrases) continue to work as before.
Previously, a human replying with anything other than an approval phrase could leave the interaction in an ambiguous state. The new behaviour is deterministic: every reply resolves the interaction one way or the other.
Decisions
Provider-agnostic bridge architecture. The team committed to keeping the awaiting-human bridge core strictly provider-agnostic. PRs #74 and #76 build the infrastructure; PR #78 (still open) ports the ClickUp transport as a pure plugin that registers via AwaitingHumanBridgeRegistry. The rule: bridge core files must not reference any specific provider. This makes adding Slack, Discord, or any future channel a matter of writing a new adapter, not touching shared infrastructure.
Google ADK as a first-class adapter. Rather than treating Google ADK as an experimental or external integration, the team registered it in the same adapter registry and capability lookup as OpenClaw. The decision signals that Bizbox is positioning itself as runtime-agnostic — the orchestration layer, not a wrapper around a single agent runtime.
VM resources doubled proactively. The resource bump in PR #73 was driven by observed memory pressure in production, not a planned capacity review. The decision to double both memory and CPUs (rather than a more conservative step-up) reflects a preference for headroom over incremental tuning.
Trade-offs
-
Bridge config is company-scoped, not agent-scoped. The new
company_awaiting_human_settingstable routes all awaiting-human interactions for a company through the same provider and channel. That's the right default for most deployments, but companies that want different approval channels for different agent types or projects will need a future per-agent or per-project override layer. - Google ADK adapter ships without end-to-end integration tests. The PR includes server-level unit tests for event parsing and execution, and UI tests for the loadout editor. A full end-to-end test (agent creation → issue assignment → heartbeat execution → result) is not yet in place. The adapter is functional but the integration surface is less hardened than the OpenClaw adapter.
- Non-approval reply semantics are a breaking change for edge cases. PR #70 changes what happens when a human replies with free text that isn't an approval phrase. Previously the behaviour was undefined; now it's an explicit rejection. Any workflow that relied on free-text replies being ignored (rather than treated as rejections) will behave differently. The change is correct, but operators should be aware.
Open Challenges
- ClickUp pure-plugin adapter (PR #78) is still open. The bridge infrastructure (PRs #74 and #76) is merged, but the ClickUp transport itself is still in review. Until #78 lands, the bridge has the configuration layer but no live ClickUp transport wired to it. The full end-to-end path — company settings → bridge core → ClickUp transport → human reply → agent wake — is not yet closed.
- Bridge reconciliation coverage. Two PRs merged to the awaiting-human bridge this week, with a third (PR #78) still in review. The surface is being hardened rapidly, but the full reconciliation path (outbox → ClickUp delivery → heartbeat poll → interaction accept → agent wake) still lacks an end-to-end integration test. This was flagged last week and remains on the backlog.
- Multi-runtime agent routing. The Google ADK adapter landing opens a real question: how does an operator decide which runtime to use for a given task? Today the choice is made at agent-creation time and is static. Dynamic routing — assigning tasks to the best-fit runtime based on task type, cost, or latency — is not yet designed.
X Thread Teaser
🧵 Bizbox Build Log — Week of May 30, 2026
5 PRs merged, 2 releases shipped. The awaiting-human bridge got a full architecture upgrade, Google ADK landed as a first-class adapter, and the VMs got a resource bump. Here's what moved 👇
1/ New: Google ADK agent adapter. Bizbox can now create and run agents backed by Google's Agent Development Kit — registered in the same adapter registry as OpenClaw. First step toward runtime-agnostic orchestration.
https://github.com/zesthq/bizbox/pull/722/ Awaiting-human bridge: company-scoped config + lifecycle hardening. Each company can now configure its own approval channel (ClickUp first). Retries create fresh rows, free-text replies stay as comments, inbound events dedupe per interaction.
https://github.com/zesthq/bizbox/pull/74 https://github.com/zesthq/bizbox/pull/763/ ClickUp approval semantics are now deterministic. Thumbsdown = immediate rejection. Free-text non-approval reply = rejection with context forwarded. No more ambiguous states.
https://github.com/zesthq/bizbox/pull/704/ VMs doubled: 4 GB / 4 CPUs. Driven by real memory pressure from concurrent multi-agent heartbeats. Headroom > incremental tuning.
https://github.com/zesthq/bizbox/pull/735/ Open challenge: the ClickUp bridge adapter (PR #78) is still in review. The infrastructure is merged but the live transport isn't wired yet. The full approval loop closes when #78 lands.
Full build log: https://github.com/zesthq/bizbox/blob/master/community/build-logs/2026-05-30.md
Grounded in merged PRs and releases from zesthq/bizbox, 2026-05-23 to 2026-05-30. No activity was invented.