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

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:

{
  "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) 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:

Your Layerup implementation engineer delivers the new line’s AOP file to your source control
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)
The new line’s intake queue is registered with the agent compute layer as an additional trigger source
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.

Foundations

Deployment Architecture

Security & Governance

Data & Integration

Observability & Resilience

Configuration & Lifecycle

Confidence & Scoring

Reference

Multi-Line Deployment

Multi-line deployment — per-line isolation with shared compute infrastructure.

The isolation model

Architecture diagram — two lines in one deployment

How per-line IAM isolation is enforced

AOP independence per line

Rollout independence per line

When to use separate deployments instead

Adding a new line to an existing deployment

​Multi-line deployment — per-line isolation with shared compute infrastructure.

​The isolation model

​Architecture diagram — two lines in one deployment

​How per-line IAM isolation is enforced

​AOP independence per line

​Rollout independence per line

​When to use separate deployments instead

​Adding a new line to an existing deployment

Multi-line deployment — per-line isolation with shared compute infrastructure.

The isolation model

Architecture diagram — two lines in one deployment

How per-line IAM isolation is enforced

AOP independence per line

Rollout independence per line

When to use separate deployments instead

Adding a new line to an existing deployment