> ## Documentation Index > Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt > Use this file to discover all available pages before exploring further. # Multi-Line Deployment > How to deploy Layerup AI Agents across multiple lines of business — IDI, Life, Group Disability, and others — within a single deployment, with complete per-line data isolation, independent AOP configuration, and shared compute efficiency. # Multi-line deployment — per-line isolation with shared compute infrastructure. Organizations deploying Layerup AI Agents across multiple lines of business — for example, IDI underwriting and Group Life simultaneously — do not need a separate deployment per line. A single deployment supports multiple workflow configurations with complete data isolation between lines, independent AOP versioning per line, and separate IAM roles scoped exclusively to each line's storage and queuing resources. This page describes the multi-line isolation model, when to use one deployment vs. multiple, and how per-line independence is enforced in both Option 2 (private cloud) and Option 3 (Layerup's Cloud). *** ## The isolation model Each line of business within a single deployment receives its own independent set of infrastructure resources. Compute is shared — the same agent container image handles all lines — but every data, queuing, and configuration resource is scoped exclusively to one line. | resource | per-line | shared | notes | | ----------------------------- | -------- | ------ | -------------------------------------------------------------------------------------------------------------- | | **S3 input bucket** | Yes | — | Line A cannot read or write Line B's documents | | **S3 output bucket** | Yes | — | Line A cannot read or write Line B's output | | **SQS intake queue** | Yes | — | Cases submitted to Line A never appear in Line B's queue | | **SQS completion queue** | Yes | — | Completion events are routed to the correct line's downstream system | | **IAM execution role** | Yes | — | Each line's agent task runs under a role scoped only to that line's buckets and queues | | **Agent Operating Procedure** | Yes | — | Each line has its own AOP file; an IDI AOP update has no effect on the Group Life AOP | | **CloudWatch Log Group** | Yes | — | Audit logs are separated by line; compliance review for one line does not expose another line's cases | | **Agent container image** | — | Yes | Same image version runs all lines; no line-specific logic is in the image — all line specificity is in the AOP | | **Bedrock model endpoint** | — | Yes | A single Bedrock model deployment handles inference for all lines within the cluster | | **ECR repository** | — | Yes | One image version applies to all lines simultaneously | *** ## Architecture diagram — two lines in one deployment ```mermaid theme={null} flowchart TB subgraph vpc ["Your VPC — Private Subnets"] subgraph compute ["Shared Agent Compute Layer"] AGT[Agent Container\nBedrock AgentCore Runtime\nShared across all lines] BDR[Bedrock VPC Endpoint\nShared model deployment] end subgraph idiLine ["IDI Underwriting — Isolated Resources"] IDI_SQS_IN[SQS Intake\nidi-intake] IDI_SQS_OUT[SQS Completion\nidi-completion] IDI_S3_IN[S3 Input\nidi-input-bucket] IDI_S3_OUT[S3 Output\nidi-output-bucket] IDI_IAM[IAM Role\nidi-execution-role\nScoped to IDI resources only] IDI_AOP[AOP v2.4.1\nIDI underwriting rules] IDI_CWL[CloudWatch\nidi-audit-logs] end subgraph lifeLine ["Group Life — Isolated Resources"] LIFE_SQS_IN[SQS Intake\nlife-intake] LIFE_SQS_OUT[SQS Completion\nlife-completion] LIFE_S3_IN[S3 Input\nlife-input-bucket] LIFE_S3_OUT[S3 Output\nlife-output-bucket] LIFE_IAM[IAM Role\nlife-execution-role\nScoped to Life resources only] LIFE_AOP[AOP v1.2.0\nGroup Life underwriting rules] LIFE_CWL[CloudWatch\nlife-audit-logs] end end subgraph sources ["Your Systems"] IDI_WS[IDI Workbench\nor Dashboard] LIFE_WS[Life Submission\nSystem] end IDI_WS -->|"submit case"| IDI_SQS_IN IDI_SQS_IN -->|"trigger — IDI role"| AGT AGT -->|"reads IDI AOP"| IDI_AOP AGT -->|"reads docs"| IDI_S3_IN AGT -->|"inference"| BDR AGT -->|"writes output"| IDI_S3_OUT AGT -->|"completion"| IDI_SQS_OUT AGT -->|"audit"| IDI_CWL LIFE_WS -->|"submit case"| LIFE_SQS_IN LIFE_SQS_IN -->|"trigger — Life role"| AGT AGT -->|"reads Life AOP"| LIFE_AOP AGT -->|"reads docs"| LIFE_S3_IN AGT -->|"writes output"| LIFE_S3_OUT AGT -->|"completion"| LIFE_SQS_OUT AGT -->|"audit"| LIFE_CWL classDef boundary fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111; classDef store fill:#f4f4f2,stroke:#111,color:#111; class vpc,compute,idiLine,lifeLine,sources boundary; class IDI_SQS_IN,IDI_SQS_OUT,IDI_S3_IN,IDI_S3_OUT,IDI_CWL store; class LIFE_SQS_IN,LIFE_SQS_OUT,LIFE_S3_IN,LIFE_S3_OUT,LIFE_CWL store; ``` *Fig. ML1.1 — Two lines (IDI Underwriting and Group Life) deployed within a single VPC. Shared agent compute handles both lines; all data, queuing, IAM, AOP, and audit resources are fully isolated per line. A case submitted to the IDI intake queue can only access IDI S3 buckets — the IAM execution role enforced by AWS prevents any cross-line data access.* *** ## How per-line IAM isolation is enforced Each line's agent task is launched with a distinct IAM execution role. The role's resource-level policy scopes every permission to that line's specific AWS resource ARNs: ```json theme={null} { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::your-org-idi-input-bucket/*" } ``` The IDI execution role cannot read from `your-org-life-input-bucket/*` — this is denied at the AWS IAM layer, not by application logic. Even if the agent were compromised or misconfigured, it cannot access another line's data because the IAM boundary is enforced by AWS independently of the agent software. The SQS queue URL is passed to each agent task as an environment variable at launch. A task launched from the IDI intake queue receives only the IDI queue URL — it has no knowledge of other queues' URLs. *** ## AOP independence per line Each line maintains its own Agent Operating Procedure in your source control system. AOP files are stored independently and versioned independently: ``` aop/ idi-underwriting/ aop-v2.4.1.json ← IDI AOP — current production version aop-v2.5.0-draft.json ← IDI AOP — under review group-life/ aop-v1.2.0.json ← Group Life AOP — current production version group-disability/ aop-v0.9.0.json ← Group Disability — staging, not yet in production ``` An AOP promotion for IDI does not trigger any change to the Group Life AOP. Your underwriting governance teams for each line operate independently. The CI/CD test harness runs the AOP validation suite per-line — a failing IDI AOP change does not block a Group Life AOP promotion. *** ## Rollout independence per line Lines can be at different rollout phases simultaneously. Rollout phase (Shadow, Assist, Auto-resolve, Full deployment — see [CI/CD Pipeline](/agents/lifecycle/cicd)) is configured per line: | line | rollout phase | human review model | | ---------------- | ------------------------ | --------------------------------------------------------------- | | IDI Underwriting | Phase 3 — Broad Rollout | Spot-check for high-confidence; full review for escalated cases | | Group Life | Phase 1 — Limited Live | 100% human review of agent output | | Group Disability | Phase 0 — POC Validation | Historical cases only; no live applications | This independence means a mature line does not need to wait for a newer line to reach its phase before expanding. Each line's phase transition is governed by that line's agreement rate data and approved by that line's underwriting leadership. *** ## When to use separate deployments instead A single multi-line deployment is the right choice for most organizations. The exception cases where separate deployments are appropriate: | scenario | recommendation | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Regulatory mandate requiring physically separate compute per line | Separate deployments — each line gets its own VPC, compute, and ECR | | Lines in different AWS regions for data residency reasons | Separate deployments per region | | Separate IT ownership — different teams manage different lines and cannot share a deployment account | Separate deployments with separate AWS accounts | | Separate vendor contracts per line requiring independent SLAs | Discuss with your Layerup implementation engineer — may be addressable within a single deployment | Separate deployments are fully supported. The cost is duplicated infrastructure provisioning, separate image update cadences, and separate deployment engagement scopes. For most organizations deploying 2–5 lines, a single multi-line deployment is significantly more efficient. *** ## Adding a new line to an existing deployment Adding a line to an existing deployment does not require redeploying the agent container. The process is additive: 1. Your Layerup implementation engineer delivers the new line's AOP file to your source control 2. Your infrastructure team provisions the new line's S3 buckets, SQS queues, IAM role, and CloudWatch Log Group using the same CloudFormation / Terraform template used for the first line (with line-specific resource names) 3. The new line's intake queue is registered with the agent compute layer as an additional trigger source 4. Your team runs Phase 0 (POC validation) on the new line before any live cases are processed No downtime is required for existing lines when a new line is added.