How can i authorize my CD pipeline to run lk agent deploy automatically? How do i tell the pipeline which account im working in?

Thanks for reaching out, Benjamin. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

when i run lk agent deploy, do i need to do something so it just works without requiring more input?

Thanks — I’m replying about running

lk agent deploy

fully non-interactively in your CD pipeline. Short answer • Yes —

lk agent deploy

can run without any interactive prompts if the CLI has the project config and credentials up front. What you must provide so it runs headless • Credentials (env vars) Set these in your CI/CD secret store and make sure they are available to the job: •

LIVEKIT_API_KEY

•

LIVEKIT_API_SECRET

•

LIVEKIT_URL

The CLI reads these and won’t prompt for login. • Agent/project config file Ensure

livekit.toml

(created by

lk agent create

) is present in the repo or workspace. It contains the agent ID/project subdomain so

lk agent deploy

knows which agent to update. • Agent secrets (if used) If your agent needs runtime secrets, provide them ahead of time via: •

--secrets-file

(e.g., a file with environment-style vars), or •

--secrets

flags, or • configure them earlier with

lk agent update-secrets

That prevents prompts for secret input during deploy. Optional flags you can use in CI • Pass credentials and URL explicitly:

lk agent deploy \
    --api-key "$LIVEKIT_API_KEY" \
    --api-secret "$LIVEKIT_API_SECRET" \
    --url "$LIVEKIT_URL"

• Include a secrets file:

lk agent deploy --secrets-file .env

• Set region programmatically if needed:

--region <region>

Security reminders • Never commit API keys/secrets to the repo. • Use your CI/CD provider’s secret storage so values are injected at runtime and not printed in logs. If you want, I can: • Provide a ready-to-use snippet for your CI platform (GitHub Actions, GitLab CI, CircleCI, etc.). • Review a sample job you have and suggest where to inject the env vars and how to keep secrets out of logs. Which CI are you using? Sources: Google AI and LiveKit | LiveKit Documentation | examples/drive-thru | livekit/livekit_composite | DeepWiki | Server-side | livekit/livekit_composite | DeepWiki | Agents (Python) | livekit/livekit_composite | DeepWiki | Agent deployment overview | LiveKit Documentation

how can i locally talk to the agent i deployed. I also need to send job context metadata to it

Thanks — I’m replying about how to talk to a deployed agent from your local machine and how to send job context metadata to it. Quick summary • You can run the agent locally in either console mode (terminal I/O) or dev mode (connects to LiveKit Cloud and lets you test via the Agents Playground). • Send job context metadata by including a JSON string when you dispatch the agent (via the agent dispatch API or by embedding metadata in a room token). The agent reads it as

ctx.job.metadata

. How to run and talk to the agent locally • Console mode (terminal interaction): run your agent locally so you can speak/type directly in your terminal. Example:

uv run agent.py console

This starts the agent locally and lets you interact directly. • Dev mode (connects to cloud for browser testing): run the agent so it connects to LiveKit Cloud for real-time testing (playback from browser UI). Example:

uv run agent.py dev

Then use the Agents Playground or a test room to join and speak to the agent in real time. How to send job context metadata • Metadata must be a JSON-formatted string and is available in the agent as

ctx.job.metadata

. • Dispatch via the Agent Dispatch API (recommended when you control dispatch from backend): a. Include a metadata field in the

CreateAgentDispatchRequest

payload:

api.CreateAgentDispatchRequest(
       agent_name="my-agent",
       room="my-room",
       metadata='{"user_name":"Alice","user_id":"12345"}'  # JSON string
     )

1. Inside the agent entrypoint parse it:

metadata = json.loads(ctx.job.metadata)
     user_name = metadata["user_name"]

• Dispatch via a room token (useful when issuing client tokens for joining a room): a. Add a

RoomAgentDispatch

entry with

metadata

when building the token:

RoomAgentDispatch(agent_name="my-agent", metadata='{"user_name":"Alice"}')

1. The agent receives the metadata the same way via

ctx.job.metadata

. • Self-hosted agents: include the metadata in your dispatch request body when invoking the agent. Local testing flow examples • Quick local dev test: a. Ensure your local agent code can read

ctx.job.metadata

. b. Run

uv run agent.py dev

. c. Dispatch from your backend with metadata or create a token that includes

RoomAgentDispatch

metadata. d. Join the room (or use the Agents Playground) and verify the agent received and parsed the metadata. Notes and tips • Keep metadata concise and JSON-serializable (strings, numbers, objects). • If you need structured data, send a JSON object and parse it inside the agent. • Use console mode for fast iterative testing; use dev mode + Agents Playground to test real WebRTC flows. • Tell me whether you’re using LiveKit Cloud or a self-hosted LiveKit instance — that affects how you generate tokens and dispatch requests. If you want, I can: • Provide a small, runnable dispatch script for your stack (Python/Node). • Show a sample agent entrypoint that reads and validates

ctx.job.metadata

. Which would you prefer? Sources: Build Your First AI Voice Agent in Python: Complete Tutorial | LiveKit | Job lifecycle | LiveKit Documentation | Agent dispatch | LiveKit Documentation

please give me the dispatch sample code. Would i be able to talk through my device on that dispatch? im not talking about running the repo locally i wat to talk to the deployed agent

Thanks — I’ll reply with a dispatch sample in Python and clarify how you can speak to a deployed agent from your local device (without running the agent repo locally). Acknowledgement • You want a runnable dispatch example that sends job metadata. • You want to connect from your local device (microphone/speaker) to the already deployed agent and speak with it. Dispatch sample (Python) • This example creates a dispatch for an agent named "my-agent" into room "my-room" with JSON metadata. It uses the LiveKit server API client and assumes you set your LiveKit admin credentials via environment variables or otherwise authenticate the API client in your environment.

import asyncio
import json
from livekit import api

async def create_dispatch():
    lkapi = api.LiveKitAPI()  # Ensure this client is authenticated for your account

    metadata_obj = {
        "user_name": "Alice",
        "user_id": "12345",
        "intent": "support_call"
    }

    request = api.CreateAgentDispatchRequest(
        agent_name="my-agent",
        room="my-room",
        metadata=json.dumps(metadata_obj)  # metadata must be a JSON string
    )

    resp = await lkapi.agent_dispatch.create_dispatch(request)
    print("Dispatch created:", resp)
    await lkapi.aclose()

if __name__ == "__main__":
    asyncio.run(create_dispatch())

What this does • Creates a job that tells the deployed agent to join (or be bound to) the specified room and makes

ctx.job.metadata

available inside the agent as the JSON string you sent. How you talk to the deployed agent from your local device • You do not need to run the agent repo locally. To speak to the deployed agent, both you (the client) and the deployed agent must join the same LiveKit room. • Typical flow: a. Dispatch the agent (as shown above) with metadata and the target

room

. b. Generate a client join token for the same room and give it to your client (browser or native app). • The token should grant room join permissions for the room name you used in the dispatch. • You can embed agent dispatch entries in the token instead of calling the API if you want the client to cause the agent to start when they join. a. From your local device, use that token to connect (WebRTC) to the LiveKit room using the LiveKit SDK (browser or native). Your device will capture microphone input and send audio to the room. b. The deployed agent will be in the room (because of the dispatch). The agent will receive audio from participants and can respond; you can hear the agent’s audio through your device. Key points and example snippets • Generating a simple room-join token (conceptual; adapt to your server-side token library):

from livekit import AccessToken, VideoGrants

  token = (
      AccessToken()
      .with_identity("alice-client")
      .with_grants(VideoGrants(room_join=True, room="my-room"))
      .to_jwt()
  )
  print("Client token:", token)

• Use the LiveKit Web SDK (or native SDK) in your client to join with that token; the SDK will prompt for microphone permission and send your audio to the room. • If you want the agent to start only when a client joins, create the token with a

RoomAgentDispatch

entry including

metadata

. That causes the agent to be dispatched as part of token usage. Important details • Metadata must be a JSON string; inside the agent parse it with

json.loads(ctx.job.metadata)

. • Ensure the dispatched

room

matches the room you join from your device. • The deployed agent must be able to join the room (permissions/network) — dispatch will handle that for a LiveKit Cloud agent. • Use secure storage for API keys and tokens; never expose admin credentials to client-side code. If you want, I can: • Provide a ready-to-run example showing server-side dispatch + token generation + minimal browser client code to join the room and use your microphone. • Show a sample agent entrypoint that reads

ctx.job.metadata

and logs it when the agent starts. Which would you prefer (browser client example, native mobile, or both)?

how can i dispatch an agent to a google meet?

Thanks — I’m replying about whether you can dispatch a LiveKit agent into a Google Meet session and how to accomplish similar behavior. Short answer • You cannot dispatch a LiveKit agent directly into a Google Meet session. LiveKit agents join LiveKit rooms, and there’s no built-in cross-platform dispatch into third‑party services like Google Meet. What you can do instead (workarounds) • Bridge via a programmatic participant: ◦ Create a programmatic client (browser automation or headless WebRTC client) that joins the Google Meet call as a participant and also connects to a LiveKit room. ◦ Relay audio/video between the two connections so the LiveKit agent in the LiveKit room can hear and speak to Google Meet participants. ◦ This is the most direct way to let an agent interact with a Google Meet call but requires building a media-bridging component. • Rehost the call on LiveKit: ◦ Run the meeting in a LiveKit room instead of Google Meet. Then you can dispatch agents natively via the Agent Dispatch API or via tokens, and participants join with LiveKit SDKs (browser/native). ◦ This is the simplest and most robust option when you want native agent capabilities. • Custom media/SIP gateway: ◦ Build or use a third-party gateway that bridges Meet to a SIP/WebRTC endpoint that your LiveKit agent can join. This requires significant custom engineering and careful handling of media, codecs, and latency. Questions to help me tailor a specific plan • What level of interaction do you need from the agent? (listen-only, speak back, full voice assistant) • Is video required, or is audio enough? • Are you able to change the conferencing platform, or must this stay on Google Meet? • Do you prefer a quick prototype (e.g., browser automation bridge) or a production-grade solution (media gateway/SIP)? If you want, I can: • Outline a step-by-step prototype to bridge a Google Meet to a LiveKit room (tools, architecture, and example code pointers). • Provide a sample architecture for a production gateway and what components you’ll need (transcoding, signaling, auth, etc.). Which direction should we explore? Sources: Introduction | LiveKit Documentation | Agent dispatch | LiveKit Documentation | Outbound Calling Script | LiveKit Documentation | Yeah, but can it run DOOM? | LiveKit

i want to be able to dispatch an agent into a call so people can interact with them via voice only, for demo purposes

Thanks — I’m responding about how to dispatch a voice-only agent into a call for a demo and whether that can be done with Google Meet. Short answer • You cannot dispatch a LiveKit agent directly into Google Meet. LiveKit agents join LiveKit rooms only. • For a quick, reliable voice-only demo, the simplest approach is to host the call on LiveKit and dispatch the agent into that LiveKit room. • If you must use Google Meet, the only practical option is a media bridge: run a programmatic participant that joins Meet and relays audio to/from a LiveKit room (more complex and brittle). Recommended approach for a clean demo (best balance of speed, reliability, and control) 1. Host the demo in a LiveKit room. 2. Dispatch your agent to that room (agent dispatch API or token-based dispatch). 3. Have demo participants join the LiveKit room from their browsers or phones using a room-join token; their devices capture mic audio and play the agent’s TTS audio. 4. The agent handles STT → LLM → TTS and communicates by voice only. Benefits • No bridging complexity or extra latency. • Full control over agent behavior, logging, and permissions. • Easy to reproduce for multiple participants and demos. Minimal architecture (LiveKit-based demo) • Server: issues room-join tokens and triggers dispatch (or includes RoomAgentDispatch in the token). • Agent: deployed via LiveKit Agents; reads job metadata and joins the room to process audio. • Client: simple web page using LiveKit Web SDK to join the room, capture mic, and play audio. Example flows I can provide • Server: Python snippet to dispatch agent + generate a client room token. • Client: Minimal browser example (LiveKit Web SDK) that joins the room and uses microphone. • Agent: Sample entrypoint showing how it reads

ctx.job.metadata

and responds with TTS. Advanced option (if you must use Google Meet) • Build a bridge: ◦ A headless browser or VM joins Google Meet as a participant. ◦ That device forwards Meet audio into a LiveKit room where the agent is dispatched. ◦ The agent’s TTS audio is captured and played back into Meet from the bridging device. • Tradeoffs: higher latency, more engineering, possible Terms-of-Service concerns, fragile for demos. Next step Which example would be most useful right now? • A ready-to-run server script (dispatch + token generation) + minimal browser client to join and talk to the agent, or • A sketch of the bridging prototype for Google Meet (architecture + tool suggestions)? Tell me which one and I’ll provide the code and steps. Sources: Agent server overview | LiveKit Documentation | Agent dispatch | LiveKit Documentation | OpenAI and LiveKit partner to turn Advanced Voice into an API | LiveKit | Gemini Realtime Agent with Live Vision | LiveKit Documentation | Yeah, but can it run DOOM? | LiveKit