Skip to main content
Webanto Logo
USE CASE

Summarise long threads

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.

What to expect

  • 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.

How to set this up

  1. 1

    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.

  2. 2

    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.

  3. 3

    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.

  4. 4

    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.

  5. 5

    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.

  6. 6

    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.

  7. 7

    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.

Products that power this use case

Frequently asked questions

  • Will this miss important detail that a human summary would catch?

    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.

  • How long a thread can I summarise in one call?

    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.

  • Can it summarise a meeting transcript with multiple speakers, not just a two-party support thread?

    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.

  • Why does a long summarisation call cost more credits than I expected?

    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.

  • Should I use this for legally sensitive threads, like a dispute or complaint escalation?

    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.

Other use cases

Keep exploring

Related resources

Ready to try it?

Start a 14-day free trial on any paid plan. Cancel before it ends and you won't be charged.

Start free trial
Newsletter

Stay Ahead

Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.