Newsletter
Stay Ahead
Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.
Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.
Use case: Condense long support threads and transcripts into decisions and actions
A support thread that ran fifteen replies deep over three days, or an hour-long meeting transcript, is expensive to read back through when someone needs the outcome without the scroll. Webanto's chat endpoint takes the full thread or transcript as input and returns a short summary structured around what actually matters operationally, decisions made, action items with owners, and open questions, rather than a generic paragraph recap. Because Qwen3.6 is a reasoning model, it tracks who said what across a long back-and-forth and resolves references such as 'as I said above' more reliably than a single-pass summariser, though it should be pointed at a specific output structure rather than left to freeform to get consistently useful results.
A long thread or transcript becomes a short list of decisions, owners, and open questions instead of requiring a full re-read.
Action items come out with an attributable owner where the source text names one, reducing follow-up messages about who was supposed to do what.
Meeting transcripts get summarised in the same structured format as support threads, so teams that use both get consistent output.
Faster handoffs between shifts or team members, since incoming staff read the summary instead of scrolling the full history.
Assemble the full thread or transcript as plain text, with speaker or sender labels preserved (e.g. 'Agent:', 'Customer:', or attendee names) — the model uses those labels to attribute decisions and actions correctly.
Write a system prompt that specifies the exact output shape you want: a JSON object with decisions[], actionItems[] (each with an owner and description), and openQuestions[]. Don't leave the structure to chance.
Call POST /api/v1/chat with model 'qwen', the assembled transcript as the user message, and generous max_tokens: a reasoning model spends tokens thinking through a long, multi-speaker input before it writes the summary, so an under-sized budget on a long thread is the most common cause of a truncated or empty result.
Estimate cost before sending: a 50-message support thread or a one-hour transcript runs roughly 6,000-9,000 total tokens once you include the reasoning overhead, around 3-5 credits at 2,000 tokens per credit. Long, chatty threads cost proportionally more than short ones.
If a thread runs past what fits comfortably in one call, chunk it (by day, for instance), summarise each chunk, then run a final pass that summarises the chunk summaries into one.
Store the structured summary alongside the original thread rather than replacing it, so anyone who needs the full context can still go back to the source.
Review a sample of summaries against the source threads periodically. Summarisation drops detail by design, and it's worth confirming the dropped detail is genuinely the unimportant part.
Any summary drops detail by definition — that's the point of a summary. The risk is dropping the wrong detail. Point the prompt at a specific structure (decisions, actions, open questions) rather than a freeform recap, and spot-check summaries against source threads for the first few weeks to confirm nothing operationally important is getting lost.
There's a practical context limit, and a reasoning model uses part of that budget on its own thinking before it writes the summary. For very long threads, multi-day, dozens of messages, it's more reliable to chunk by day or topic and summarise each chunk, then summarise the chunk summaries, than to push one enormous transcript through in a single call.
Yes, as long as speaker labels are present in the text. The model uses them to attribute decisions and action items to the right person. An unlabelled transcript with no speaker markers will still summarise, but ownership attribution on action items becomes unreliable.
Two things add up: the prompt itself, the full thread, which can run to thousands of tokens, and the reasoning tokens the model spends working through it before writing the visible summary. Both count toward the 2,000-tokens-per-credit chat rate, so a long, dense thread costs meaningfully more than a short one even though the output summary ends up roughly the same length either way.
Use it to get oriented quickly, but don't treat the AI summary as the record of what was said or agreed for anything with legal weight — go back to the source thread for that. The summary is an operational aid, not a substitute for the original correspondence.
Shoppers who spot a product in the wild, on someone else's feed, or on a competitor's site rarely know the right keywords to find it in your catalogue. Visual search closes that gap: a shopper uploads
Large media libraries accumulate redundancy fast — the same product shot re-exported at a different crop, a stock photo uploaded twice under different filenames, a banner re-saved at a lower compressi
Reverse image search answers a narrower question than catalogue browsing: given one photo someone just handed you — a screenshot, a competitor's product shot, a customer's snapshot of a damaged item —
Start a 14-day free trial on any paid plan. No credit card required.