Everything you need to know about Lyzr Studio

What Lyzr Studio is

Lyzr is a full-stack agent infrastructure platform. Agent Studio is the visual layer where you build, test, deploy and monitor agents, and every agent you build is also an API.

Studio gives business users a no-code builder and gives engineers full programmatic control. Memory, knowledge bases and Responsible AI guardrails switch on per agent, and every published agent automatically exposes an OpenAPI 3.1 REST endpoint (plus gRPC stubs), so it can be dropped into existing services, multi-agent systems or protocols such as MCP and Google A2A.

The platform in five layers

The top three layers are where agents are built and run. The bottom two are the foundations every agent depends on.

What happens on every agent call

Safety is part of the request path, not a separate service you call. Each request moves through the same pipeline:

Core building blocks

An agent is a role, a goal and instructions, plus the capabilities you switch on. Everything in Studio, including multi-agent systems, is assembled from these pieces.

Agents

The agent is the fundamental unit. Its role, goal and instructions are the source of truth for behaviour, and its core features (memory, knowledge base, Responsible AI and so on) add capability. Agents are tested in the Playground, which supports multiple sessions, file uploads (PDF, DOCX, PPTX, Excel, images) with table and image extraction, and side-by-side model comparison with tokens and timings shown under each answer. You can also describe an agent in plain English to the Conversational Builder.

Models

Studio is model-agnostic, with ready-to-use models from OpenAI, Anthropic, Google, Amazon Bedrock, Groq, Perplexity, xAI, Mistral and Meta. Three capabilities matter most in production:

Memory

Memory lets agents stay coherent within and across conversations. Lyzr Cognis is the default production memory layer, with zero configuration, automatic updating of stale facts, and optional cross-session memory for the same user. The earlier Lyzr Memory keeps the last 10 messages verbatim and summarises older ones. You can also bring your own provider: Bedrock AgentCore Memory, Mem0, SuperMemory, Azure AI Foundry, or Vertex AI Memory Bank and Sessions.

Knowledge: three ways to ground an agent

Knowledge bases and graphs are also available as a service, so agents built on LangChain, Semantic Kernel or other frameworks can query the same knowledge without duplicating data.

Tools, Skills, Global Context and Structured Output

Orchestration and automation

Two ways to make agents work together, a choice of triggers to run them without a human, and Git to manage them like software.

Why SuperFlow is production infrastructure

• Durable execution. Every step is journaled. If the service restarts mid-run, execution resumes from the point of failure.
• Exactly-once side effects. A step that succeeded never runs again, so retries do not double-charge, double-email or re-fire API calls.
• Per-node retries with exponential backoff, and opt-in error edges that route permanent failures to a fallback or a human.
• Human-in-the-loop. Wait for Approval pauses a run durably, with typed approval forms validated server-side, so irreversible actions can be gated.
• Enterprise HTTP auth built in: Bearer, Basic, API key, OAuth2 client credentials, AWS SigV4, JWT and mTLS.
• Crash-safe schedules. Cron ticks are not missed and queued runs survive restarts. Flows are versioned.

Triggers

Agents and workflows can run on a schedule (minutes, hours, days, months or cron, with up to 10 retries and a configurable delay) or from a webhook (a dedicated endpoint secured by a regenerable secret key). Every run appears in an Executions dashboard with status and error reason.

Git for Agents

Connect any agent to GitHub or GitHub Enterprise and its configuration lives in a repository. Use branches for dev, staging and production (each with its own API key), promote through pull requests, enforce branch protection, and restore any commit in one click. Edits sync both ways between Studio and Git, giving you an audit trail for regulated change control.

Voice agents

Low-latency conversational agents you can put on a phone number, with the same knowledge and guardrail features as text agents.

Voice agents connect to Telnyx, Twilio or Plivo using your own accounts, support knowledge base retrieval, dynamic variables, pronunciation rules, Krisp noise cancellation and call recording. Every call produces a transcript with interruption tracking, handoffs and a technical event log.

Integrations and APIs

Studio connects to your data and tools, and every agent can be called from your own applications.

Data and vector stores

Interoperability

• MCP. Connect any MCP server by URL (API key or OAuth) and choose which actions each agent may use.
• A2A. Call agents built on other platforms (LangChain, CrewAI and others) from Lyzr agents and workflows by their A2A server URL.

Calling agents from your applications

Every agent is instantly deployable. Publish it in Studio with Private, Organization or Public visibility, and call it through its REST endpoint or the Python ADK.

POST https://agent-prod.studio.lyzr.ai/v3/inference/chat/
x-api-key: <YOUR_API_KEY>      # always server-side, never in frontend code
Content-Type: application/json

{
  "agent_id":   "<AGENT_ID>",
  "user_id":    "user@company.com",
  "session_id": "conv_abc123",
  "message":    "..."
}

The Deploy tab of every agent shows this request ready to copy, alongside the agent's A2A endpoint and its Agent JSON. How you set session_id and user_id decides what the agent remembers:

Platform architecture

Studio is a set of containerised microservices on Kubernetes. The service topology is the same everywhere it runs; only the substrate underneath changes.

Deployment models

Service topology

The sizing baseline is 16 services in two tiers. The current service catalogue is broader (20+ services, including Skills, the Simulation Engine, Agent Builder and background workers), so confirm the exact list for your version with Lyzr.

Reference architectures

Every cloud follows the same three-zone pattern: a public edge (WAF and load balancer), a private application subnet running the Lyzr services, and a private data subnet reachable only from the application tier. Pick a cloud to see its diagram; click any diagram to enlarge it.

Diagrams from Lyzr's Solutions Architecture reference designs. The diagrams show the full current service catalogue, which is wider than the 16-service sizing baseline above.

The same platform on every substrate

Tenancy and data separation

On Lyzr Cloud, Studio runs on shared multi-tenant infrastructure with logical tenant isolation. Dedicated per-tenant infrastructure or databases are not created by default.

The isolation boundary is the organisation ID

Every organisation and every sub-account gets a unique org_id, and every resource, user assignment and permission is mapped to it. A resource belongs to exactly one org_id, and a user's access is evaluated against the org they are operating in. Two sub-accounts under one parent are as separated from each other as two different companies.

Where each kind of data lives

When you need a stronger data boundary

• Bring your own data store. Connect your own vector database or PostgreSQL (or another supported vector-capable store) for knowledge base data, so that data stays in infrastructure you control.
• Bring your own model credentials. Inference runs against your provider account, for example Bedrock in your own region.
• Use your own OAuth apps for tools, so authentication and data access stay under your governance.
• Deploy privately. A VPC or on-prem deployment gives you dedicated infrastructure, databases and secret stores (chapter 12).
• Separate teams with sub-accounts inside your organisation (chapter 11).

Security and responsible AI

Guardrails run inside the inference loop on every turn. Policies are written once and attached to many agents, and changes apply from the next message.

Guardrail families

Prompt injection is scored before the question reaches the LLM (default threshold 0.3) and blocked above threshold. Toxicity is scored on the response (default 0.4); a toxic draft is sent back to the model for a safe alternative.

Compliance guardrails

Switch on Compliance in a policy, pick frameworks, and add plain-English custom rules with a severity. Both checks run at temperature 0 for consistent verdicts, and an audit record with trace spans is written for every check, whether or not anything fails.

• Block mode (default): HIGH or CRITICAL failures withhold the reply; LOW and MEDIUM failures are flagged.
• Flag mode: the reply is delivered and reviewers see the concerns with evidence quotes.
• A blocked input never reaches the model; it sees only the block notice.

Access, credentials and API security

• Role-based access with Owner, Admin and Member roles. Only Owners and Admins manage models and data connectors.
• Audit log of every platform action, filterable by date, user, action (read, delete, access denied, export), resource type and result.
• Tool credentials are held in Lyzr's secure store on SaaS, or in your own infrastructure for private deployments. Custom OAuth apps keep authentication under your governance.
• API keys must be sent server-side only, never from frontend code. Webhook endpoints are protected by regenerable secret keys.
• Memory scope. Per-conversation memory is the default and the more privacy-friendly option; enable cross-session memory deliberately.

In a private deployment

Secrets live in your cloud's secret manager or HashiCorp Vault and are mounted through the Secrets Store CSI driver with rotation enabled on AWS. Services authenticate to cloud resources with workload identity (Pod Identity, Managed Identity, Workload Identity Federation) instead of long-lived keys. Data stores are reachable only on private endpoints, ingress is TLS-terminated behind a WAF, and customer-managed encryption keys are supported on AWS, Azure and GCP. On GKE and bare-metal, namespaces run with default-deny network policy and restricted Pod Security Standards.

Scaling and availability

Studio scales in two layers on EKS. KEDA adds and removes pods per service based on load, and the Cluster Autoscaler adds nodes when new pods cannot be scheduled.

Pod autoscaling

Every enabled HTTP service gets a KEDA ScaledObject, and KEDA creates and manages the HPA behind it (a plain HPA is used only when a service opts out; the two are never combined on one Deployment). When several triggers are active, the one asking for the most pods wins.

KEDA's cooldown is 60 seconds for services. ArgoCD ignores replica counts on Deployments, so a GitOps sync never resets what the autoscaler has set.

Node autoscaling

Node capacity comes from the EKS Cluster Autoscaler on managed node groups. When a new pod does not fit on any node it waits as Pending until a node is added. Pods can run on any node unless a node selector is configured.

Availability guards

Resilience above the infrastructure

• Model fallback across up to three providers keeps agents answering through a provider outage or rate limit.
• Durable SuperFlow execution resumes after restarts without re-running completed steps.
• Queue-driven workers for parsing, crawling and knowledge base sync absorb bursts without slowing the chat path.
• Rate limits protect shared capacity from spikes and abuse (chapter 11).

Observability and lifecycle

Test before production, watch after, and keep every change reversible.

Owners and Admins can download organisation-wide reports in Excel by agent (runs, credits, tokens, latency, error rate) or by user. In private deployments, logs, metrics and traces flow into your own stack through OpenTelemetry and the native monitoring service for your cloud, or Prometheus, Grafana and Loki on-prem.

Governance and cost control

Organise teams into isolated workspaces, give people the right roles in each, and cap spend at every level.

Roles

Sub-accounts

Sub-accounts split one organisation into separate workspaces, typically one per team, department, client or project. Each has its own org_id, and its agents, knowledge bases, tools, skills, users, roles and usage stay inside it. A person can be an Admin in one sub-account and a Member in another, and a role in one confers no access in any other. Sub-accounts are enabled on request.

Rate limits

Set token or credit limits over any window (hourly, daily, weekly, monthly or custom) at four levels. Limits cascade, so a user cannot exceed their team's limit even if the organisation has quota left. When a limit is hit, requests fail cleanly with a quota-exceeded response.

How usage is metered

Usage is metered in credits, where one credit equals one dollar. Model usage is token count (prompt plus response, including instructions and retrieved context) multiplied by a per-model rate. Tool calls cost a fixed amount per invocation, memory is free, and guardrails and groundedness checks add cost based on the modules used. Auto-routing and lighter models are the main levers for keeping cost down.

Deploying in your VPC or on-prem

Installing the software is rarely the long pole. Network, identity and security approvals are, so they should start on day one, in parallel with provisioning.

What your teams will evaluate

The deployment sequence

Indicative only. Adjust to your own change-control cadence, especially for network and identity approvals.

AWS prerequisites at a glance

• EKS 1.35 with the OIDC provider and the EKS Pod Identity Agent add-on enabled (Pod Identity is used, not IRSA).
• System nodes 2 × m5.large; app nodes 2 to 20 × m5.large with autoscaling.
• Add-ons: AWS Load Balancer Controller, Secrets Store CSI Driver, AWS Secrets and Config Provider, KEDA, Metrics Server, Cluster Autoscaler.
• Secrets Manager entries for shared and per-service secrets, ECR repositories, SQS queues, S3 buckets, an ACM wildcard certificate and wildcard DNS to the ALB.

helm install lyzr-studio ./chart/lyzr-studio \
  -f ./chart/lyzr-studio/values.yaml -f ./values-<env>.yaml \
  --namespace lyzr-studio --timeout 10m

On-premises sizing reference

About 108 vCPU and 416 GiB in total, with roughly 2× headroom over steady state. On-prem LLM inference needs a separate GPU sizing exercise. See Fig 6.4 in chapter 06 for how the pools fit together.

Things to line up early

• Firewall and proxy changes usually go through change control and can take weeks.
• Secrets. Services need many per-service keys; have your secrets and IAM team ready to provision them before install.
• Model access. Confirm whether outbound calls to public model APIs are allowed, and choose an in-region or self-hosted fallback if not.
• Identity mapping of directory groups to roles often involves a separate IAM queue.
• Written success criteria, agreed with security and architecture as well as the business sponsor.

Getting started checklist

A suggested path through your first weeks. Tick items as you go; your progress is saved in this browser.

• Sign in at studio.lyzr.ai and copy an API key from Account and API Keys
• Build and test a first agent with a knowledge base in the Playground
• Add your own model credentials and configure fallback models
• Create a Responsible AI policy with PII, prompt injection and the compliance frameworks you need, and attach it
• Call the agent from your backend over the REST API or ADK, with session_id and user_id
• Set up roles, sub-accounts and rate limits for your teams
• Run a Simulation Engine evaluation before going live
• Connect the agent to Git and set up a non-prod branch
• Decide on SaaS or private deployment, and if private, start the network and identity requests

Resources