In under two years, prediction markets went from a niche corner of the internet for political junkies to platforms with sportsbook-level engagement.

Kalshi and Polymarket alone have hit millions of monthly active users.

For most industries, that growth curve gets a headline and a victory lap. For anyone responsible for trust and safety, it’s the exact scenario that keeps them up at night. You inherit a flood of users (and every bad actor who follows them) before your infrastructure has had time to catch up.

“These companies don’t know what or how they should moderate yet,” says Sam Richardson, Enterprise Account Executive at Stream who spends most weeks talking to the platforms building this category from scratch. “But they know they need to be catching everything now, before it gets out of control.”

Enter: moderation.

Quite possibly the most critical element for prediction markets right now. Why? Because the alternative (no moderation, free-for-all) could mean the end of an industry.

Sounds extreme, but we wouldn’t be afraid to bet on it.

Let’s get into it — and why you should care.

The Blind Spot Nobody Built For

Real-money gaming and gambling apps have existed for decades, but they were never social products.

“Historically, these companies were never thinking about moderation because there was no need. There were no user-to-user interactions. You logged in, transacted, and left.”

Prediction markets broke that model.

With trade chats, comment threads, and social feeds built around live events, engagement is now a feature. So what? Well, these platforms inherited millions of users and a genuinely social product, running on moderation infrastructure that was never designed to watch user-to-user behavior at all, let alone the specific kind that shows up when real money is moving on a live outcome.

Yes, it’s dangerous.

What’s Actually at Stake?

It’s easy to forget how new this category actually is.

Kalshi and Polymarket went from effectively nothing to millions of monthly active users in about a year and a half. That’s the entire lifespan of the industry so far.

“In prediction markets, you basically figure out your brand integrity in the first year and a half. After that, it’s locked in. The platforms that get ahead of it now are the ones setting the standard next year.”

For a builder in this space, it’s a product-integrity issue, on par with getting custody or settlement wrong.

Not to mention… the whole world is watching.

If prediction market apps drop the ball on moderation, the fallout could end the app entirely, and not always at the hands of a regulator.

App stores, cloud providers, and payment processors have shown they’ll pull support before any court does:

• Parler found that out in January 2021. Apple, Google, and Amazon Web Services all cut it off within days over its failure to moderate content inciting violence, and it was fully offline for more than a month.
• Omegle shut down for good in 2023 after years of lawsuits alleging its lack of moderation let predators target minors; its founder said the platform simply couldn’t carry that weight anymore.
• 8chan lost its infrastructure protection in 2019 after a mass shooter posted a manifesto there unchecked, and it never came back at scale.

A category like prediction markets that’s moving this much money, under this much scrutiny, won’t get a longer grace period than any of those did.

Compliance & Moderation Are Not the Same Bet

If Richardson had to guess, he’d say prediction markets are going to force the entire gambling and fintech industry to admit that compliance and moderation solve two different problems, and treating them as interchangeable is a mistake that’s about to get expensive.

“You can be fully licensed and still attract manipulation and abuse. Compliance asks ‘are we legal.’ Moderation asks ‘are we safe.’ Right now this category’s got the first one down and is winging the second.”

His prediction:

The platforms that survive the next two years of regulatory chaos will be the ones that put moderation first. Fancy lawyers aren’t the solution. And frankly, they should never have to get involved if moderation is dealt with upfront.

Now What?

Stream already powers moderation for 80% of prediction markets.

And with good reason.

While most of the moderation market is still selling one-size-fits-all detection, Stream’s models are built around context. They know the difference between a five-year user blowing off steam after a bad trade and a brand-new account running the exact same message pattern ten times in a row.

“Prediction markets mix finance, sports, and gambling, so people talk like it’s a gambling forum. Most of that’s harmless. The problem is the same language shows up right before something worse happens. Without context on who’s talking and how they’ve changed, a moderator looking at one message will miss it.”

That, on top of powerful LLM models, multilingual protection, and highly customizable rule builders, make one thing true. If you’re building a prediction market platform right now, there’s a real chance your biggest competitor is already using Stream.

The Bottom Line

Richardson’s read on where this goes? The apps that win in this category are the ones focused on retention. And retention is downstream of whether users trust what they’re walking into.

“If moderation isn’t part of the picture, this isn’t sustainable.”

It’s black and white.

The lawyers can keep you legal. They can’t keep you trusted. In a category this young, with this much money and this much regulatory attention, trust will determine who’s still around in two years.

Prediction Markets Have a Trust Problem. Here’s How to Solve It. was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Speech, text, and vision should share a single realtime loop with shared rules for turn-taking, tool use, and fallback.
• Turn-taking and state are core design work. Think voice activity detection, a turn policy, narrow tool calls, and memory that doesn’t make the conversation brittle.
• Vision involves sampled frames. Route precision tasks (like small on-screen text) to a specialized CV model instead of expecting the multimodal model to catch everything.
• Track turn latency, interruption recovery, tool round-trip time, and session drop rate.

If your app needs to listen, watch, and respond in the same session, a normal speech-to-text plus text-to-speech stack quickly starts to feel clumsy.

The best multimodal agents are not built as three separate pipelines stitched together. Rather, they should be designed as one realtime workflow that can process speech, text, and vision together, with clear rules for turn-taking, tool use, retrieval, and fallback behavior.

This guide breaks down how to design multimodal AI agent architecture for voice and video apps that hold up in production, using the architectural choices, transport options, and model constraints that matter most.

How To Think About Multimodal Realtime Agents

Evaluating a realtime agent starts with three questions.

1. How fast does it respond when the user interrupts?
2. What happens when vision input arrives late or is missing?
3. And can the system keep state across a long call without drifting into nonsense?

Those questions come from the same failure modes showing up over and over. A clean demo often falls apart on barge-in, noisy audio, or a camera feed that updates slower than the conversation. A useful agent needs a turn detector, a transport that stays stable under load, and a way to decide when speech, text, or vision should drive the next action.

The other thing worth checking is whether the system treats multimodality as one loop or as separate services. If a product sends audio to one service, images to another, then tries to reconcile the outputs in a third layer, the user usually pays for that in delay.

The better systems keep the conversation together and make each input type part of the same session state.

One Loop, Not Three Pipelines

The old chain of ASR to LLM to TTS still works for short prompts, but it gets awkward the moment the user talks over the assistant or points the camera at something that changes quickly.

In a live support call, even a 700 ms pause can feel long. In a coaching or telehealth flow, a delayed response can make the agent miss the moment that matters.

The shift is architectural. Audio, images, and text flow through a single live session instead of separate services stitched together after the fact. The model is part of the live loop.

That matters for interruption handling, too.

If the model hears the user start talking before the previous response has finished, it can stop, adjust, or defer. If the camera feed changes while the call is active, the agent can use that frame as part of the same turn instead of waiting for a separate vision pipeline to catch up.

Choosing Your Transport

Transport choices decide how much control you have over the session, where media can originate, and how hard the whole thing is to debug.

WebRTC is the default choice for browser-based voice and video agents because it was standardized for real-time audio and video on the web. In practice, that means lower friction for mic and camera capture, a better fit for bidirectional media, and fewer awkward hops through a backend that was never meant to handle media timing.

For phone-based agents, Twilio is usually the practical path since the media already lives in telephony, bridging a call into the agent session rather than asking the user to switch to a browser.

Turn-Taking, Tools, and State

The core work is session design.

A production agent needs a voice activity detector, a turn policy, a tool router, and some memory of what just happened.

In a real call, the sequence is usually messy:

• The user starts speaking before the agent has finished
• A tool call returns while the agent is still generating audio
• The same user asks a follow-up that depends on the previous answer
• The session needs to fall back to text if audio drops

The agent should know when to pause, when to continue, and when to call a tool.

Tool calls work best when they are explicit and narrow. A calendar check, a CRM lookup, and a policy search should not all go through one generic endpoint if the output needs to be dependable.

And state matters as much as the tool layer. A live session needs enough memory to keep context, but not so much that the conversation becomes brittle. That means server-side controls, guardrails, conversation lifecycle management, and cost monitoring. Not just a longer prompt.

Vision: Frames, Not Video

One common mistake is assuming a video agent is watching everything all the time. That is rarely true in production.

Most systems use sampled frames, short clips, or still images, then combine those with audio and text. In practice, the model treats a frame more like a photo dropped into the conversation than a continuous stream it’s watching. That distinction matters because it changes what you can expect from the model and where you need extra CV logic.

For applications that need precise visual cues, a specialized vision model often does the first pass:

Vision Agents leans into that pattern with pluggable vision pipelines, frame-by-frame processors, and support for models such as YOLO and Roboflow alongside larger language models. That is the sensible split for use cases like golf coaching, form checks, or screen walkthroughs.

The other constraint is context length.

Video understanding gets weaker in longer continuous sessions, especially after roughly 30 seconds, and that small text is a weak spot. That lines up with what to expect from any live system: if the user needs OCR-level accuracy on a tiny UI element, route that task to the right model instead of waiting for the multimodal model to guess.

Grounding With Retrieval

Live multimodal agents break down quickly when the answer depends on policy, product details, or account-specific context. Retrieval is the difference between a fluent answer and a confident mistake.

For voice and video apps, the retriever needs to be fast enough to stay inside the session. Vision Agents supports two practical paths here: Gemini File Search for quick setup, and TurboPuffer for hybrid vector plus BM25 search with reciprocal rank fusion. The details matter because the agent may need a short policy paragraph, a meeting note, or a case file while the user is still talking.

RAG is also what keeps phone and support agents from hallucinating on local rules. In a telephony workflow, the agent can answer an intake question, check a knowledge base, then hand off a concise summary to a human if needed. That is a better fit than trying to make the model remember everything in the prompt.

Deploying and Monitoring

A realtime agent is easy to launch and harder to keep healthy.

The things that usually show up first are packet loss, slow turn detection, and cost creep from long sessions. After that comes observability. With no trace of which turn triggered which tool call, you’re stuck guessing what happened.

Vision Agents takes a practical approach here. The project includes HTTP server support, Prometheus metrics via OpenTelemetry instrumentation, Docker, and Kubernetes deployment. In practice, teams can watch LLM, STT, TTS, and turn detection metrics without rebuilding the same plumbing themselves.

For production tuning, the numbers that matter most are:

• end-to-end turn latency
• interruption recovery time
• tool-call round-trip time
• frame processing delay
• session drop rate

If those are not measured, the agent is being tuned by feel.

Is Vision Agents a Fit?

Vision Agents makes sense when the app is truly multimodal and the team wants Python-first control over transport, tools, and deployment. It fits best when the workflow needs voice, video, RAG, and a clear path to production monitoring in the same codebase.

A simple way to judge fit is to ask whether the app needs frame-level vision plus live audio in one session.

If the answer is yes, the framework’s modular agent design, WebRTC support, Twilio calling flow, and deployment tooling line up with that problem.

If the answer is only voice, with no real vision or custom tool layer, it may be more framework than the project needs.

For teams evaluating it, run one interruption test before anything else. Start a live session, point the camera at a page with small on-screen text, then interrupt the agent mid-answer and ask it to read a specific line from the frame. A useful system should stop cleanly, recover the turn, and send the right visual task to the vision pipeline without losing the conversation state. If that fails, the rest of the stack usually has the same weakness.

The Vision Agents quickstart is the fastest way to set up that test.

Frequently Asked Questions

What is a multimodal AI agent for voice and video?

A multimodal agent processes speech, text, and vision in one live session. In practice, that usually means audio streaming, sampled frames or images, tool calls, and a response loop that can handle interruptions.

Should voice and video agents use WebRTC or WebSockets?

WebRTC is the better fit for browser audio and video because it is built for real-time media. WebSockets still make sense for server-side orchestration, control messages, or middle-tier apps that are not sending media directly from the client.

Do multimodal agents need continuous video understanding?

Usually not. Many production systems use discrete frames or sampled clips, then combine that with live audio. That keeps latency lower and makes the vision side easier to control.

Why does turn detection matter so much?

Without turn detection, the agent will talk over the user, cut off too early, or wait too long to answer. Voice activity detection and turn policy are what keep the session usable.

When does RAG matter in a live voice or video app?

RAG matters any time the answer depends on policy, product details, a support article, or account-specific context. It keeps the agent from guessing when the correct answer is already in a source document.

Is Vision Agents more suited to voice-only or multimodal builds?

It is better suited to multimodal builds. The framework is built around voice, video, retrieval, and deployment in one workflow, so it makes more sense when vision is part of the product rather than a side feature.

Multimodal AI Agent Architecture: Designing Voice and Video Apps was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Deepfakes broke the old assumption that seeing a face on a call proves who’s on it. Encryption and account logins were never designed to check that.
• A video call has four separate security layers: transport encryption (DTLS), media encryption (E2EE/SFrame), account authorization (tokens and roles), and human verification. Only the last one checks who’s actually on camera.
• Stream covers transport encryption today and is adding native E2EE (SFrame) to the React SDK. Verifying the person on screen stays the developer’s responsibility.
• Zoom and Microsoft shipped identity verification into mainstream video products in 2026. The question for developers is which of their own call types need the same guarantee.

In January 2024, a finance worker at the engineering firm Arup joined a video call with his company’s CFO and several colleagues. The request was unusual: a series of confidential transfers, authorized on the spot. But the people asking were familiar faces, live on camera. He made 15 transfers totaling HK$200 million (about US$25.6 million) to five bank accounts.

Everyone else on that call was a deepfake, assembled from publicly available footage and voice samples.

Nothing about the session was compromised in the traditional sense. The connection was encrypted. The meeting was real. The attack worked because every security control involved verified the session, and none of them verified the humans in it.

This piece walks through what a video call actually secures today, where the gaps are, and what closing them looks like in practice.

Why is Human Verification Arriving Now?

Like they say in “All The President’s Men,” always follow the money. The costs explain the urgency. Deloitte’s Center for Financial Services estimates that AI-enabled fraud losses in the US could grow from $12.3 billion in 2023 to $40 billion by 2027.

We can think about AI-enabled fraud along two axes:

1. Quantity. Generative AI collapses the cost of volume. Scams that once needed a human to write every message, business email compromise being the classic case, can now run against thousands of targets at once, each message fluent, personalized, and free of the tells that used to give phishing away.
2. Quality. The same models collapse the cost of fidelity. Producing a convincing human face in real time used to require resources far beyond a typical fraud operation, and now it runs on cheap, accessible tooling.

Volume is a problem the industry already has defenses for: spam filters, rate limits, anomaly detection, all tuned across years of email and payment fraud. Fidelity has nothing comparable yet.

Two years after the Arup call, that gap is reshaping product roadmaps. In April 2026, Zoom announced a partnership with Tools for Humanity to integrate World ID Deep Face into Zoom Meetings, verifying in real time that participants are actual humans. Verified attendees get a “Verified Human” badge on their video tile.

Microsoft has been moving in the same direction with Entra Verified ID, and its identity team frames the problem plainly: existing systems verify credentials, sessions, and devices, not the person behind them.

The two efforts sound similar but make two different promises, and the distinction matters when you’re deciding what your product actually needs. World ID is proof of humanity. It confirms that a real, unique human is present without revealing who they are. Microsoft Entra Verified ID sits closer to traditional identity proofing. Its Face Check flow compares a real-time selfie against the photo from a government ID and shares only the match result with the relying application.

Different products need different guarantees. A marketplace fighting bot armies needs proof of human. A payroll approval flow needs proof of person. A telehealth platform probably needs both, plus a record that verification happened. Knowing which guarantee your high-stakes moments require shapes every downstream build decision.

What Can a Video Call Verify?

There are four things a video call can verify: the connection, the media, the account, and the person. Each has its own control, each control answers exactly one question, and none of them covers for the others. That sounds obvious written down. In practice, the four get collapsed into one word, “secure,” which is how a company ends up wiring $25 million to a face on a screen.

The first three check the connection, the media, and the account. None of them looks at the person, so their gaps all reduce to the same case: a fake face in a legitimate session. The fourth control closes exactly that gap, and until this year, no mainstream video product shipped it.

The Connection: Transport Encryption Stops at the Media Server

Transport encryption is the control that every video product already ships. Its job is to keep anyone sitting on the network path from reading or tampering with your packets, whether that’s a coffee shop router, an ISP, or a compromised hop somewhere in the middle.

In WebRTC, that means DTLS (Datagram Transport Layer Security), because media travels over UDP and TLS assumes a reliable, ordered connection that UDP doesn’t provide. DTLS is TLS reworked for packets that arrive late, out of order, or not at all. It produces the keys SRTP uses to encrypt the audio and video, and it encrypts data channels directly.

The current version is DTLS 1.3, and it’s the reasonable minimum to ask of any video infrastructure in 2026. Plenty of deployments are still running 1.2. If you want to know if your stack is running it, the WebRTC stats API reports it directly:

// pc is your RTCPeerConnection
const stats = await pc.getStats();
stats.forEach((report) => {
  if (report.type === "transport") {
    // tlsVersion is wire-format hex: "FEFD" is DTLS 1.2, "FEFC" is DTLS 1.3
    console.log(report.tlsVersion, report.dtlsCipher, report.srtpCipher);
  }
});

If that prints FEFD, you’re on 1.2. If it prints FEFC, it’s 1.3. If you’re using Stream, you also have access to the WebRTC stats API through the useCallStatsReport() hook:

import { useEffect } from "react";
import { useCallStateHooks } from "@stream-io/video-react-sdk";

// Maps the hex `tlsVersion` reported in RTCTransportStats to a readable name.
const DTLS_VERSIONS: Record<string, string> = {
  FEFD: "DTLS 1.2",
  FEFC: "DTLS 1.3",
};
const readTransports = (stats, leg) => {
  const out = [];
  stats?.forEach((r) => {
    if (r.type === "transport") {
      out.push({
        leg,
        dtlsState: r.dtlsState,
        tlsVersion: r.tlsVersion,
        dtlsCipher: r.dtlsCipher,
        srtpCipher: r.srtpCipher,
      });
    }
  });
  return out;
};
export const DtlsCheck = () => {
  const { useCallStatsReport } = useCallStateHooks();
  const report = useCallStatsReport();
  useEffect(() => {
    if (!report) return;
    const transports = [
      ...readTransports(report.publisherRawStats, "publisher"),
      ...readTransports(report.subscriberRawStats, "subscriber"),
    ];
    transports.forEach((t) => {
      // Until the handshake completes, tlsVersion/ciphers are undefined.
      if (t.dtlsState !== "connected" || !t.tlsVersion) {
        console.log(`[dtls:${t.leg}] handshaking… (state=${t.dtlsState})`);
        return;
      }
      console.log(
        `[dtls:${t.leg}] ${DTLS_VERSIONS[t.tlsVersion] ?? t.tlsVersion}`,
        `| dtlsCipher=${t.dtlsCipher}`,
        `| srtpCipher=${t.srtpCipher}`,
      );
    });
  }, [report]);
  return null;
};

Here’s the catch.

Almost every production video product routes calls through an SFU (selective forwarding unit) because peer-to-peer meshes stop scaling past a handful of participants. And in an SFU architecture, transport encryption is hop-by-hop: the server terminates the encrypted connection, handles your media as plaintext frames, and re-encrypts on the way out to each recipient.

The server needs that access to route packets, and features like recording depend on it, so this is by design. But it means transport encryption alone never gave you end-to-end anything in a group call. It secures the path to the server and the path from it, and the server itself sees everything.

Stream runs DTLS 1.3 across the whole media path, including the hops between its own media servers when a call cascades across multiple edge locations.

The Media: Encryption the Server Can’t Read

If the SFU sees plaintext, the fix is to encrypt the media itself in a way the SFU can route without reading it. That’s what SFrame does. Each media frame is encrypted and authenticated end-to-end between participants, while the packet metadata the SFU needs for forwarding decisions stays visible. It was designed for server-routed conferencing from the start, and it’s the approach the industry has converged on.

Browser support is through WebRTC Encoded Transforms. This API lets you intercept and modify encoded frames before they’re sent. You can use this to roll your own media encryption, but doing so can fall apart for a few reasons:

• The SFU has to be in on it. A frame carries two separable things: the content (pixels, audio) and the structure (is this a keyframe, which quality layer, what it depends on). For routing, the server only ever needs the structure. E2EE splits the two: content gets encrypted, and structure moves to cleartext fields the server can still read. Clients and servers have to agree on that split, which is what SFrame standardizes.
• Keys need their own secure channel. Everyone on the call has to hold the same frame keys while the server holds none of them, and the set of people changes mid-call: someone joins, someone leaves, and the keys rotate so the newcomer can’t read the past and the leaver can’t read the future. There is an entire protocol for this problem, MLS, and it’s not a gap you can vibe-code through.
• Every server-side media feature breaks. Recording, transcription, captions, AI summaries: they all depend on the server decoding your media, and a server that can’t read frames can’t process them. Zoom and Teams both ship E2EE and publish the same kind of trade-off list. Zoom’s E2EE mode turns off cloud recording, live transcription, AI Companion features, streaming, whiteboards, and polling. Teams E2EE drops recording, captions, and transcription, and limits which clients can join.

Those tradeoffs are real product decisions: which call types get E2EE, what users are told about the features they lose, how compliance recording works when regulation requires it. They get made at the platform level, in coordination between the SDKs and the media servers. Bolting frame encryption onto app code skips the coordination and inherits all the breakage.

Stream is adding native end-to-end encryption to the React SDK in Q3 2026, with other SDKs to follow, built on the SFrame approach so it works with Stream’s SFU and cascading architecture rather than around it. Stream has already made the public argument for this direction: SFrame is what makes E2EE viable for group calls without giving up the scalability of selective forwarding.

The Account: Tokens and Roles You Can Tighten Today

When building video, this is where weaknesses are usually self-inflicted. Stream won’t admit anyone to a call without a JWT your server signed, and the role attached to that token decides what the account can do once it’s in: join, publish, record, moderate. Call-scoped tokens handle narrow cases, such as granting a guest access to a specific call.

All of it is only as strict as you configure it. For anything sensitive:

• Generate tokens server-side with short expirations. Tokens are signed with your API secret, and anyone holding that secret can mint a valid identity for any user in your app, so it never touches a client. A long-lived token is a bearer credential waiting to leak.
• Keep default roles minimal. Grant join and publish, then add capabilities per role on purpose. It’s much easier to widen a narrow role than to walk back a broad one.
• Don’t ship permissive call types. Stream’s development call type has everything enabled by design to keep friction low while you prototype. It has no place in a production flow that touches money or health data.
• Prefer call-level grants over app-wide ones. A support agent who needs recording on one call type doesn’t need recording rights across all call types.

A deepfake defense means very little if anonymous users can wander into sensitive calls because a call type is shipped wide open. That’s the full extent of it, though. Token auth verifies an account and authorizes what it can do. It has no opinion about the face on screen.

The Person: The Gap No SDK Closes For You

A user signs in and gets a valid token from your server. Their device is real. The call is end-to-end encrypted with keys only the participants hold.

And the “camera” the browser is capturing from is a virtual camera device, playing a real-time deepfake.

Nothing in the stack objects. The transport encrypts it, SFrame encrypts it, the token checks out, and the encryption even works against you here: no intermediary can inspect the stream. Every control below this one is doing exactly what it was designed to do.

Stream verifies the session, not the human, and so does every other video infrastructure provider today. A valid token tells you your app admitted the right account. It can’t tell you the webcam feed belongs to the person who owns that account, that the feed is live, or that a virtual camera isn’t sitting in the capture path. No SDK flag changes that, whatever the marketing around “deepfake protection” implies.

Zoom’s implementation shows what closing the gap looks like in practice, and it breaks down into five pieces:

1. An enrolled reference. Users verify once at an Orb, and that enrollment becomes the reference for every subsequent check.
2. A gate at entry. With a Deep Face Waiting Room on, nobody gets into the meeting until they’ve verified against it.
3. A check at the moment of decision. Any participant can trigger re-verification of another participant mid-meeting when a request seems off.
4. A check bound to the live stream. What gets matched is the video Zoom is actually transmitting on the person’s own device, so there’s no way to verify with one camera while streaming from another.
5. A visible result. Verified participants carry a badge on their tile that everyone else can see.

You can build every part of this:

1. Your enrolled reference. Decide what identity you trust: an IdP account with MFA at the low end (it proves the account, not the face), a verifiable credential like Entra Verified ID, or a document-plus-selfie enrollment with an identity verification vendor at the high end.
2. Your gate at entry. Your server already issues the call token, so the gate is the token endpoint: for sensitive call types, no verification, no token.
3. Your check at the moment of decision. Before the wire transfer or the account recovery, force a fresh challenge: a step-up IdP login (SSO, passkey, MFA), a liveness check, or, for irreversible actions, out-of-band confirmation on a second channel. The Arup attack dies here.
4. Your check bound to the stream. This is the piece that’s hardest to buy today. Most identity verification products capture in their own flow, separate from the call. A virtual camera can feed that flow the same way it feeds yours using synthetic frames written straight into the pipeline. So a liveness check that only sees what the “camera” shows is checking the deepfake itself.
5. Your visible result. Surface verification state on the participant in your UI, and write it to an audit log, because “we verified them at 2:14 pm” is the record that matters afterward.

Four of the five are buildable today from parts that already exist. The check that would have caught the Arup call is the out-of-band step in number three, and that’s ordinary engineering.

Number four, binding the check to the stream itself, is the piece the market hasn’t productized yet; Zoom shipping it is the clearest signal the gap is temporary. And the asymmetry runs in your favor. An attacker has to get past every check you put in the path, while you only need one of them to fire.

What to Build, By Stakes

None of this needs deciding product-wide. The controls sort by workflow, and most products end up running all three tiers side by side:

The first two rows are becoming the platform’s job. Stream covers the first today, and the second arrives with native E2EE in the React SDK in Q3. The third stays with your application, and it should, because an infrastructure provider can’t know that one particular button in one particular call authorizes a wire transfer.

That third row is also getting easier to fill. Zoom shipped proof-of-human verification into meetings this year, and Microsoft is certifying identity-verification partners for Entra Verified ID. What was an exotic enterprise add-on eighteen months ago is turning into a standard part of the stack.

The Arup employee did everything his tools asked of him. He joined a real meeting through real software and trusted the encrypted, authenticated faces on screen. Every control in that call did its job; none of them was pointed at the people. That’s the part that finally changed this year. Deciding which of your calls need it is the part that’s yours.

The New Security Requirements for Real-Time Video Infrastructure was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago, I visited my uncle in Spain. A professional painter and photographer, he’d recently turned his camera to the sky at night.

His images were incredible. Bright, sharp, and full of detail, his images were mesmerizing, and I completely got the astrophotography bug. One problem: my photography skills are closer to that of a macaque than a professional photographer, and I don’t have the $20k he spent on his rig.

Enter smart telescopes. These incredible little machines give people with “limited” ability the chance to capture images that used to demand years of practice and thousands of dollars worth of equipment. I share these with my family and friends, and once in a while online on the right subreddits, but it would be great to have a proper place to share, discuss, and compare notes with other people who’ve caught the same bug.

That is what we’re going to build here: AstroFeed. Members post their astrophotography with target, equipment, and exposure metadata, talk in channels and DMs, and join a standing “star party” video call.

But when I say “what we’re going to build here,” I don’t mean you and me; I mean Claude and Agent Skills.

So, What Are Agent Skills?

Claude Code has a feature called skills: folders of instructions, reference docs, and rules that sit in your project and that Claude reads when they’re relevant to what you ask. The simple idea is that Claude can reference the exact knowledge it needs via these skills rather than searching the web and finding outdated or wrong information.

Stream’s Agent Skills are the Stream SDK expertise packaged that way. One command (getstream skills — claude) installs a router that reads your prompt and figures out what you’re trying to do, a docs-search skill, and a general builder. The platform packs (React, React Native, Swift, Android, Flutter) install themselves on demand when the router needs one. AstroFeed is a Next.js app, so everything here runs through stream-react, which brings:

• Bundled references and blueprints. The agent works from Stream’s current docs rather than whatever it half-remembers from training, and only fetches live docs when the bundled knowledge runs out.
• Hard rules. Never read .env.local, don’t touch files the current track forbids, and check the schema before any CLI write.
• Tracks for different jobs. Scaffold a new app, enhance an existing one, or audit what’s already built.
• A verification step. Every phase ends with type checks, a production build, and a headless browser test that takes actual screenshots.

That’s the promise. I wanted to see the practice. So I ran this build as a bit of an experiment. Each phase starts in a fresh Claude Code session with a deliberately cold one-line prompt, to check whether the router lands on the right track with no help.

For the record, this is built with Claude Code 2.1.220 running Fable 5, and using getstream CLI 1.1.0.

The Plan in the Prompt

The only real input I gave this build was a plan document. Phase 0’s opening prompt in Claude Code was the plan itself, pasted whole. Every prompt after that was a one-liner or a two-sentence follow-up.

It’s also the input that matters most. An agent will build confidently with whatever you give it, so a vague plan doesn’t fail loudly. It fails as drift, and you spend the whole build nudging Claude back on course one correction at a time. The plan is where you spend that effort once, up front: what to build, in what order, what not to build, and what happens when something goes wrong.

I drafted mine in a regular Claude chat before any code existed, then handed the finished document to Claude Code. Here it is, trimmed of the per-phase prompts and expected-behavior notes:

## What we're building

A web app where amateur astronomers share their astrophotography and talk
about it. Next.js, built through the `stream-react` skill.

Features, in build order:

- **Photo feed.** Members post shots: the image, a target name (M31, the
  Orion Nebula), the equipment used, an optional exposure line, a short
  caption. The card is image-forward with the metadata laid out under it,
  which means custom feed UI and image attachments, both of which should
  force docs lookups.
- **Discussion chat.** Two channels (#general and #gear) plus DMs.
- **Star party call.** One page that joins a standing video call by ID.
  Minimal on purpose: it exists so the Video audit (Track F) applies at
  the end.
- **Moderation.** Blocklist and automod on both chat and feed content,
  configured through the CLI.

Keep the product surface exactly this. No gold-plating, no extra features.
If something in this spec conflicts with what a skill wants to do, stop
and ask me rather than improvising.

## Build log protocol

Maintain BUILD_LOG.md. After each phase, append: the exact prompt
(verbatim), which skill and track activated, what the skill did, manual
interventions, and surprises. Prefer verbatim capture over summary.
Never fix a skill's mistake silently.

## Session discipline

Start Phases 1, 2, and 3 in fresh Claude Code sessions. Part of what
this evaluates is whether the router picks the right track from a cold
prompt, and carried-over context contaminates that. BUILD_LOG.md is the
cross-session record, so read it at the start of each new session.

## Phases

0. Prerequisites and versions
1. Scaffold the feed (Track A)
2. Add chat (Track E)
3. Add the star party call (Track E)
4. Moderation via CLI

## Hard rules

- Never read or print `.env.local` or any secrets.
- No SDK upgrades, no migration tracks.
- If a skill fails or misroutes: log it first, retry once with a
  rephrased prompt, then escalate to me.
- Ask before any deviation from the spec above.

It didn’t make me immune to my own mistakes, though. Two of the plan’s follow-up steps never got sent, and both times it was the log that caught it before I did.

One Sentence to a Running Feed

Phase 1’s prompt, in full:

"Build me a Feeds app for sharing astronomy photos."

That one sentence allowed Claude and Agent Skills to do a lot of work:

• Routing and self-install. The router classified the prompt, picked stream-react, noticed the pack wasn’t installed yet, and downloaded it before moving on.
• Onboarding. It logged me into Stream through the browser and had the CLI write credentials to .env.local, which the agent never reads, per its own rules.
• Recovery. My project folder sits inside a yarn Berry workspace, and the standard shadcn scaffold command picked up the parent workspace and broke. The session scaffolded with create-next-app into a temp directory instead, moved the files in, ran shadcn on top, and checked nothing had leaked into the parent.
• A self-caught bug. tsc flagged a missing field on the SDK’s Attachment type. Fixed before I ever saw it.
• Verification. Clean production build, then a headless Playwright pass: log in, post an image, confirm it renders on the timeline, delete the test post.

A few minutes after the prompt, I had a token endpoint, a login page, and a working feed: composer, post cards, comments, follows, profiles.

The app was ready to use:

An interesting point here is that there were zero live docs fetches. I’d expected the custom feed work to send it off to Stream’s documentation. Instead, every API decision came from reference files bundled inside the skill itself, and the docs-search skill never fired once.

But probably the nicest part here for any developer was the getstream login:

Almost any app you build requires you to share your API key or secret; Stream is no different. Usually that means logging into the dashboard manually and copying them over. Using the CLI, this is all automatic. It even looks through the possible apps in your account and will choose the most logical one (e.g., my astronomy app here).

Forgetting the Spec

Unfortunately, “Build an astronomy app. Make no mistakes” might work on Claude, but doesn’t work on me, because I made a mistake. The initial prompt was a little too sparse. Claude had told me to expand, but I’d forgotten.

This is a good lesson for LLM coding: you are still at the mercy of stupidity.

The cold prompt built a correct, generic photo feed. Caption box, image upload, done. The target and equipment fields, the image-forward card, all of it existed only in my plan document, because I never sent the follow-up. Look closely at the screenshots above, and you’re looking at the generic composer.

The log caught it. The log-keeping pass audited the phase against the plan’s done-when line and marked Phase 1 incomplete. So I resumed the session and sent the spec, word for word:

Photo posts need structured metadata: a target name (e.g. M31, Orion Nebula), 
equipment used, an optional exposure line, and a short caption. The card 
should be image-forward with the metadata laid out under it.

About five minutes later:

• The right data model, with a citation. It put the metadata on the activity’s custom field and pointed at the bundled Feeds reference documenting exactly that pattern.
• A rewritten composer and card. Target required, equipment and exposure optional, full-bleed photo with the metadata laid out underneath.
• Its own re-verification. A fresh Playwright pass posted a test M31 shot, checked the card rendered per spec, and deleted it.
• Zero docs lookups. Everything it needed was already loaded from the first pass.

The lesson here is explicitness: The model doesn’t know what you want; your plan must contain every detail (or a way to catch missing details).

Adding Chat, and a Fight With the CSS Cascade

Fresh session, cold prompt:

"Add Chat to this app."

The harness recognized an existing app with Stream already in it and built around it:

• Zero server configuration. Stream ships a built-in messaging channel type, and it just works. Not one CLI call in the whole main pass.
• The first live docs fetches of the entire build. Two of them. “Start a DM by username” isn’t in any bundled blueprint, so it went to the live docs to confirm the distinct-channel pattern and the context API for switching channels.
• The usual wiring. Dual tokens from the token route, a chat client alongside the feeds client, and a chat panel assembled from Stream’s prebuilt components.

By this point I had two browser windows logged in as different users, and the feed side had comments and reactions flowing between them while chat took shape.

This is where the first issue came up. Stream’s chat stylesheet ships flex: 0 1 auto on the channel window, so my chat pane rendered at 460 pixels inside a 700-pixel space. The session’s first fix, a Tailwind arbitrary variant ([&_.str-chat__channel]:flex-1), silently did nothing, for two stacked reasons:

• Tailwind converts underscores to spaces inside arbitrary variants, so a selector containing __ can never match anything.
• Stream’s stylesheet is unlayered while Tailwind v4 utilities live in a layer, so the SDK wins the cascade anyway, even with an ! modifier.

The working fix was a small scoped CSS module that simply out-specifics the SDK’s single-class rules:

.channelPane :global(.str-chat__channel),
.channelPane :global(.str-chat__container),
.channelPane :global(.str-chat__main-panel) {
flex: 1 1 0%;
min-width: 0;
}

Worth noting how this got caught: tsc and next build were green the whole time. Only the Playwright screenshot check saw the squashed layout.

I also wanted to add specific #general and #gear channels at this point. Instead of creating the channels through the CLI or client code, the session put idempotent get-or-create and add-member calls in the token route. Every login converges on membership, and the existing channel list picks them up with zero client changes:

const SHARED_CHANNELS = [
{ id: "general", name: "#general" },
{ id: "gear", name: "#gear" },
];
// In the token route, on every login:
await Promise.all(
SHARED_CHANNELS.map(async ({ id, name }) => {
const channel = chatClient.channel("messaging", id, {
name,
created_by_id: userId,
});
await channel.create(); // no-op get-or-create after the first call
await channel.addMembers([userId]);
}),
);

A Star Party in One Page

Fresh session, cold prompt:

"Add a video call page for our star party nights. One page, one standing call 
joined by ID, no lobby, no ringing, no call lists."

The track picked it up and continued the build:

• No gold-plating. One nav tab, one page, the prebuilt SpeakerLayout and CallControls, and nothing else. It didn’t try to build a calling experience.
• Mostly bundled knowledge again. The video references shipped with the pack covered nearly everything, with a single live fetch for running chat and video clients side by side. Where the bundled snippet and the live page disagreed, the pack’s stricter version won, which is the precedence its own rules prescribe.
• The first CLI write of the entire build. A one-field app update setting the video use case, which the reference calls for and which had been sitting at null.

Getting to two clean tiles took a fight. The first smoke test showed four participant tiles for two users.

The cause is a React strict mode classic. Strict mode mounts every component twice in development. The first mount kicks off join(), cleanup fires while that join is still in flight, and leave() does nothing because there’s nothing to leave yet. Then the original join resolves anyway and orphans a session that keeps right on publishing.

The session diagnosed it and extended the canonical join pattern with a liveness check:

useEffect(() => {
if (!client) return;
const c = client.call("default", STAR_PARTY_CALL_ID);
let active = true;
c.join({ create: true }).then(() => {
// If the effect was cleaned up while join was in flight, the cleanup's
// leave() no-oped (not joined yet) - leave now to avoid a ghost session.
if (active) setCall(c);
else c.leave().catch(() => {});
});
return () => {
active = false;
c.leave().catch(() => {});
};
}, [client]);

tsc was clean, the production build was clean, and the console was clean. Only the screenshot check saw four tiles where two belonged. That’s the second bug of this build that no static check could have found, and the fix is three lines that arguably belong upstream in the reference snippet itself.

Moderation with Zero App Code

Final prompt to add moderation:

"Set up moderation: a blocklist and automod on chat messages and feed posts."

This phase changed no application code at all, which is the correct answer. Moderation on Stream is server-side configuration, and the session treated it that way: everything through the CLI, with the review UI left to the Dashboard, where it already lives.

It was also the phase where the docs machinery finally got a real workout:

• The first true escalation. The pack’s docs map has no moderation section at all. The session guessed a URL and got a 404. The docs-search skill resolved the right index and worked from there.
• It checked for existing config before writing any. Stream apps ship with a built-in profanity blocklist, 1,105 words. The session found it and skipped creating a duplicate.
• Three writes. Attach the blocklist to the messaging channel type. Set app-level moderation config for chat. Set it again for feeds, which turns out to be a separate config key, with AI text rules like HATRED, INSULT, THREAT, and SCAM. Everything set to flag, nothing to remove.
• Verification. It read the config back, then ran the moderation engine against sample text in a test mode that persists nothing. A blocklist word flags and a strong insult flags, but “worthless idiot” doesn’t, which tells you the AI engine has severity thresholds.

Two findings from this phase belong in Stream’s docs backlog. The policies page’s example labels, SPAM and HARASSMENT, but Claude tells me the API rejected both, and the real label set (34 of them) lives on a different page and contains neither. And that test mode isn’t mentioned in any reference the session had. It found it by reading the CLI’s own help output.

Obviously I wanted to test it, so I added a “This is f***ing sick!!” under a nebula shot (which is sick!). The comment was sitting there in plain view, which was unexpected to me, but expected to the model:

Review queue: 2 items, both processed automatically (status: complete), 
nothing awaiting human review.

1. The flagged feeds comment (by user jo): text "This is f***ing sick!!" - 
tripped the blocklist, matched word fucking under the profanity rule, 
recommended_action: flag. Because the configured action is flag (not 
remove/bounce/shadow_block), the comment was still delivered to readers and 
just filed for review - that's the trade-off the Phase 4 config deliberately 
chose.
2. A user-level item for jo - the aggregate record that tracks the flagged 
user (flagged_count: 1), auto-resolved with recommended_action: keep.

This is working as configured. Flag means the content gets delivered and a human gets a case to review.

Where Agent Skills Excelled, And What Needs Work

The core promises held. Every cold prompt routed to the right track, the agent asked for input exactly once all afternoon, and the guardrails did their job: it wrote credentials without ever reading them, stayed out of the files its rules forbid, and checked the schema before every CLI write. The standout was the verification habit. Both real bugs of this build sailed past type checks, builds, and the console, but the Playwright screenshots caught them.

A simple build like this doesn’t give you all the information, but it left me with four things:

• Managing Stream directly through the CLI is a great feature, and it was great for this build. Everything the Dashboard can do, an agent can now do, which is why moderation needed zero app code and why so much of this can be automated.
• Agent skills work excellently with a good model. Not perfectly, but the model starts with about 95% of the information it needs already on disk and can easily find the rest through the references. It never had to guess.
• The skills encode Stream’s defaults, and on those defaults the build is trivial. Both times the model had to change happened exactly where AstroFeed strayed from them, so the more specific your app, the more of that you should budget for.
• I built linearly on purpose so I could watch the router work. Real projects will run agents in parallel under an orchestrator or a loop, and that’s where skills matter most: they keep every model tied to the same current references and the same rules instead of improvising from memory.

If you want to try this yourself, Agent Skills are free on GitHub and work with any Stream account, including a free trial. Install them with getstream skills — claude, point Claude Code at your own app idea, and see how far one prompt gets you. And if you want to see exactly how this build went, prompt by prompt, the full log is in the AstroFeed repo.

Building An Astronomy App with Agent Skills was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Live moderation splits into two paths: a fast, shallow check that blocks content before it ships, and a slower, deeper check that corrects the decision after the fact.
• Your delivery protocol sets the size of that window before any model runs. WebRTC’s sub-second delivery leaves almost no time to block; LL-HLS’s few seconds of delay leaves room to work with.
• Keep the blocking path inside its window by scoring fewer frames, compressing the model, and running it at the edge; give the correcting path the time and context (multimodal fusion, human review) the blocking path doesn’t have.
• Track precision, recall, and F1 by category instead of one accuracy number, and keep an immutable decision log.

A creator goes live on your platform. It’s a shopping stream with thousands of viewers and chat running fast.

Twenty minutes in, something crosses a line. A counterfeit item on camera… a slur in the chat… a claim the policy doesn’t allow.

Viewers have already watched it happen by the time anyone notices, and it’s your platform’s rules on the line, not just the creator’s.

That’s what makes live stream moderation different from every other content type. There’s no queue to hold a violation in, and no way to recall what’s already gone out.

This piece covers the architecture for it: a fast, shallow path that beats your delivery window and blocks content outright; a slower, deeper path that corrects the call after the fact; and the protocols, models, and queues that make both work.

What You Must Decide: Whether To Block Now or Correct After

The core idea is to sort every check you run by its deadline rather than by what it looks at.

That means you’re not building one moderation pipeline for chat, another for video, and another for audio. Instead, you ask a timeline question about every check: how long do I have before a viewer sees this, and can the check answer inside that time?

The time you have is the gap between content reaching your servers and a player showing it, and your protocols and product decisions set this number: a few seconds of segment delay on LL-HLS, or just a few hundred milliseconds on WebRTC, plus whatever small hold you can add without viewers feeling it.

• A check that beats the window can block the content. Its verdict arrives while the content is still only on your side, so acting on it means the chat message never appears or the video segment never gets published. Nothing was seen, so there’s nothing to undo.
• A check that misses the window has to act after viewers have watched the content. This means you’re correcting the decision, not the violation. Whatever was seen was seen, and no correction resets someone’s eyeballs.

So you effectively end up with two streams of moderation, one fast and shallow, the other slow and deep. The same live video gets both treatments at once: a small image model scores sampled frames quickly enough to hold a segment back, while a temporal model that needs a few seconds of clip runs behind it and flags more subtle problems.

Chat works the same way, with a lightweight classifier gating each message and a slower context check reconsidering it.

So the design work splits into three pieces:

1. The window, which your protocols fix before any classifier runs.
2. The blocking path, everything that has to beat the window.
3. The correcting path, everything allowed to miss it as long as it can still act.

The window comes first because you inherit it rather than choose it.

The Window Your Protocols Set

Protocols are what define livestreams, and they matter to moderation in different ways:

• Delivery protocols, server-to-player, set the window itself. This is where the time in the timeline question comes from.
• Ingest protocols, encoder-to-server, decide what condition the stream arrives in. They don’t change the window, but a stream that stalls on the way in leaves nothing for either path to work with.

Most of the latency spread comes down to TCP versus UDP. RTMP runs over TCP, so one lost packet holds up everything queued behind it until retransmission. That’s head-of-line blocking, and on a congested stream it turns into stalls and jitter. The UDP protocols skip the missing packet and move on, since a frame that shows up late isn’t worth waiting for in a live stream.

Here’s a breakdown of low-latency streaming and the different tradeoffs:

On the ingest side, RTMP is still the default because nearly every encoder speaks it. On the delivery side, the choice decides how much room the blocking path gets:

• LL-HLS: seconds of delay, cheap scale, real working room. Segments ride the same CDN caches as static content, so big passive audiences stay affordable, and players run a few seconds behind your encoder.
• WebRTC: sub-second delivery, per-viewer cost, almost no window. Every viewer holds a session with a selective forwarding unit (SFU), and a frame is on screens before most checks return.

In practice, most platforms mix them: WebRTC for the hosts and guests on stage, and LL-HLS via a CDN for everyone watching.

But we can see immediately how these decisions matter for moderation. With LL-HLS, a violation caught now stops the next segment from ever being published, or ends the stream before any player requests it, holding the violation’s airtime to seconds.

But if you deliver entirely through WebRTC, your options are limited, as blocking mostly means acting on the frames that follow. Sub-second delivery is a real feature; you just pay for part of it out of the moderation budget.

One Stream In, Two Paths Out

At ingest, you fork the stream. One copy goes straight to transcode and delivery. The other feeds moderation, and nothing that happens to it can slow the first copy down.

On the moderation copy, the two paths map onto straightforward engineering:

• The blocking path runs synchronously, inline with the content. A verdict comes back before the message posts or the segment ships.
• The correcting path runs asynchronously, behind a queue. Verdicts come back as webhooks, on their own time.

What Runs Inline

A semantic filter scoring each chat message before it posts, a small image model scoring sampled frames before the next segment ships. There’s deliberately little infrastructure here, because every extra hop spends window time.

The inline check doesn’t have to live on your servers either. You can put it on the device: a light model screens every frame locally, and only suspicious 2–6 second clips, keyframes, or compact embeddings get uploaded for a deeper look. The blocking path sits next to the content, and the correcting path picks up at the upload.

What Runs Behind the Queue

Ingestion publishes frames and chat events to a bus like Kafka, rules and heavy models consume them from a stateful processor like Flink, and decisions flow back to enforcement on their own schedule. A model that takes ten seconds, or a review backlog forty items deep, delays a correction and touches nothing else.

The consumers can be a whole pipeline of their own. In AWS’s generative-AI moderation pattern, a segment landing in S3 starts a Step Functions state machine that fans out: Transcribe on the audio, Rekognition on sampled frames for labels and moderation flags, a Claude model for frame summaries, and Titan embeddings. Everything collects in OpenSearch, where a Bedrock LLM reads the metadata against the policy prompt.

The worry with acting after the fact is how long after. The Amazon IVS variant gives real numbers: under 500 ms for the Rekognition call on frames below 1 MB, about two seconds from frame to notification through the rules engine, and the stream stops automatically when a rule fires. A correction that lands in two seconds means the violation aired for two seconds, not the rest of the hour.

In short: cheap checks sit next to the content, expensive checks sit behind a queue, and enforcement flows back into delivery.

The Blocking Path: Beating the Window

Everything on this path answers the same timeline question: Can this check return a verdict before the window closes?

The work splits into four pieces, in order:

1. Find where the time actually goes.
2. Score fewer frames.
3. Make the model fit the budget.
4. Move the whole thing next to the stream.

Find Where the Time Actually Goes

A software profiler measures the model, not the pipeline. It can report a 5 ms model while the full pipeline runs 50 ms behind. The number to watch is glass-to-glass: how long from a photon hitting the camera sensor to a processed result coming out the other end.

Much of that time is spent before inference runs. Sensor exposure takes 1–33 ms depending on light, a rolling shutter reads rows out one at a time, and an encoder with B-frames enabled buffers several frames before it can emit anything. By the time the blocking path sees a frame, part of the budget is gone.

Instrument every stage and fix the biggest contributors first. They’re often decode, transport, and buffering rather than the model.

Score Fewer Frames

Most violations persist across many consecutive frames; a nudity or weapon detection doesn’t appear and vanish inside 33 ms. AWS samples at two frames per second and describes that as typical.

On top of sampling, drop the frames that carry nothing new:

• Embedding similarity. AWS’s generative-AI pattern embeds each sampled frame, runs a cosine similarity check against the previous one, and discards any frame too close to its predecessor.
• Image hashing. Amazon IVS skips a frame if its hash is near the previous frame’s for the same channel.

Sampling plus deduplication can cut inference volume by an order of magnitude. The saving applies to both paths, since the correcting path’s heavy models see the same reduced stream.

Make the Model Fit the Budget

Once the model is the bottleneck, the goal is fewer operations per frame. Three compression techniques:

• INT8 quantization maps weights and activations from 32-bit floats to 8-bit integers. The model shrinks roughly 4x, and Tensor Cores run the integer math 2–4x faster than FP32. It costs some accuracy, so teams train with quantization awareness and keep the sensitive first and last layers in FP16.
• Structured pruning removes whole filters, channels, or attention heads. Zeroing individual weights produces sparse matrices that standard GPUs can’t accelerate; removing entire filters preserves the dense matrix operations the hardware runs fast.
• Temporal shift modules give a 2D model temporal reasoning without 3D convolutions. They shift a fraction of the feature-map channels along the time axis before a normal 2D convolution, so the model reasons about motion at close to 2D speed.

Past the model, several pipeline settings reduce buffering:

When a downstream stage falls behind, a leaky queue drops the oldest frames instead of building a backlog. A verdict on a frame from two seconds ago arrives too late to act on. SRT makes the same tradeoff at the transport layer when it drops stale packets.

Run It Next to the Stream

Pure cloud makes sense when the model is too big to quantize for edge hardware and the application can tolerate more than 300 ms of round-trip latency. Running at the edge keeps raw frames on the device, which helps privacy, and ships events or short clips instead of full video, which cuts egress cost.

In practice, almost every production system lands on the same hybrid: a quantized detector at the edge screens everything, and ambiguous frames escalate to a heavier model in the cloud. That’s the blocking and correcting split expressed in hardware: the edge model does the blocking, and the cloud model does the correcting.

Cold starts are the operational detail to plan for. TensorRT engine builds and model loads can take 30 to 300 seconds, so pre-warm with a synthetic inference at startup and pin model files to NVMe. Otherwise, the first stream after a deploy goes unmoderated.

The Correcting Path: Getting the Call Right

Everything here has already missed the window, so a verdict can take seconds or minutes instead of milliseconds. That time goes to bigger models, more context, and human judgment.

The work splits into two pieces:

1. Score the modalities together, with context the inline checks don’t have.
2. Route the judgment calls to humans, without putting one in the request path.

Score the Modalities Together

Blocking-path checks look at one track at a time, because that’s what fits inside the window. Each classifier answers a narrow question: what’s visible in this frame, what was said in the last few seconds of audio, what’s in this chat message.

Per-track checks miss harm that only exists in the combination. A chat message that’s innocuous on its own but aimed at the person on screen passes the text check, because the text check can’t see the screen. A pitch that calls an item authentic passes the audio check, footage of the item passes the frame check, but together they count as a counterfeit sale. Each classifier answered its own question correctly, and the violation went through.

Scoring the tracks jointly closes that gap, and multimodal ML has three standard ways to combine them:

• Early fusion concatenates feature vectors straight after the encoders. It catches low-level cross-modal signals but needs expensive joint training.
• Late fusion combines each modality’s final scores with learned weights. Modular and easy to maintain, but the interaction between modalities is lost.
• Hybrid fusion does both, running cross-modal attention over raw features while correlating the intermediate scores. It captures the most context and is the most work to build and run.

The joint score still needs context from outside the content. The same phrase can be fine in one channel and a violation in another. This is context collapse. A semantic embedding check runs in 10–50 ms, but the final call needs user history, channel type, and conversation flow. Aggregating those signals server-side cuts false positives and makes the system harder to game.

Route the Judgment Calls to Humans

Satire, political speech, and harassment phrased politely end up in front of a person. Review time is unpredictable, so a human inside a synchronous pipeline backs the queue up behind them. Redis’s write-up on oversight patterns lays out the three ways to wire people in:

• Human-in-the-loop gates on explicit approval. The latency is unbounded, so it can’t sit on a live path.
• Human-on-the-loop lets the system act in real time while people monitor with veto power. Live moderation runs this way, and the cost is a short exposure window before an override lands.
• Human-out-of-the-loop runs autonomously inside policy bounds, with people involved only at design and evaluation time.

Escalation routes on confidence. The same write-up pairs a trust score for model agreement and classification confidence with a risk score that flags severity regardless of confidence. High trust triggers automated action. Low trust or moderate risk goes to review.

You can’t predict when a reviewer will get to an item, so the system saves the whole event before it escalates: the flagged clip, the transcript, the model scores, and the conversation around it. The reviewer opens the case with everything already in front of them.

Redis Streams works as that queue. Escalations sit as persistent logs you can query later, and a sorted set ranks them by urgency, scored on viewer count, creator tier, and severity. Whatever’s most urgent gets seen first.

When the reviewer makes the call, the item flips from pending to approved or rejected. That status change triggers enforcement asynchronously, and the decision becomes a labeled example for active learning, so the models learn the edge cases and send fewer of them to review over time.

Stream Moderation is built around the same loop. Flagged content lands in a review queue sorted by severity; each severity level can have its own action, and webhooks fire whether the flag came from a model, a blocklist, or a person. The Check API takes text, images, video, or a user profile, so chat and video share one queue and one enforcement layer.

Measuring Both Paths

Plain accuracy will flatter the system because moderation data is heavily imbalanced. Almost everything is fine, so a model can post a high accuracy number while missing most of the abuse.

Moderation metrics are what to track instead:

Split all three by category, because a system strong on spam can be weak on bullying, and by language and region, because models are best in the languages they were trained on. Operationally, track system latency, throughput at peak, review time per item, reviewer agreement rate, and escalation rate. A rising rate of escalation usually indicates ambiguous policy rather than a weak model.

The Audit Trail Is a Legal Requirement Now

Under the EU’s Digital Services Act, a live platform owes users a notice-and-action mechanism, prompt removal of illegal content once notified, and a statement of reasons for every removal. Annual transparency reports have to describe the automated systems in use and disclose their accuracy and error rates.

The penalties are serious money. The Commission can impose a fine of up to 6% of global annual turnover for serious infringements, plus periodic penalties of up to 5% of average daily worldwide turnover for each day of delay in compliance. Enforcement started in December 2025 with the first DSA non-compliance fine, €120 million against X, for transparency failures rather than slow removal, and well below the cap, but the framework is clearly live.

The useful part is that compliance mostly asks for things this architecture already produces: a sub-second automated path for clearly illegal content, which is the blocking path, and an immutable log of every automated and human decision. The event log the correcting path keeps for review queues and active learning is the same artifact a regulator asks for.

The Whole System, Job by Job

Everything in this article comes down to three jobs: pick your window, make sure the inline checks beat it, and give the deeper checks a way to act once they’re done.

• Pick your window deliberately. Ingest over SRT so a creator’s bad hotel wifi doesn’t stall the stream, deliver LL-HLS through a CDN to viewers, and save WebRTC for the hosts and guests who actually need it. Every bit of delivery latency you cut is time your inline checks lose, so sub-second delivery is a cost you should choose on purpose.
• Make sure the inline checks beat it. Sample around two frames per second, throw away near-duplicate frames with embedding similarity or hashing, and run a quantized model at the edge with zero-copy buffers and leaky queues. Warm it up before traffic hits, otherwise the first stream after a deploy goes out unmoderated.
• Give the deep checks time and a way back in. Put them behind Kafka so nothing slow touches delivery, run the fused multimodal scoring and LLM policy checks on their own schedule, and act through webhooks. Anything the models aren’t sure about goes to a review queue in Redis Streams, ranked by urgency, and every human decision goes back into training.
• Watch both sides and write everything down. Track precision and recall by category and language instead of one headline accuracy number, keep an eye on review time and escalation rate, and log every decision somewhere immutable. That log is also what the DSA asks you to produce.

Where Stream Fits

The whole design keeps coming back to the same question: Does this check beat the window or miss it?

Beat it, and you can block. Miss it, and you’re correcting the decision, so the check needs a way to act on the stream, the replay, and the account.

Stream covers a lot of these pieces on shared infrastructure: chat, feeds, and video with AI moderation built in, a Check API that takes text, images, video, or user profiles, review queues ranked by severity with webhooks, and the open-source Vision Agents SDK for running models at the edge. It doesn’t make the tradeoffs go away, but you end up tuning a pipeline instead of building one.

If you want to try it, the moderation docs cover setup for chat and video. Wiring the Check API into chat is the smallest version of the blocking path, and a sensible place to start before the video pipeline.

Architecting Real-Time Moderation for Live Video was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

Picture this scenario:

A patient calls a pharmacy line and says: “Hi, I need to refill my mom’s Augmentin, the 875.”

A voice agent takes care of this request. It listens, pulls out the structured details, asks one clarifying question, accepts the request, and sends the medication out.

That setup is both technically impressive and incredibly dangerous. Automation is one of the big promises we’re getting from the agentic era of AI. However, blindly implementing a use case without questioning its implications can pose great dangers.

That’s why we built a demo to see what it actually takes to run a voice agent in a domain where being wrong has consequences.

Let’s break it down.

What’s at Stake?

A few examples where the exact path we laid out can go wrong:

• Auto-accepting prescription requests can lead to incorrect deliveries that might have serious health implications for patients.
• A fully-automated process can miss important details and context with medication.
• Small transcription errors can lead to major problems if the wrong medication is prescribed and delivered for a specific treatment.

And, these errors are increasingly more likely with modern technology. The sheer wiring up of a voice agent is now a straightforward task. You…

• capture audio,
• run speech-to-text,
• send the transcript to an LLM,
• speak the response back.

This is where most tutorials stop.

As with many other things, the devil lies in the details. The steps laid out are not wrong, but without further thinking and guardrails, this is not enough. That’s why we’re laying out five decisions that allowed us to build a trustworthy agent.

(Note: We’re applying these lessons to the medical space, but they’re also applicable to any voice agent where mistakes have serious implications.)

The Stack

• Stream’s Vision Agents SDK to handle the real-time call and agent orchestration
• AssemblyAI for speech-to-text
• LLM (Gemini 3.5 Flash, in this build) for the reasoning
• TTS model from Inworld to give our agent a voice

Lesson 1: Design the Flow Around the Stakes

The version that looks great in a demo is where the agent closes the loop itself: caller asks, agent confirms, “Great, your refill is approved and on the way.”

It’s satisfying to watch. It’s also the wrong design for anything with real consequences.

We made the agent an intake assistant, not an approver. Its job starts when the call connects and ends at “prepared for pharmacist review.” A human is always in the loop before anything happens. The agent’s own instructions spell out what it’s not allowed to do:

You are not a doctor, pharmacist, or prescriber.
You must not provide medical advice.
You must not approve, prescribe, dispense, recommend, or modify medication.
You must not say that an order is complete or approved.

But instructions alone are a soft boundary, and anyone with a bit of experience can argue an LLM out of them. So the boundary needs to also be enforced structurally. The agent cannot declare the intake finished on its own by design. In our case that means that it has to call a prepare_pharmacist_handoff tool, and that tool refuses to return a "ready" state until every required field is present:

REQUIRED_FIELDS = (
    "patient_name", "request_type", "medication", "strength",
    "instructions", "quantity", "prescriber", "delivery_preference",
)

The frontend has a “Send to pharmacist” button which is only active when the exact same conditions are met, so the UI and the agent agree on what “done” means.

The general takeaway here is that for any high-consequence workflow, the first design question is not: what can the agent do? Instead, it’s: where does the agent stop?

Define the handoff boundary before you write the prompt, and encode it somewhere deterministic that imposes a hard limit that the model can’t bypass.

Lesson 2: Pick the Right Tool for the Job

Speech-to-text providers look interchangeable until you point them at your actual vocabulary. On a generic benchmark, they cluster together. Then your agent hears “atorvastatin” as “a tour of a statin”. That leads to an issue where everything that follows (extraction, validation, the handoff packet) is built on a wrong transcript. In this domain, garbage in — garbage out means a major safety issue.

The number that mattered to us was the word error rate on the words that carry the risk: drug names, strengths, and units. That’s exactly where general-purpose models tend to slip, because those terms are rare in ordinary training data and easy to confuse with common words.

We used AssemblyAI because it held up well on dense pharmaceutical terminology, which is where it separated from more general STT for this use case. Because the Vision Agents SDK abstracts the call transport, the STT provider is a pluggable component.

This allowed us to evaluate and change different options with a one-liner:

stt = assemblyai.STT(
    api_key=settings.assemblyai_api_key,
    speech_model="universal-3-5-pro",
    keyterms_prompt=ASSEMBLYAI_KEYTERMS,  # more on this in Lesson 3
)

The broader lesson here is that the metric for choosing the best model should not be an arbitrary leaderboard on the web.

Instead, we should first declare “for what” we’re using the model and evaluate its quality only on that specific use case. We’re not building a product that needs to work in any setting, so we shouldn’t choose a model that tries to be applicable for all scenarios.

Lesson 3: Give the Agent a World Model

With the right selection of an STT provider and a capable LLM, they still don’t know our domain out of the box. The recognizer doesn’t know “amox clav” is a thing a caller might say; the model doesn’t know which strengths of levothyroxine are plausible. We have to supply that knowledge, and it turned out to matter at two different layers.

1. At the ear (recognition). AssemblyAI accepts a keyterms_prompt, which is a list of terms to bias recognition toward. We fill it with the vocabulary this agent actually encounters: medication names, brand/generic pairs, the prescriber's name, even the agent's own name. Here is a simplified list of key terms we feed to the model:

ASSEMBLYAI_KEYTERMS = [
    "atorvastatin", "Lipitor", "amoxicillin clavulanate", "amoxicillin-clavulanate", "Augmentin",
    "levothyroxine", "Synthroid", "pharmacist review",
]

This is where Lesson 2 and Lesson 3 meet: picking a strong recognizer is step one, but you get a further accuracy jump by telling it which uncommon words to expect. We can already see here that building a product means connecting multiple approaches.

2. At the brain (reasoning). The agent has a medication reference that it can use to look things up in a database. These can be canonical names, aliases, common strengths, and a per-drug review flag. Here is an example for a medication:

{
  "name": "Amoxicillin-clavulanate",
  "aliases": ["amoxicillin clavulanate", "Augmentin", "amox clav"],
  "commonStrengths": ["500 mg / 125 mg", "875 mg / 125 mg"],
  "type": "antibiotic",
  "requiresPharmacistReview": true
}

So when a caller says “amox clav,” the agent normalizes it to the canonical “Amoxicillin-clavulanate” rather than guessing, and it knows “the 875” maps to a real strength.

We can summarize that an LLM is a reasoning engine, not a knowledge base. Don’t assume it memorized your catalog, your SKUs, or your entity names. It’s our job to give it a source of truth to consult. This will then enrich both the layer that hears and the layer that thinks.

Lesson 4: Don’t Make the LLM Do Everything

It’s tempting to hand the LLM the whole job, including extraction, validation, flow control, and tone. A cleaner split is to let the model do the fuzzy work and let plain code do the mechanical work.

The deterministic side handles anything that’s verifiable and boring. Normalizing units and frequencies, for example. This can be a simple lookup and does not need to be a judgment call:

STRENGTH_ALIASES = {
    "20 milligrams": "20 mg",
    "875 125": "875 mg / 125 mg",
}
FREQUENCY_ALIASES = {
    "every night": "Once nightly",
    "twice a day": "Twice daily",
    "every 12 hours": "Every 12 hours",
}

Completeness is enforced in code, too. Instead of trusting the model to remember every field it still needs, a function checks the intake state against the required list and reports what’s missing.

This is the exact condition that gates the handoff we described in Lesson 1:

def missing_required_fields(state) -> list[str]:
    return [f for f in REQUIRED_FIELDS if not getattr(state, f, None)]

Meanwhile, the LLM does what it’s genuinely good at: interpreting what the caller meant, deciding which clarifying question is worth asking, and keeping replies short and warm. Its instructions push it toward that role through formulations like this:

• Ask at most one clarification question at a time
• Keep spoken replies short, usually one sentence

The principle is a division of labor by reliability.

If a rule can be checked with a for loop, check it with a for loop; you don’t want correctness riding on a probabilistic system when a deterministic one is exact. Save the model for the calls that actually require judgment.

Lesson 5: Guardrails Are Not Simply a Line in the Prompt

“Be safe and don’t give medical advice” in a system prompt is both necessary and, at the same time, nowhere near enough.

Prompts can be worked around. On the other hand, if we add deterministic logic checks to each phase of the flow, we can assure that our safeguards can’t be breached.

Our demo has three cooperating layers.

1. A deterministic safety net. Before the LLM’s judgment enters into it, transcript text is scanned for high-risk language. Emergency terms trigger a hard stop; dosage-change requests and medical-advice questions get forced into pharmacist review regardless of what the model would have done.

EMERGENCY_TERMS = ["chest pain", "can't breathe", "overdose",
                   "allergic reaction", "suicidal", ...]

def run_safety_checks_on_text(text):
    if _contains_any(text, EMERGENCY_TERMS):
        return SafetyResult(status="blocked", blocked=True,
                            response=EMERGENCY_RESPONSE)=

If a caller says “chest pain,” the agent breaks out of the intake flow and points them to urgent care. That behavior does not depend on the LLM deciding to be careful.

2. Instruction guardrails. The behavioral rules from Lesson 1 (never approve, never diagnose) always frame the outcome as “prepared for pharmacist review.” These shape the model’s default behavior.

3. Structural gates. The prepare_pharmacist_handoff tool makes the unsafe end-state ("the agent said it's done") unreachable until the required data exists. There's also a standing "pharmacist review required" check applied to every request, plus extra checks when a caregiver is calling on someone's behalf or a second medication comes up.

The idea is defense in depth. Assume any single layer can fail, and arrange things so the next layer catches it. For any agent that touches health, money, legal, or identity, the guardrails need to hold even when the model behaves in a way you didn’t anticipate.

Conclusion

We see one theme across all five lessons. A trustworthy voice agent is a systems problem, not a prompt problem (alone).

The LLM is one component among several. Most of the value is in how you surround it. That means the right transport, an STT model that holds up on your vocabulary, real domain knowledge fed to both the recognizer and the reasoner, deterministic checks for anything verifiable, and guardrails that reliably catch when the model is misbehaving.

This tooling lets us spend our effort in the right place. Stream’s Vision Agents SDK made the real-time call, orchestration, and provider swapping cheap, so the work went into the domain decisions above rather than plumbing. AssemblyAI made the speech layer accurate enough on medical terms to build the rest on top of.

The end result is a demo that deliberately is a limited one.

No real fulfillment, no medical advice, a human pharmacist at the end of every request.

But the pattern generalizes well beyond pharmacy, with real-time voice, a high-stakes domain, and a human kept firmly in the loop. If you’re building in that shape, the five lessons here are a reasonable place to start.

5 Lessons from Building a Voice AI Prescription Agent was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

The humble programming tutorial has recently been thoroughly transformed from copy-paste toil to one-click wonder. Cinderella’s fairy grandmother waved her magic wand and turned a pumpkin and mice into a fabulous carriage pulled by white horses; today’s AI coding agents have an almost as magical-seeming ability to turn the barest of specs into a full-fledged application.

Stream’s CLI tool is the magic wand for building realtime apps on web and mobile. It offers a powerful AI skill that knows how to generate and update complete applications that use Stream’s API. It works so well that almost any classic Getting Started tutorial has effectively become a single line, like this:

/stream make me a video call web app with chat

The agent will go ahead and plan for the project, ask you to log in on Stream, create the app in your account, set it up with sensible defaults, and build a whole React single-page app for the example given above.

For better or worse, if you just ask for “web app”, the default on all LLMs is React because it’s so prevalent in AI training material. If you want some other framework, you need to ask for it by name. Of course Stream agents also know how to write iOS, Android, Flutter…

It’s impressive to watch it work. But when you move past tutorials and experiments into real apps, you eventually run into problems. A one-sentence prompt simply can’t describe your real world problem well enough to be a fully solid base for an app. Where the specification is lacking, the magic wand of AI will just go ahead and guess on the fly. Some of these guesses inevitably become bugs, or at least undesirable behavior that’s already been baked into code and then you have to make an extra effort to get rid of it.

So when it comes to one-shot app generation, it needs to be well-grounded. By spending a bit more time upfront planning your design, you’ll be saving a lot more time down the road by avoiding the slow iterations needed to fix AI’s initial misassumptions.

Building a complete live shopping app

In this post I’ll show you the design process used to create a one-shot application called VinylStream, a live shopping app that lets people buy and sell vinyl records online. Sellers can schedule live shows where they show their record finds on camera, and viewers can bid on live auctions and ask questions on Stream chat.

• Try it live: vinylstream-live-shopping-react-demo.vercel.app
• View the full source code: GetStream/vinylstream-live-shopping-react-demo
• Read the design document: vinylstream-concept.md

The exact steps are described in the companion tutorial, but it’s so simple that you barely need to read it. I just created a new folder for the project, copied the design doc under docs, added the Stream skill using the getstream CLI, opened Claude Code, and entered this prompt:

/stream Build me the app described in docs/vinylstream-concept.md

I’ve tested this one-shot creation on several models including Claude Opus 4.8, Fable 5, and Sonnet 5. There wasn’t a significant difference in the output. Opus was the most token-efficient at around 90k tokens, but the other models were not far off. This is really a testament to how the Stream agent skill provides the essential intelligence for building the app — you don’t need the fanciest LLM because so much knowledge is encoded already in the skill, you just need baseline smarts and enough context window (Sonnet 5 at 1M context clears the bar handsomely).

Although this is a video-centric app, the lessons of this process are general. You can apply them to any realtime-oriented app you’d build with an AI agent. Stream’s agent skill has a lot of built-in intelligence that routes based on target platform and use case, but it’s always worth getting the basics right in your design phase. It will save you tokens and frustration.

In effect, the design document is the real source code. You still need to tell the computer what to do — that part of programming isn’t going away. With AI and agent skills you can do it on a much higher level than thinking in terms of if sentences and API calls. So take a moment to get it right.

Something important to note about the VinylStream design document is that it was made for a demo and intentionally leaves some questions open so it can better function as an app skeleton. When you’re bootstrapping a finished application, decisions can be settled already at the design stage. I’ll highlight these differences when appropriate, so you’ll know what transfers from VinylStream and what you can fix already.

1. Name the core pattern

Don’t jump to discussing your specific vertical too early. If you tell the agent to build a “vinyl app” or “telehealth app”, it will jump to optimizing surface features like buttons and screens rather than the mechanism that makes the app work. You get a demo that looks convincing, but feels wrong as soon as you try to do something in it.

For VinylStream, the core pattern is “binding canonical product data to a live video stream”. That’s the heart of any live shopping app, whatever is being sold.

Superficial mechanics can be misleading. If you think of live shopping as “QVC-style TV home shopping channel in a browser”, you might assume the core pattern is “a video stream with a chat and a buy button”. That would work for a single person experience, but the internet is not television — a live shopping app is both multiplayer (there are other people bidding) and uses multiple data sources (potentially thousands of sellers each making their own TV show). Your app needs to be aware of which item is live right now, where the price comes from, and who’s winning. Stream’s infrastructure and APIs will make sure the video and chat work, but to close the sale, you need to own the product experience.

Consider telehealth. It looks like “a video call with a doctor”, but the call is the easy part. The core pattern is conducting a properly documented and consented clinical encounter tied to a verified patient and their record. Video is just one channel for what the doctor needs to know. If that’s your business, Stream will let you handle the boring but complicated video part reliably, and you can focus on delivering results to patients and doctors. But you need to focus your AI coding agent’s attention on that.

2. Map your realtime planes and the source of truth

Most realtime apps — well, the ones that do something useful or fun, anyway! — are not just one stream, but several planes running at once. For live shopping, there’s video, chat, and shared application state like bids, auction status, etc.

When preparing your design document, list these planes. Then, for each piece of shared state, write one sentence: where does the source of truth live?

Traditional database-backed “CRUD apps” are fairly uniform in how data is treated. (Whether your entity is big or small, a CRUD app will expose the same essential API patterns.) For realtime, it’s easy to apply that same thinking and assume that everything that moves in realtime is the same kind of thing. Video frames, chat messages, and an auction’s current price all “update live,” but they have completely different correctness requirements. If you let the coding agent blur these lines, it will often do whatever it finds most convenient in the moment when developing the solution because it’s eager to move ahead. That could mean trusting a bid price which happened to arrive over the chat channel, or something worse. (Reading a product price from a video overlay? Why not? The data is right there…)

For VinylStream, the auction’s current price, high bidder, and countdown are authoritative on the server. Bid events can ride the same realtime channels as chat — it’s a fine transport for this purpose — but the ultimate truth lives server-side, never in a transient source like the seller’s client or the chat stream. Video and chat are views of the auction, not the source of truth.

3. Find your integration seams

List the major parts of your app one at a time: video, chat, the product catalog, payments, shipping, notifications… Then mark each one with one of these labels: is it real, mocked, or shaped?

Real is what you build now. Mocked is a throwaway stand-in. Shaped is the interesting one, an in-between state where you expect things to evolve. You don’t build it yet, but you design the data model to make it easy to drop in the real thing later.

AI agents will happily do “vibe mocking” where they fill in the gaps with whatever shape is easiest in the moment. Replacing those can be a complex rewrite. Providing the right shape early avoids those detours.

For VinylStream, shipping is an example of a feature that’s the last one real sellers and buyers would encounter, so it would be easy to brush it aside as irrelevant. But a moment spent thinking and researching about the shape will help the agent focus. A state like “label printed, in transit” stands in for any real fulfillment. The data model underneath can already be shaped for the real thing, so each order carries a shipment with a destination address, a tracking reference, and a status that moves from pending to shipped to delivered.

For a demo, you wouldn’t care if everything outside of the core pattern is mocked. But for a real app, the shape becomes important. Instead of “what can I fake?”, you should be asking: “What are my seams to the outside world, and do I know their shape already?”

4. Decide your external dependencies

In the previous section you drew the boundaries. Now look at that other side which is out of your control: things like third-party APIs, keys, rate limits, licensing, network quality… And make decisions about each.

If decisions are not laid out explicitly in your design, an agent may guess in ways that become expensive (or at least annoying) to undo: it wires up whatever API call looks “obvious” with no key management, has no fallback for when the service is down, and so on.

For VinylStream, there was a big external dependency: the catalog that provides the vinyl records. Thanks to the tireless efforts of vinyl fans, there exists a free site called Discogs which provides exactly the canonical database we need. We don’t want to abuse their API or their terms, so the catalog for this demo was built from the Discogs monthly data dump — a full XML export under a CC0 public domain license — rather than by hitting the Discogs API for each request. It makes the demo run smoothly because the data is always available.

This is the section where a real app would diverge most sharply from the VinylStream demo, so be careful when copying from it. For a demo, you want to eliminate external dependencies to make sure it works everywhere. A real app on the other hand wants the opposite: it needs to solve problems like getting the fresh record inventory and dealing with practical issues like Discogs’ API terms (if you build a product on someone else’s data, it’s highly advisable to get legal advice early on). The exercise is the same — enumerate your dependencies — but the answers tend to run in the opposite direction. So be careful about copying a demo’s decisions into a real product.

5. Trace your critical user paths

Language models know an awful lot of things that they’ve read on the internet, but so far nothing beats human intuition about how things should actually work. You should tell the model explicitly what happens inside the app, rather than trust that it can play human long enough to figure it out.

So write the shortest end-to-end user paths that exercise the core pattern. One sentence per role is enough. Then write down what’s explicitly left out.

For VinylStream, the seller side is: create a show -> add about five items via Discogs search -> go live with the item queue.

The buyer side is: join the stream -> see the current item card -> bid -> win -> cart. Explicitly out: real payments, shipping, notifications.

For a demo or throwaway prototype, those “out” features never get built, they’re just design placeholders that feed the audience’s imagination. In a real app, “out” instead means “deferred to phase 2”. So the critical path doesn’t change, but how you track the missing features is different. You can ask your AI agent to maintain another design document for what you need to build beyond the one-shot.

The design document is the real source code

AI hasn’t taken away the essence of programming, and probably won’t: deciding what the thing should actually do. A language model is great at typing API boilerplate, and it can also role-play all kinds of scenarios, but ultimately only you know why you’re building something and why someone might want it. Everything discussed in this blog post is about getting you faster to the point where that motivation can be expressed and validated in working application code.

The one-shot magic wand really does work. But if you point it at a vague wish, you get a vague result. (Or, to continue with my Disney analogies, worst case is that you end up like Mickey Mouse in “Sorcerer’s Apprentice” and your agents are running amok doing things on their own, completely oblivious to your wishes because you didn’t express them clearly enough…)

And notice how little of the thinking involved here was about video or chat specifically, even though we built a live shopping app whose hardest technical bits are those realtime components? That’s the whole point. Stream’s APIs and skills makes the realtime plumbing reliable and auto-scalable and boring, so you can focus on doing the product work that only you can do. So why not start building today? You could have something real up and running in less than an hour, armed with any old LLM and the Stream agent skill.

Building a Live Shopping App with One-Shot AI was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

Online communities rely on moderation to function, yet every moderation decision carries significant ethical implications.

The platforms that choose to remove, allow, promote, or downrank content directly shape culture, discourse, and safety. As AI systems take on more moderation responsibilities and regulatory scrutiny increases, the stakes continue to rise. Ethical moderation is no longer only a product concern. It is a societal concern.

This guide explains the ethical challenges behind content moderation, why fairness matters, the tensions between safety and expression, and the best practices that can help teams build trustworthy and transparent systems.

Introducing the Ethics Problem

Content moderation determines what billions of people see, share, and experience online.

When models or human reviewers make mistakes, those errors can perpetuate inequities, silence marginalized communities, or facilitate the spread of harmful content. Ethical concerns arise not only from the decisions made, but also from how those decisions are made and who they impact.

Bias is a central part of this challenge. Bias appears in data, tools, guidelines, and human judgment. It can be subtle and unintentional, yet it can still create meaningful harm. Ethical frameworks help teams ensure their moderation systems are safe, fair, and accountable.

Why Ethical Moderation Matters

Fair and transparent moderation is crucial because these decisions significantly impact public discourse and user trust. If communities feel targeted or unfairly censored, participation drops. When harmful content slips through, safety collapses.

Both outcomes create real consequences for individuals and for the broader information ecosystem.

At the same time, global regulations like the Digital Services Act and emerging Online Safety Acts put additional pressure on platforms to demonstrate due diligence. Teams must show that their models are trained responsibly, that oversight is consistent, and decisions can be explained. As a platform grows, the importance of ethical alignment becomes increasingly essential.

Ethical moderation is a product necessity, not a nice-to-have. And it’s essential to earning trust.

Understanding Bias in Moderation

Bias enters moderation systems in many ways.

Machine learning models mirror the data they are trained on. Human reviewers bring cultural and contextual assumptions. Over time, these biases compound into systematic patterns that can disadvantage certain groups or amplify harmful narratives.

Algorithmic Bias

AI models are powerful for scaling moderation, yet they are only as fair as their training data. When datasets underrepresent certain dialects, languages, or communities, the model cannot accurately identify intent or nuance.

For example, certain varieties of English used by marginalized communities have historically been mislabeled as harassment. Similarly, languages with limited online data often experience underdetection, allowing harmful content to slip by.

Differences in sensitivity across categories also create ethical questions. Political speech, for example, may be treated with more caution than hate speech, which can confuse both users and reviewers.

Human Reviewer Bias

Human moderation remains crucial, especially for content that is ambiguous. These reviewers rely on lived experience, cultural norms, and personal judgment. Their perspectives are valuable but inconsistent. Fatigue, emotional strain, and the volume of content can also lead to uneven enforcement across teams or regions.

These inconsistencies can lead to unequal treatment, where similar cases receive different outcomes, thereby undermining both fairness and trust.

Why Fairness Is a Core Requirement

Fairness sits at the heart of ethical moderation. More than simply making the right decision, it ensures that the process leading to that decision is just, explainable, and accountable.

Procedural Fairness

Users expect clear rules that are consistently applied. Procedural fairness means every step of the moderation process is transparent.

This includes having stable community guidelines, predictable enforcement, and meaningful appeal systems. Users are more likely to accept outcomes when they believe the process is legitimate.

Distributional Fairness

Moderation systems must ensure that no group is unfairly targeted or disproportionately silenced. Automated systems that overflag content from certain demographics can create real harm by reducing representation or discouraging participation. Evaluating false positives and false negatives across demographic groups is essential for building equitable systems.

Transparency and Explainability

Users deserve to understand why their content was flagged or removed. Explainability also fulfills regulatory expectations and creates a healthier relationship between platforms and communities.

Even simple explanations can reduce confusion, build trust, and mitigate the chilling effect of overly strict or unclear rules.

The Challenge With Ethical Moderation

Balancing safety, expression, and fairness is inherently difficult. Platforms must make tradeoffs between preventing harm and protecting legitimate discourse. These tradeoffs vary across regions, cultures, laws, and community expectations.

Censorship vs Safety

One of the strongest tensions in moderation appears in the interplay between censorship concerns and safety needs. Removing harmful content protects users, but removing too much content can restrict open dialogue.

Ethical moderation attempts to find a middle ground that prioritizes safety without diminishing diverse expression.

Platform norms and public norms also differ. Community guidelines reflect the values of the platform, while users may hold other expectations rooted in their own cultural or political context. Meanwhile, governments may create additional pressure by imposing content compliance rules that risk regulatory overreach.

Tradeoffs Around Free Speech

Traditional free speech laws do not govern online spaces. Platforms are not required to host all speech. Yet users generally expect neutrality and ideological balance. This expectation becomes more complicated when legal speech is still harmful. Disinformation, bullying, and coordinated manipulation campaigns can cause damage without technically breaking laws.

The paradox of tolerance also applies. Allowing intolerant speech may reduce the total amount of speech in a community by driving people away.

The Chilling Effect

When rules are unclear or inconsistently applied, users may self-censor out of fear. Over-moderation discourages creativity, participation, and discussion.

Ethical moderation aims to avoid this chilling effect by making decisions predictable and guidelines easy to interpret.

Best Practices for Ethical Moderation

Solutions to ethical challenges involve a combination of better data, stronger processes, more transparent communication, and thoughtfully designed AI systems.

Build Bias Mitigation Into the Moderation Lifecycle

Bias is inevitable in moderation systems. Ethical moderation assumes bias will appear and builds mechanisms to detect and reduce it continuously.

Effective teams move through a recurring cycle:

1. Detection — Measure false positives and false negatives across content categories, languages, regions, and dialects, not just overall accuracy.
2. Diagnosis — Identify whether disparities stem from training data gaps, model thresholds, unclear guidelines, or reviewer interpretation.
3. Intervention — Adjust datasets, retrain models, recalibrate reviewers, or update policy language.
4. Verification — Re-test changes against the same fairness metrics to confirm improvement.
5. Communication — Document and explain changes internally and, where appropriate, externally.

Use Diverse and Representative Data to Prevent Systematic Harm

Moderation models inherit the strengths and weaknesses of their training data. Datasets that underrepresent certain communities, dialects, or regions often lead to disproportionate enforcement errors.

To reduce this risk:

• Include linguistic and cultural variation in training and evaluation data
• Test performance across demographic and regional slices
• Avoid relying solely on globally aggregated metrics

The goal is not perfect neutrality, but proportional accuracy that does not consistently disadvantage specific groups.

Combine AI Scale With Human Judgment

AI moderation is essential for scale, consistency, and speed, but ethical systems avoid full automation in high-impact or high-context scenarios.

Best practice architectures:

• Use AI for first-pass classification, prioritization, and volume reduction
• Route ambiguous, sensitive, or high-impact decisions to human reviewers
• Maintain human oversight over automated enforcement pipelines

This hybrid approach reduces reviewer fatigue while preserving nuance, accountability, and contextual understanding.

Standardize Human Review Through Calibration

Human reviewers bring cultural awareness and contextual reasoning, but inconsistency is a major ethical risk.

To improve fairness:

• Run regular calibration sessions using real edge cases
• Align reviewers on how guidelines apply in ambiguous scenarios
• Monitor inter-reviewer agreement rates over time

Calibration turns subjective judgment into a shared standard, improving both consistency and trust.

Design for Procedural Fairness, Not Just Outcomes

Ethical moderation depends as much on how decisions are made as on what decisions are reached.

Procedural fairness requires:

• Clear, stable community guidelines written in accessible language
• Predictable enforcement patterns across similar cases
• Meaningful appeal processes with human review
• Timely and understandable responses to user actions

When users believe the process is fair, they are more likely to accept outcomes (even unfavorable ones).

Make Decisions Explainable by Default

Opaque moderation decisions undermine trust and increase frustration, appeals, and accusations of bias.

Explainability does not require exposing models or internal systems. Even simple explanations help:

• Identify which rule was triggered
• Clarify whether the decision was automated or human-reviewed
• Indicate how users can avoid future violations

Use Ethical Frameworks to Guide Hard Decisions

Moderation teams regularly face gray areas where no outcome is universally correct. Ethical frameworks provide consistency when rules alone are insufficient.

Common lenses include:

• Utilitarian — Which decision minimizes overall harm?
• Rights-based — Are individual freedoms being unnecessarily restricted?
• Justice-focused — Does the decision disproportionately affect vulnerable groups?
• Pragmatic — What is enforceable at scale without creating new risks?

Documenting which lens informed a decision helps teams align internally and explain reasoning externally.

Monitor and Publish Fairness Signals

Ethical moderation requires accountability. Transparency reporting demonstrates that systems are measured, audited, and improved over time.

Useful signals include:

• Accuracy and error rates by category and region
• Appeal volumes and reversal rates
• Known limitations or edge cases
• Changes made in response to identified disparities

These reports build credibility with users, regulators, and internal stakeholders.

Common Ethical Failure Modes to Avoid

Many moderation failures stem from predictable gaps:

• Over-reliance on automation without oversight
• Inconsistent reviewer enforcement across regions
• Measuring success only through aggregate accuracy
• Unclear or shifting guidelines
• No feedback loop from appeals into model improvement

Recognizing these failure modes early helps teams design systems that degrade gracefully rather than fail silently.

Ethical Moderation as a Product Discipline

Yes, ethical moderation reduces harm, but it should also establish clear rules, explain decisions, and ensure consistent enforcement. Well-designed moderation systems both assume complexity and plan for disagreement.

Over time, these qualities support safer communities and sustainable growth.

The Role of AI in Ethical Moderation

AI is essential for scaling moderation, especially on large platforms.

When built carefully, AI enhances consistency, alleviates human burden, and promotes fairness. It can also detect patterns and categories humans struggle to identify.

However, AI introduces its own risks. Opaque models can make it challenging to explain decisions. Biased training data can amplify harmful patterns. Automated decisions without oversight can lead to unfair outcomes.

Human-in-the-loop and human-on-the-loop systems mitigate these concerns. Moderators review edge cases, interpret nuance, and oversee automated pipelines. This partnership between AI and human judgment is critical for accountability.

Platforms must also define responsibility. When an AI system makes a decision, the accountability still lies with the platform. Ethical governance means documenting model behavior, decision boundaries, training data sources, and known limitations.

Where Moderation Ethics Is Headed

Moderation ethics are evolving rapidly.

Global regulations are increasing transparency requirements, safety obligations, and expectations for explainable AI. The Digital Services Act, in particular, sets new standards for algorithmic accountability.

Platforms will face stronger expectations to justify automated decisions, measure fairness, and provide users with recourse. Public institutions and private companies are starting to collaborate on establishing norms that will guide the future of online governance.

The rise of constitutional AI approaches also signals a shift toward models trained with ethical principles built directly into their reasoning. These approaches offer new opportunities for more consistent, values-aligned moderation.

As online communities become increasingly complex, ethical moderation becomes both more challenging and more crucial. Teams that embrace transparency, AI moderation support, fairness, and thoughtful design will be best positioned to build safe, inclusive, and trustworthy platforms.

Content Moderation Ethics: Navigating Bias, Censorship & Fairness was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

You’re working in a warehouse when you see an automated forklift barreling towards a coworker. You whip out your phone and type “STOP!” into the app controlling the vehicle. You add another exclamation point to make sure it knows it’s an emergency.

That’s not good enough, and it’s not how things have to be.

AI can revolutionize real-world workplaces, but not the way it works right now. There can be no typing when your hands are full, and there can be no “Thinking…” when milliseconds mean safety. To work alongside humans, any real-world AI needs to see, hear, and perceive the world as a human does. It needs to hear a shouted “STOP!” and do so, or see the forklift out of control and immediately shut it down without human intervention.

Vision and speech AI gives machines the ability to see and hear in ways that actually connect to human behavior. These systems can interact with the world in the natural way we do, integrating directly into real-world workflows.

How is this happening today? And how can developers start to think about and build AI out in the real world?

Vision AI Keeps Industrial Workers Safe

Construction and industrial environments are some of the hardest places to deploy AI. You have people and machinery constantly moving, in poorly lit environments, where a single missed hazard can result in injury and death.

Human behavior, machine behavior, and environmental state are all part of the perceptual mix, and decisions need to be made on-site, under strict latency requirements.

Kajima, one of Japan’s largest construction firms, deployed Archetype’s physical AI across active job sites to monitor high-risk human-machine interactions in real time. Unlike single-model or single-sensor systems, Kajima’s deployment fused video, depth, LiDAR, and environmental data into a unified spatial model of the site.

This enabled the system to track:

• Worker proximity to heavy machinery (cranes, excavators, autonomous vehicles)
• Unauthorized entry into hazardous or exclusion zones
• Unsafe behavioral patterns, such as workers standing in blind spots
• Equipment anomalies (unexpected motion, machinery operating out of sequence)

Because construction sites have unreliable connectivity and high privacy requirements, Kajima ran the perception models entirely on-site, on local GPUs. This eliminated cloud latency and ensured that when the vision AI recognized a dangerous event, such as a worker stepping into a moving excavator’s turning radius, it could trigger an instant local alert, a signal to the machine operator, or an automatic stop condition if integrated with control systems.

This highlights core architectural patterns developers need to adopt for industrial perception:

1. Multimodal fusion is mandatory. Text alone doesn’t work. You need video and audio at a minimum to start to understand these environments. Depth, LiDAR, and sensor telemetry then help to stabilize the model of the world and reduce failure modes.
2. Edge inference is the default. If your model’s output is tied to safety or machine control, you cannot afford cloud round-trips. Latency budgets are on the order of tens of milliseconds. On-prem GPU boxes with embedded AI are the only viable option.
3. Safety requires continuous state estimation. Developers should think in terms of temporal reasoning: tracking trajectories, modeling intent, and prediction. In these environments, users need not just detection, but intervention.
4. Event-driven integrations turn perception into action. This is mission-critical AI. It stops machines, sends alerts, logs incidents, and saves lives.

As with Kajima, vision and speech AI systems will become core infrastructure that changes how safety protocols are enforced, how incidents are prevented, and how human and machine workflows are coordinated.

Speech AI is Critical in Operations

Speech is part of the operational control loop. In high-noise, high-tempo environments, a “shut it down!” shouted across the room can be faster than reaching for an emergency button and more reliable than hoping someone sees a hand waving.

Audio then needs to be treated as a parallel channel rather than a separate subsystem. If you are thinking in text rather than speech, the extra step means seconds that the machine isn’t shut down. Speech AI needs to fuse with vision AI and sensor data to generate reliable, real-time interpretations of events.

Modern ASR systems (such as Whisper, Deepgram, or custom domain-tuned models) are now robust enough to operate in factories, warehouses, and construction sites where noise floors routinely exceed safe listening levels.

These are only transcription services. They can classify operational intent, detect urgency, and be used to build out workflows. With speech AI, developers can build:

• Voice-logged maintenance and inspection systems. Technicians performing inspections or repairs can dictate findings while working, instead of pausing to write logs (e.g., “Unusual vibration on Pump A, bearings likely failing.”) The ASR output can feed directly into CMMS/maintenance databases.
• Safety-critical speech triggers. Speech models can run continuously on edge devices, listening for predefined emergency phrases like “Emergency!” or our “Shut it down!” example above. These can be paired with visual AI (e.g., recognizing a person entering a danger zone) so the system can trigger stop signals for machinery and alarms.
• Hands-free queries for real-time data. Operators frequently need sensor values without dropping tools. Speech AI can run a loop with the plant’s telemetry systems, returning data verbally or via heads-up displays.

Deploying speech understanding in operations isn’t about transcription accuracy alone. There are key principles developers have to consider:

1. Noise is the default condition. Industrial environments have baseline noise levels of 85–100 dB, requiring models trained on augmented datasets with machinery sounds, alarms, and overlapping voices, not clean office recordings.
2. On-prem inference is required for safety-grade latency. When a worker yells “stop,” the speech AI needs to process that command and halt machinery in under 100 milliseconds, which means running models locally on edge hardware rather than waiting for cloud round-trips.
3. Speech must feed into an event model. Raw transcription becomes actionable only when the speech AI understands context: who said it, where they are, what equipment they’re near, and whether the command requires immediate machine intervention or just logging.
4. The value emerges when speech and vision converge. A worker pointing at a gauge while saying “this reading looks wrong” requires the vision AI to fuse visual object detection with speech understanding to identify which specific gauge, read its value, and determine if intervention is needed.

When speech and vision AI operate as a unified perception layer, they create systems that understand not just what workers are saying or what the cameras see, but the full context of human intent and machine state. This multimodal fusion is what transforms perception from a monitoring tool into an active participant in operational workflows.

Multimodal AI Powers Assistive and Accessibility Tools

Accessibility systems are among the purest expressions of real-time perception: they must continuously interpret a user’s environment, respond within strict latency, and adapt their output to the user’s cognitive and sensory constraints.

Unlike industrial systems that optimize for throughput or safety margins, assistive vision and speech AI optimize for clarity, privacy, and contextual relevance. You need to describe not just what’s in a scene, but what matters to the user. Assistive technologies need to combine on-device vision models, speech recognition, and language-model reasoning to deliver real-time understanding.

Apps like Be My Eyes’ “Virtual Volunteer” demonstrate how multimodal models move beyond object detection and OCR. Users submit a photo or a continuous video stream, and the system:

• Identifies salient objects (food items, signage, screens)
• Reads and summarizes text
• Infers context (e.g., “these ingredients could make a pasta dish”)
• Answers follow-up questions with conversational precision

Wearables like XRAI Glass take this further, pairing ASR with AR displays to caption speech in the user’s field of view. These include low-latency, on-device ASR, continuous streaming transcription, diarization (identifying who’s speaking), and projection to overlay text in physical space.

These systems need to handle overlapping speech, reverberant rooms, and mixed accents, all in real time.

Assistive vision and speech AI force developers to solve some of the most challenging perception problems:

1. A spoken caption that appears 700ms late is unusable, and a scene description that lags by a second destroys the interaction. Developers must design for sub-200-ms feedback loops.
2. On-device inference is the default privacy posture. Many users cannot (or should not) upload raw video/audio, so models must be optimized to run on mobile GPUs, NPUs, or edge accelerators.
3. Summarization > enumeration. Blind users do not want “There is a table. There is a chair. There is a lamp.” They want contextual interpretation: “Your coffee mug is on the far right side of the table, near the edge.” This requires multimodal perception + LLM reasoning, not raw detection.
4. Developers must build for not just what the system detects, but how it communicates: concise TTS, AR text, haptic cues, and summaries.

The accessibility domain generalizes to other real-time perception problems. Design constraints developed here, such as low latency, privacy-preserving inference, contextual summarization, map directly to robotics, industrial safety, and autonomous systems.

Temporal AI is Essential for Sports Analytics

Sports environments push vision AI to its limits. Players move at high speed, balls travel even faster, camera angles shift constantly, and multiple events compete for attention. Unlike controlled industrial settings, sports vision AI must track everything while maintaining player identity across multiple camera feeds and delivering insights fast enough for broadcasting, coaching, and officiating.

The challenge isn’t just detecting what happened, but understanding the context and significance of each moment. A spike in crowd noise could signal a goal, a near-miss, or a controversial call. A player’s sudden deceleration might indicate fatigue, tactical positioning, or injury.

Hawk-Eye (tennis, cricket) and VAR (soccer) use multi-camera triangulation to track ball position and player movements for officiating decisions. Second Spectrum (NBA) and Next Gen Stats (NFL) provide real-time analytics by processing multiple video feeds to track players, ball trajectories, and game events.

These systems combine computer vision with audio processing to create comprehensive game understanding.

• Player and ball tracking across the entire field of play
• Automatic offside detection and line-call verification
• Team formation and spacing analysis
• Injury risk detection through biomechanical analysis
• Automated highlight detection using crowd noise and visual cues

The technical requirements for sports perception create unique developer challenges:

1. Single-frame detection is insufficient. Single-frame detection fails when tracking fast-moving players who cluster, occlude each other, or temporarily leave the frame.
2. Sports systems often ingest 8–24+ feeds simultaneously. Officiating decisions require perfect frame alignment across feeds to determine the exact moment of rule violations.
3. Multimodal fusion reduces false positives. Vision identifies player actions, audio captures crowd reactions, and commentary provides semantic context that no single modality can deliver alone.
4. Latency requirements vary by use case. Officiating can tolerate seconds for review, while injury detection must flag risks immediately.

Sports perception systems are blueprints for any fast-moving, multi-agent scenario. The same principles that track basketball players through screens apply to warehouse robots, autonomous vehicles, and drone coordination, but with every decision visible to millions of viewers in real-time.

Frequently Asked Questions

How can I combine vision and audio inputs to interpret real-time events?

You must treat audio as a parallel channel for multimodal fusion rather than relying solely on text. Speech AI captures intent and urgency (e.g., a shouted “Stop!”), while vision AI provides physical context (e.g., a worker in a danger zone). When fused, these inputs allow the system to understand the full context of human intent and machine state.

What’s the best architecture for low-latency perception in edge environments?

Edge inference is the required default for safety-critical operations. To meet latency budgets of under 100 milliseconds, you must use on-premise GPU hardware or embedded AI to process data locally. This architecture eliminates cloud round-trips, allowing the vision AI to trigger instant alerts or machine stops immediately upon detecting a hazard.

How can accessibility features use perception AI safely and privately?

Accessibility tools should utilize on-device inference as the default posture to ensure user privacy, avoiding the need to upload raw video or audio. These systems combine vision and speech AI to deliver contextual summaries — interpreting what matters to the user rather than just listing objects — and must operate with sub-200ms feedback loops to remain usable.

What’s the difference between industrial and sports vision systems?

Industrial vision AI optimizes for safety and immediate intervention in poorly lit environments with heavy machinery. In contrast, sports vision AI must track high-speed, multi-agent scenarios across 8–24+ simultaneous camera feeds, maintaining player identity and alignment for broadcasting and officiating decisions.

How do I evaluate real-world perception systems for accuracy and reliability?

You should evaluate systems based on “continuous state estimation” (temporal reasoning) rather than single-frame detection, which often fails in dynamic environments. Reliability is achieved through multimodal fusion (combining vision, speech, and sensor data) to stabilize the world model, reduce false positives, and enable the system to predict trajectories and intent.

Building Perception Systems for the Real World

Every deployment faces the same architectural decision tree.

Safety-critical systems like Kajima’s construction monitoring require edge inference with sub-100ms latency, processing everything locally on GPUs to avoid network dependencies. Broadcasting and analytics systems can leverage hybrid architectures, using edge devices for initial processing and cloud resources for deeper analysis. Accessibility tools require on-device inference by default, both for privacy and responsiveness, while sports systems often distribute processing across multiple tiers to handle dozens of camera feeds simultaneously.

The convergence of vision, speech, and temporal AI isn’t just enabling new applications; it’s creating a blueprint for how AI systems interact with the physical world. Developers building these systems are creating the sensory layer that lets AI understand, respond to, and ultimately reshape how we work, play, and live in real environments.

From Cameras to Action: Real‑World Applications of Vision and Speech AI was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.

As online platforms strengthen their safety frameworks, malicious users respond with increasingly creative ways to evade detection. The rise of content moderation circumvention is not a surprise. Modern apps support global conversations at scale, and as moderation becomes more effective, the incentive to outsmart it grows.

But circumvention isn’t increasing solely because moderation is improving. It’s also rising because today’s digital environments make evasion easier.

AI-generated text, global user bases, and real-time formats give bad actors the perfect cover to hide within rapid, fragmented communication patterns. At the same time, trust and safety teams are expected to operate faster with fewer resources while catching more nuanced misconduct.

In this guide, we’ll explore the most common evasion tactics: algospeak, obfuscation, and adversarial manipulation. We’ll also outline how platforms can counter them using modern detection strategies, multimodal AI, and human-in-the-loop workflows.

What Is Moderation Circumvention?

Content moderation circumvention refers to actions taken deliberately to avoid safety checks, filters, or enforcement. These behaviors can be human-generated, AI-assisted, or fully automated. Regardless of the method, the intent is the same: pass harmful content through systems designed to block it.

People evade moderation for many reasons. Some simply want to bypass profanity filters. Others attempt to coordinate harassment, share self-harm content, or spread misinformation while avoiding bans. In marketplace or transactional apps, evasion often aims to lure buyers away from secure channels to complete scams through external payments.

Several factors are accelerating circumvention patterns:

• Easy access to AI tools
• Cultural shifts in online spaces where euphemism communities form
• Growth of global platforms with multilingual challenges
• High-risk categories like dating, marketplaces, gaming, and live chat, where real-time content is harder to review

These forces make platform circumvention more widespread and more difficult to stop with traditional moderation alone.

Algospeak: The Language of Evasion

Algospeak is community-driven coded language intentionally designed to avoid detection by automated systems. It often emerges organically when users realize that certain keywords trigger moderation. Over time, entire subcultures develop around alternative phrasing.

You see this across mainstream communities on TikTok, Discord, and Reddit. Instead of using terms directly associated with sensitive topics, users swap in replacements that models are less likely to flag. Although this sometimes happens for non-malicious reasons, it is equally common in harmful contexts, including self-harm forums or extremist spaces.

Common Algospeak Strategies

A few patterns recur consistently across platforms.

• Phonetic substitutes such as “seggs,” “unalive,” or “sewer slide”
• Emoji codes where symbols replace banned words
• Euphemism communities that invent full vocabularies
• Mandated language shifts in stigmatized or high-risk groups, such as eating disorder recovery spaces, hate groups, or self-harm clusters

These strategies evolve quickly because communities rapidly copy each other and modify terms as they become detectable.

Why Algospeak Works Against AI

Algospeak is effective because it exploits known weaknesses of automated models.

• AI depends on patterns it has seen before
• New terms appear faster than models can be retrained
• Cultural nuance is difficult to capture across languages
• Many terms are context-dependent and harmless in certain settings

A simple vocabulary change can bypass systems that rely solely on keyword lists or outdated models.

Obfuscation: Hiding Harm in Plain Sight

Obfuscation refers to techniques that disguise harmful content so it appears harmless to moderation systems, making it difficult for automated filters to recognize or block violations.

Below are a few of the most common ways users do this.

Character Manipulation

One of the oldest forms of circumvention involves tampering with characters so that text appears normal to humans but unreadable to models.

Common character-based methods include:

• Leetspeak substitutions like “h4t3”
• Zero-width spaces that break up words
• Unicode homoglyphs that look identical to common characters
• Deliberate misspellings or strategic spacing

These tricks require minimal effort yet completely bypass traditional keyword filters.

Format Manipulation

Bad actors often switch formats to remove or blend the harmful text into a medium that automated systems struggle to scan.

Examples include:

• Screenshots of text
• Handwritten words inserted into images
• Embedded text in videos or livestream overlays
• Encoded messages using Base64 or ROT13

Image-only or audio-only pipelines often lag behind text classification, making these attacks effective in real-time chat or community apps.

Intent-Based Obfuscation

Some users rely on ambiguity rather than explicit manipulation.

Common patterns include:

• Sarcasm or “ironic” wording that still conveys harm
• Dog whistles familiar only to specific groups
• Jokes that double as harassment
• Friendly language masking malicious intent
• Innocent phrasing with contextual red flags

These tactics make moderation difficult because they require deeper semantic understanding.

Adversarial Tactics Targeting AI Models

Some users go beyond obfuscation and intentionally manipulate inputs to mislead AI systems.

These attacks often fall into three categories: input manipulation, context evasion, and coordinated evasion, each targeting different parts of the detection pipeline.

Input Manipulation

Bad actors can introduce tiny modifications specifically designed to confuse classifiers. These attacks exploit the way AI interprets patterns.

Common examples include:

• Random punctuation inserted in harmful phrases
• Visual noise added to images
• Slight audio warping that hides keywords
• Distracting symbols woven into text

To humans, the content still appears clear. To an unprepared model, it looks entirely different.

Get started! Activate your free Stream account today and start prototyping with moderation.

Context Evasion

Instead of hiding words, some users fragment harmful meaning across multiple messages or imply meaning indirectly.

Methods include:

• Splitting a harmful sentence into several posts
• Suggestive phrasing that implies outcomes without naming them
• Role-playing scenarios that violate platform policy
• Context windows manipulated to mislead AI

This is common in real-time chat where velocity and message order matter.

Coordinated Evasion

Some communities work together to defeat moderation.

These groups often create:

• Dictionaries of coded terms
• Versioning systems where new vocabulary replaces flagged language
• Organized raids where users post in synchronized patterns
• Group training on how to bypass filters

Coordinated networks can scale evasion faster than platforms can respond.

Real World Examples of Evasion

Modern apps see circumvention patterns across nearly every risk category.

Examples include:

• Hate speech hidden through symbols that look innocent at first glance
• Self-harm content disguised as aesthetic trends using pastel imagery and coded language
• Scams that mask product names to lure marketplace buyers into off-platform payments
• Child safety evasion through mislabelled hashtags or emojis
• Misinformation disguised as parody that exploits the blurred line between humor and harmful narratives

Marketplace and transactional apps face a specific threat: scammers intentionally skirt moderation to pull buyers away from safe in-app payments. Once outside the platform, users lose payment protection and become easy targets. These evasion tactics often mix obfuscation with persuasion patterns that appear legitimate.

Why Traditional Moderation Struggles to Keep Up

Moderation stacks often rely on a mix of static rules, manual review, and outdated machine learning. Circumvention evolves faster than these approaches can adapt.

Key challenges include:

• Long lag time between term emergence and model updates
• Cultural nuance that cannot be captured with one-size-fits-all rules
• Massive volume and velocity in real-time chat
• Single-model systems that fail to catch multimodal content
• Human reviewers overwhelmed by obfuscated and ambiguous content

If your platform relies solely on keywords, basic classifiers, or slow escalation workflows, evasive behavior will always stay one step ahead.

How Platforms Can Fight Moderation Evasion

No single model or rule can stop evasion on its own. Effective defense requires multiple layers, including modern detection systems, continuously updated pipelines, powerful moderation tools, and strong human — AI collaboration.

Multi-Layered Detection Systems

The most effective strategy against circumvention is layering multiple techniques. No single model is strong enough to catch every type of evasion across every content type.

A multilayer system may include:

• AI-powered classifiers for text, image, and video
• Heuristics that look for velocity anomalies
• Behavioral signals such as rapid channel switching or repeated failed sends
• Reputation scoring based on long-term user patterns
• Anomaly detection for suspicious spikes or unusual vocabulary

Combining rule-based and AI-based systems reduces blind spots.

Updated Moderation Pipelines

Modern platforms must treat moderation as a living system. That means continual updates and adaptation.

Effective pipelines often include:

• Continuous model retraining with fresh examples
• Real-time feedback loops from moderators
• Strong community reporting features
• Alignment between policy teams and model training teams
• Rapid incorporation of new slang and cultural references

This allows platforms to respond the moment new circumvention patterns emerge.

Moderation Tools and Dashboards

Trust and safety teams need tools that surface patterns instead of burying them.

Helpful capabilities include:

• Dashboards that highlight suspicious content
• Contextual conversation threads that reveal intent
• Multi-language coverage
• Queue systems that split cases by severity
• Insights into user history or known evasion patterns

The goal is not only to catch harmful content but also to make moderation workflows efficient.

Human and AI Collaboration

AI alone cannot solve the issue of moderation circumvention. Humans provide cultural understanding, nuance, and judgment that models cannot match.

Teams benefit from:

• Human verification for ambiguous or high-risk content
• Linguistic specialists who understand regional slang
• A trust and safety team structure that allows fast escalation
• Clear response protocols for urgent cases

Blending machine speed with human insight removes blind spots and reduces errors.

Your Best Defense Against Bad Actors

Content moderation circumvention is an inevitable part of running a digital platform. As long as filters exist, people will search for ways to evade them. The key is not eliminating evasion but minimizing its impact through adaptive, multi-modal, and constantly evolving strategies.

For product managers, developers, and trust and safety teams, the priority is building moderation systems flexible enough to learn, adjust, and scale. Multi-layer detection, continuous retraining, intelligent dashboards, and human expertise create a strong foundation against evasion attempts.

When platforms invest in dynamic safety infrastructure, they not only reduce harm but also protect the integrity of transactions, conversations, and communities. With the right approach, moderation circumvention becomes manageable and far less disruptive to user trust. Solutions like Stream’s flexible AI Moderation API, real-time signals, and automated classifiers can strengthen this foundation and provide your team with the tools needed to stay ahead of bad actors as their tactics evolve.

Content Moderation Circumvention: Algospeak, Obfuscation, and Adversarial Tactics was originally published in Stream on Medium, where people are continuing the conversation by highlighting and responding to this story.