# About Agora (/en/introduction/about-agora)

> For AI agents: see the complete documentation index at [llms.txt](/llms.txt).

## What Agora is [#what-agora-is]

Agora is a real-time platform for products where people, devices, services, and AI systems need to stay connected inside the same live session.

Instead of treating voice, video, messaging, AI orchestration, and media processing as separate stacks, Agora gives you a shared real-time foundation you can build on. You can start with one immediate use case, such as voice calling or an AI agent, and then extend the same session architecture into messaging, cloud processing, analytics, and production operations.

<CalloutContainer type="info">
  <CalloutTitle>
    Think in live sessions, not isolated features
  </CalloutTitle>

  <CalloutDescription>
    Agora is easiest to understand when you treat it as a shared real-time layer for interaction, coordination, AI participation, and media workflows.
  </CalloutDescription>
</CalloutContainer>

## What problems it solves [#what-problems-it-solves]

Teams usually come to Agora when they need to solve more than one live-product problem at the same time:

* Keep voice and video interactions usable under real-world network conditions.
* Coordinate room state, presence, events, and messaging alongside live media.
* Add voice AI into a live session instead of bolting AI onto a disconnected backend flow.
* Record, transcribe, translate, transform, or distribute media after the session starts.
* Operate production systems with the credentials, security, monitoring, and governance live products require.

In practice, this means Agora is most useful when your product is not just sending a message or making a single API call, but managing an ongoing real-time experience.

## Product families [#product-families]

Agora's docs are easier to navigate when you group the platform into four product families instead of reading it as a list of unrelated SKUs.

<CardGrid>
  <FeatureCard title="Conversational AI">
    Build voice agents, assistants, tutors, support flows, and multimodal AI experiences that participate in a live real-time session.
  </FeatureCard>

  <FeatureCard title="Real-Time Voice & Video">
    Build calling, meetings, classrooms, livestream interaction, smart-device media flows, and other low-latency communication products.
  </FeatureCard>

  <FeatureCard title="Messaging & Presence">
    Keep users, devices, and room state synchronized with chat, presence, metadata, signaling, and collaboration surfaces.
  </FeatureCard>

  <FeatureCard title="Cloud Media Services">
    Extend live sessions with recording, speech-to-text, translation, push and pull workflows, transcoding, and distribution tooling.
  </FeatureCard>
</CardGrid>

## How these products fit together [#how-these-products-fit-together]

The most useful mental model is to think in layers of responsibility:

1. **Projects and credentials** define access, billing scope, and service boundaries.
2. **Real-time sessions** connect users, devices, and agents inside a shared live context.
3. **Voice, video, and messaging** carry interaction, room state, and events through that context.
4. **AI and server-side control** add orchestration, automation, callbacks, and business logic.
5. **Cloud media services** capture, transform, translate, distribute, and observe the live session.

You do not need every layer on day one. The value of the platform is that these layers can be added over time without forcing you to replace the underlying session model.

## Common solution patterns [#common-solution-patterns]

Most implementations start from a small number of repeatable patterns:

<CardGrid>
  <FeatureCard title="RTC only">
    Start with live voice or video when the main requirement is low-latency communication between participants.
  </FeatureCard>

  <FeatureCard title="RTC + RTM">
    Add room messaging, presence, and coordination when participants also need shared state, chat, or event-driven flows.
  </FeatureCard>

  <FeatureCard title="RTC + AI">
    Add a voice agent when an AI system needs to join the session as a live participant instead of a separate backend service.
  </FeatureCard>

  <FeatureCard title="RTC + Recording or STT">
    Extend a live session with archive, compliance, captions, transcripts, translation, or post-session processing.
  </FeatureCard>

  <FeatureCard title="AI + Device">
    Build smart-device or embedded experiences where microphones, speakers, sensors, and agents operate through the same real-time path.
  </FeatureCard>
</CardGrid>

These patterns are helpful because they let you choose a narrow first milestone while keeping a clear path to the rest of the platform.

## Where to start [#where-to-start]

Choose the next page based on the first problem you need to solve:

* Start with [Start with AI](/en/introduction/start-with-ai) if you want an AI-assisted path using Skills, MCP, and agent-friendly docs.
* Go to [Conversational AI](/en/introduction/conversational-ai) if your main product is a voice agent, assistant, tutor, or spoken AI experience.
* Go to [Real-Time Voice & Video](/en/introduction/realtime-audio-video) if your first milestone is calling, meetings, classrooms, livestream interaction, or device media transport.
* Go to [Messaging & Presence](/en/introduction/messaging-presence) if chat, presence, signaling, or shared room state is your main coordination problem.
* Go to [Cloud Media Services](/en/introduction/cloud-media-services) if you need recording, transcription, translation, media routing, or stream transformation around a live session.
* Read [Core Concepts](/en/introduction/core-concepts) if you want the platform primitives before choosing a build path.

When you move from prototype to production, continue with [Projects](/en/introduction/projects), [Console setup](/en/introduction/console-setup), [Billing](/en/introduction/billing), and [Security and privacy](/en/introduction/security-privacy).