Table of Contents
ToggleEnterprises building AI agents today face a critical bottleneck: getting agents from development into production reliably, securely, and at scale. Most teams cobble together fragmented CI/CD pipelines, manually manage deployments, and lack standardized approval workflows.
The result is slow iteration, inconsistent security posture, and agents that never make it past the proof-of-concept stage.
The Lyzr Control Plane solves this. It is the deployment infrastructure layer that provides a fully automated, no-touch pipeline to take agent code from any framework and deploy it to any supported cloud runtime, with security scanning, evaluation, identity registration, and staged promotion built in.
What Makes the Control Plane Different
Framework agnostic: Bring agents built with LangGraph, CrewAI, Strands, Lyzr SDK, or any custom framework.
Cloud agnostic: Deploy to AWS Bedrock AgentCore, GCP Vertex AI Agent Engine, or other supported runtimes.
Git-driven: Every deployment is triggered by code pushes and webhooks—version controlled and auditable.
Enterprise-grade: Built-in security scans, Responsible AI guardrails, agent simulation, Okta identity, and multi-environment promotion.
1. Agent Building
Lyzr provides a flexible path to bring agents into the platform, regardless of the framework used to build them.
External Agent Code Drop-In
For teams that have already built agents using any framework. The Control Plane accepts agent code from:
- LangGraph agents
- CrewAI multi-agent systems
- Strands agents
- Custom/proprietary agent code
Simply point the Control Plane to your repository, and it takes over from there—handling the entire deployment pipeline regardless of the framework used to build the agent.
This is what makes the Control Plane truly framework agnostic. You own the code, Lyzr handles the infrastructure.

Control Plane Dashboard, Agents from LangGraph, CrewAI, and other frameworks managed in one view
2. Git-Driven Workflow
Every agent deployment on the Control Plane is git-driven. This means:
- Agent code lives in a GitHub or Azure DevOps (ADO) repository
- Webhooks listen for pushes to non-prod and production branches
- Every code change triggers the full CI/CD pipeline automatically
- Version tags are created at every stage, providing a complete audit trail
- Rollbacks are as simple as reverting to a previous version tag
This approach ensures that agent deployments are fully version-controlled, auditable, and repeatable, the same standards enterprises apply to traditional software, now extended to AI agents.

Git-Driven Version History – Every deployment tracked by commit hash with Playground and Redeploy actions
3. Deployment
The deployment phase is the core of the Control Plane. It automates everything from cloning the repo to running the agent in production with full identity, monitoring, and evaluation. The pipeline supports multiple environments and includes rigorous CI/CD stages.

Control Plane — Complete CI/CD Pipeline Overview
3.1 Multiple Environments
The Control Plane enforces a staged promotion model with distinct environments:
| Environment | Purpose | Gating Criteria |
| Non-Prod (Dev/Staging) | Build, test, and evaluate agents before they touch production traffic | Stakeholder approval, environment readiness checks, security scans |
| Production | Serve live traffic with full identity, monitoring, and governance | All non-prod evaluations passed, PR approved and merged by configured approvers |
Agents are never deployed directly to production. They must pass through the non-prod pipeline, clear all evaluations, and receive explicit approvals before promotion.

Multi-Environment View — Agent deployed across preprod, prod, and dev branches on AWS
3.2 CI/CD Stages
The CI/CD pipeline covers the following stages in sequence:
Stage 1: Stakeholder Approval & Configuration
- Configured approvers from the deployment metadata must approve before the pipeline proceeds
- Deployment metadata (preset configuration bundle) is applied, covering tenant, repo URL, branch info, security settings, integrations, simulation config, and RAI guardrails
- An Environment Readiness Check validates the target environment: VPC/VNet accessibility, security groups, IAM roles, ECR/GCS access, quotas, and network connectivity

Deployment Configuration
Stage 2: Code Analysis & Build
- Git Clone: repository is cloned from the configured branch
- Static Code Analysis: prerequisite checks, security scans, and vulnerability assessments are run against the agent code
- Version Tag: a unique version tag is created for this deployment
- Build Agent Image: a container image is built for the agent
- Container Scan: the built image is scanned for vulnerabilities, security issues, and dependency risks
- Push to Registry: the scanned image is pushed to ECR (AWS) or equivalent container registry

Non-Prod Pipeline — Config → Environment Check → Clone → Build → Scan → Deploy
Stage 3: Deployment to Non-Prod Runtime
- The agent is deployed to the target cloud runtime (AWS Bedrock AgentCore or GCP Vertex AI Agent Engine)
- An automatic health check verifies the agent is responsive
- On success: the agent goes live in non-prod and all stakeholders are notified
- On failure: automatic rollback to previous version, error logging, self-healing attempts, and stakeholder notification

Live Deployment Logs with Pipeline stages
Stage 4: Identity Registration
- The agent is registered in the Non-Prod Agent Registry
- The agent receives a dedicated identity in the Non-Prod Okta tenant
Stage 5: Agent Simulation & Evaluation
This is the gate between non-prod and production. An automated evaluation suite runs against the live non-prod agent, covering:
- RAI Scans: Responsible AI policy compliance
- Hallucination Check: Factual accuracy validation
- Relevance & Correctness: Response quality metrics
- All evaluation data is captured and logged in the deployment run
If evaluations pass: a Pull Request is automatically created to the production branch with the configured approvers. The PR merge triggers the production pipeline.
If evaluations fail: all provisioned non-prod resources are cleaned up (AgentCore runtimes, ECR images, IAM roles, registry entries, Okta identities), errors are logged and analyzed, and changes are recommended back to the development team.
Stage 6: Production Deployment
Once the PR is merged, the production pipeline runs a streamlined deployment (the code was already validated in non-prod):
- Webhook triggers on merge to the production branch
- Production version tag is created
- Production container image is built
- Agent is deployed to the target cloud with the preset configuration bundle attached
- Health check confirms the agent is responsive
- Agent is registered in the Production Agent Registry
- Agent receives a Production Okta identity
- Agent is live and serving traffic
- All stakeholders are notified of the successful production deployment
If a production deployment fails, the system automatically rolls back to the previous production version, captures deployment logs, and alerts all stakeholders.

Evaluation Gate & Production Promotion — Non-Prod deploy → Agent Simulation → PR to Prod → Live in Production
4. Addition to the Agent Registry
Once an agent is deployed, it is automatically registered in the Lyzr Agent Registry, providing central discovery and identity-mapped governance across the enterprise.
4.1 Central Discovery
The Agent Registry serves as the single source of truth for all deployed agents across the organization. Teams can:
- Discover all agents currently running in non-prod and production environments
- View agent metadata including version, deployment status, framework, target runtime, and configuration
- Search and filter agents by team, function, department, or use case
- Track the full deployment history and version lineage of every agent
Think of the Agent Registry as your enterprise’s catalog of its AI workforce—every agent is tracked, versioned, and discoverable.

Agent Registry : Central catalog of all deployed agents with framework, cloud provider, and deployment status
4.2 Identity Mapped
Every deployed agent receives a dedicated identity via Okta integration:
- Each agent gets its own Okta identity in the appropriate environment (non-prod or production)
- Identity is tied to the agent’s entry in the Agent Registry, creating a unified view of what the agent is, what it can do, and how it authenticates
- This enables fine-grained access control, audit trails, and compliance reporting for every agent action
- When an agent is decommissioned or fails evaluation, its identity is automatically revoked and cleaned up
5. Key Features
5.1 Ease of Building
The Control Plane eliminates the boilerplate and DevOps overhead that traditionally slows down agent deployment:
- Drop in agent code from any framework, LangGraph, CrewAI, Strands, or custom, and the platform handles everything from there
- Pre-built agent templates provide ready-to-use scaffolding for common enterprise patterns, no need to start from scratch
- The template catalog is extensible: teams can create, approve, and publish new templates that become discoverable across the organization
- CI/CD pipelines are auto-generated when a template is selected, developers write agent logic, and the platform handles everything else
- Deployment metadata can be saved as Preset Configuration Bundles, making future deployments one-click repeatable
5.2 Version Controlled
Every aspect of the agent lifecycle is version-controlled:
- Agent code lives in GitHub or Azure DevOps repositories
- Every deployment creates a unique version tag for traceability
- Non-prod and production branches are managed separately with explicit promotion gates
- Rollbacks revert to the exact previous version tag, no guesswork
- Configuration bundles are versioned alongside the code, ensuring environment parity
- The full deployment history is preserved: who approved it, when it was deployed, what evaluations it passed, and what version is currently live
5.3 Orchestration with Platform-Agnostic Agents
The Control Plane is designed to work with agents regardless of how they were built or where they run:
- Agents built with LangGraph, CrewAI, Strands, Lyzr SDK, or custom code all follow the same deployment pipeline
- The Agent Registry provides a unified view across frameworks, you can see a LangGraph agent, a CrewAI agent, and a Lyzr agent side by side in the same catalog
- Multi-agent orchestration is supported natively: agents can collaborate, share context, and hand off tasks regardless of their underlying framework
- Integrations use standardized connector layers with MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols, ensuring interoperability
- When a SaaS tool changes its API, the connector layer updates automatically, agent workflows survive even as the enterprise stack evolves
5.4 Cloud Agnostic
Enterprises have invested in specific cloud providers, and the Control Plane respects that investment:
| Cloud Provider | Supported Runtime | Deployment Details |
| AWS | Bedrock AgentCore | Deploys container images via ECR, IAM roles for runtime access, CloudWatch for logging |
| GCP | Vertex AI Agent Engine | Deploys via Reasoning Engine, GCS for artifacts, Cloud Logging for observability |
| Others | Additional runtimes | The architecture is extensible to support additional cloud providers and on-premise deployments |

Cloud Provider Selection — Deploy to AWS Bedrock AgentCore or GCP Vertex AI Agent Engine
- Deployment configuration handles cloud-specific details (VPC, security groups, IAM roles, container registries) through the preset configuration bundle
- Teams can deploy the same agent to different clouds by switching the target runtime, the pipeline adapts automatically
- On failure, cleanup is cloud-aware: AWS resources (AgentCore, ECR, IAM, CloudWatch) and GCP resources (Reasoning Engine, deployed sources, Cloud Logging) are cleaned up independently
- Full data privacy and sovereignty, agents run within your cloud environment, not on shared infrastructure
Wrapping Up
Most enterprise agent initiatives don’t fail because of bad ideas, they stall because production is messy. Fragmented pipelines, unclear approvals, and missing guardrails slow everything down. What starts as a promising agent often never makes it to real users.
The Lyzr Control Plane changes that equation.
It brings structure to how agents move from code to production. Every deployment follows a defined path. Every change is tracked. Every agent is evaluated, approved, and identity-mapped before it goes live. No shortcuts, no guesswork.
Instead of stitching together infrastructure, teams focus on what actually matters, building agents that solve real business problems.
And when deployment becomes predictable, scaling stops being a bottleneck.
Ready to move beyond demos and actually ship agents?
Try Lyzr Agent Studio and see how agents go from code to production with a single, governed pipeline.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here