Images, audio, files, and rich output
BailingHub can accept image, audio, and file inputs, then return Markdown, attachment links, and declarative rich content. Upload, model understanding, and frontend rendering are separate responsibilities and must be configured independently.
Input media
Section titled “Input media”After upload, media storage creates a controlled asset URL. The route input policy decides what happens next:
- images may be analyzed or passed to a compatible multimodal model;
- audio may be transcribed or passed to a compatible model;
- files may remain attachments, while text extraction depends on configured processing support;
- missing models or policies should produce an explicit fallback, not a claim that the content was understood.
Formats, size limits, and item counts are versioned HTTP-contract details. Use the fixed release documentation when implementing a client.
Image attachment space for local agents
Section titled “Image attachment space for local agents”The host can register a locally generated image or one the user explicitly designates for business use as a current-conversation attachment. After upload, an authorized business tool can use its URL for a campaign cover or product image. Hosts explicitly integrate the attachment catalog and original upload records; images used only for chat understanding are not automatically registered or uploaded. Image generation, attachment upload, and business writes are configured and performed separately.
Attachment space is disabled by default. An administrator enables it for a workspace and selects storage. It currently accepts PNG, JPEG, and WebP, up to 6 MiB per image and 8 images per batch; lower limits can be configured. Images use public read access for public-facing media. The deployment operator manages retention; ending a conversation or revoking authorization does not delete files automatically.
Uploads link to the current conversation and turn, with an optional business run_id; uploading does not require creating a business task. After a lost connection, inspect the original upload ID and reuse completed URLs. Subsequent business writes retain their original authorization and approval requirements. See generated images and attachment space for setup.
Output capabilities
Section titled “Output capabilities”| Content | Official Widget behavior | Additional dependency |
|---|---|---|
| Markdown and tables | Safe built-in display | None |
| Images and file links | Rendered from the final reply and attachment structure | None |
| Charts | Declarative fenced payload passed to a trusted renderer registered by the host | The business page selects and installs the chart library |
bailing-form |
Built-in constrained fields, validation, submission, and receipt | No dynamic-form runtime |
The model supplies data only. It cannot select or execute JavaScript, HTML, CSS, remote scripts, or component code. Unknown types, invalid JSON, oversized payloads, and renderer errors must fall back to inert code text.
bailing-form is not approval
Section titled “bailing-form is not approval”bailing-form collects ordinary information or user selections. The source reply has already reached done; submit or cancel creates a new user turn and a new job in the same thread.
It does not replace:
- approval for a high-risk tool;
- login, identity verification, or authorization;
- payment confirmation or secret collection;
- final permission checks before a business-side effect.
Form values remain untrusted user input. A later business action still passes through capability scope, approval policy, and backend authorization.
Custom clients
Section titled “Custom clients”A custom chat UI declares only renderers it actually implements and trusts. Parse fenced payloads only from the complete done.reply, never mount charts or forms from delta, and never interpret model output with eval or innerHTML.