Attachments & multimodal

A conversation isn't only typing. Someone may record a voice note, snap a photo, or drop a PDF into the chat. AnyBot lets an agent take that in mid-conversation: it transcribes speech, describes images, and reads documents, then folds what it found into the same turn so the agent answers as if the person had typed it. This page covers what's actually supported, how it works, and what reaches the agent on each channel.

Voice notes → transcript

When a message arrives with an audio recording, AnyBot downloads it and runs speech-to-text, then splices the transcript into the user's message. Transcription is multilingual, Arabic included, so a spoken question in any supported language becomes text the agent reads normally.

The agent's own reply comes back as text. Turning that reply into spoken audio (text-to-speech) is a separate, channel-side step, not something the agent does itself.

Images → description

Attach a photo (a screenshot, a product shot, a receipt) and a vision model looks at it and produces a written description, which the agent then reads. This matters for expectations: the agent works from a description of the image rather than seeing pixels natively. That's excellent for "what's in this picture", "read this label", or "what error is on this screen", and weaker for pixel-precise measurement. If an image can't be fetched or described, the turn continues without it rather than failing.

Documents → extracted text

Send a file and AnyBot detects its type, extracts the text, and hands that to the agent. Supported formats:

An unsupported type doesn't break the conversation. The agent is simply told a file was attached that it can't read, so it can ask for a different format instead of guessing.

How the agent "reads" an attachment

The common thread: every attachment becomes text before the agent sees it. A voice note becomes a transcript, an image becomes a description, a document becomes its extracted contents, each spliced into the same user turn as an inline note (delivered to the model as an [AUTO](…) block). One consequence worth understanding: the agent handles a spoken or pictured question with the exact same reasoning, tools, and guardrails it uses for typed text. Your behavior & guardrails and answer-only-from-knowledge settings apply identically, and a more capable model bundle reasons over the transcript or description just as it would over typed input.

Two honest limits fall out of this design: attachments are per-turn (not saved as knowledge; see below), and image understanding is description-based, not pixel-exact.

What each channel forwards

An attachment only reaches the agent if the channel delivered it, and that varies by platform. The web chat widget accepts uploads directly; messaging channels forward the voice notes, photos, and files their own users send. A channel that doesn't support a given attachment type simply won't pass one along. The agent then only sees whatever text came with the message. Rather than assuming a channel supports voice or files, test the specific one you care about with a real attachment and confirm the agent responds to it.

Attachments vs. the knowledge base

These are different surfaces, and it's worth keeping them straight. An attachment is ephemeral context for one conversation, the file a customer sends right now, used for this turn only. The knowledge base is durable training you curate once: documents and pages you add so every future conversation can draw on them. Use attachments for "here's my situation" and the knowledge base for "here's what the agent always knows."

There's a nice symmetry: an image you add to the knowledge base is also read by vision AI and indexed as text, the same description-based approach, made permanent instead of per-turn.

Next

• Knowledge base, durable training vs. mid-chat attachments
• Abilities (tools), what the agent can do once it understands the request
• Testing your agent, send a real attachment and watch the turn