Two releases make data-agent boundaries testable instead of implied

Two open-source data projects shipped changes this week that look unrelated: QwenPaw-Data moved messaging out of its engine, while OrionBelt taught DuckDB to consume its governed query surface. Read together, they point to the same operating principle: a data agent is easier to trust when execution, delivery and query access meet at explicit contracts rather than sharing one process.

QwenPaw draws a line around execution

QwenPaw-Data 0.3.0 adds a headless HTTP and replayable-SSE runtime covering sessions, chats, attachments, artifacts, files, scheduled runs, steering, feedback, traces, snapshots, forks and signed share links. The same release removes engine-owned instant-messaging delivery; host applications now own delivery through that HTTP/SSE boundary.

That split matters operationally. QwenPaw’s repository architecture already separates governed facts in DataBridge, reusable methods in Skill-Hub and execution control in Host. Version 0.3.0 makes the outer integration boundary match that internal design: the runtime produces durable state and events, while a Slack, web or other host decides how users receive them.

The release also renames the public datapaw- packages and command to the qwenpaw-data- line, so adopters must treat 0.3 as a migration rather than a drop-in upgrade. Its four coordinated packages now require versions within the same 0.3 range, according to the release notes.

A new client found OrionBelt’s hidden assumption

OrionBelt 2.27.1 documents and tests DuckDB as a client of its Flight SQL surface through DuckDB’s community adbc_scanner extension. The recipe lets a governed query become a DuckDB relation that can be joined to local tables, aggregated or materialized.

Adding that client exposed a protocol defect existing clients had missed. Flight SQL’s CommandGetTables supports a four-column response or a five-column response that includes serialized table schemas, selected by the request’s include_schema flag. OrionBelt always returned five columns. Earlier tested clients requested that form, but DuckDB requested four and rejected the endpoint. Version 2.27.1 now parses the flag and keeps the streamed table and advertised FlightInfo schema aligned, according to the release notes.

OrionBelt’s README describes one semantic model exposed through REST, PostgreSQL wire, Flight SQL and MCP. The DuckDB result is a useful warning for every project making a similar claim: implementing an open protocol is not the same as proving interoperability. A second client can exercise a legal branch of the protocol that the first client never touches.

The practical test

For operators evaluating data-agent infrastructure, these releases suggest two checks. First, can the execution engine be upgraded, replayed and audited without coupling it to a specific chat transport? Second, has each advertised query protocol been driven by more than one independent client, including different metadata and schema-negotiation paths?

QwenPaw-Data and OrionBelt do not solve the same product problem. Their common contribution is narrower and more useful: each moved a boundary from an architecture diagram into a versioned, testable interface.