2 — Infrastructure provisioning & compute runtimes — container delivery, security scanning & execution environments.
This section details the specific compute components required to run Layerup AI Agents at scale, and the compatibility of those components with your existing cloud-native infrastructure standards. It is addressed to Platform Engineering and Cloud Architecture teams.2.1 Container image delivery and private registry integration
Layerup AI Agents are packaged as a standard Open Container Initiative (OCI)-compliant Docker container image. This is an industry-standard artifact format — compatible with any enterprise container registry and runtime your organisation already operates.2.1.1 AWS: Amazon Elastic Container Registry (ECR)
The delivery sequence for AWS environments:- Your AWS Marketplace subscription triggers delivery of the signed Layerup container image to a designated ECR repository within your own AWS account.
- The image is tagged with a semantic version (e.g.,
layerup-ai-agent:1.4.2) for full traceability across environments. - ECR repository policies are configured by your team to allow access only from IAM roles within your account. Layerup retains zero access to the repository after image delivery.
- Amazon ECR automatically replicates the image across your chosen AWS regions for high availability and disaster recovery compliance.
2.1.2 Azure: Azure Container Registry (ACR)
The equivalent delivery sequence for Azure environments:- The Azure Marketplace offer delivers the signed image to your private Azure Container Registry (ACR) instance.
- Azure Defender for Containers continuously scans all images in ACR for known CVEs from the moment of delivery.
- Images are stored with geo-replication enabled across your designated Azure regions, maintaining data residency requirements at the registry layer.
- ACR Access Tokens restrict pull access to specific managed identities assigned to your agent compute instances — no external principal can pull the image.
2.2 Pre-deployment security scanning — no image enters production unscanned
Before any container image version is promoted to your production compute environment, it must pass your existing automated vulnerability scanning pipeline:| cloud | scanning tool | behaviour |
|---|---|---|
| AWS | Amazon Inspector | Automatically initiates a vulnerability assessment when a new image version lands in ECR. Evaluates against known CVE databases, checking all OS packages and application dependencies. Images failing defined severity thresholds are quarantined and cannot be deployed to production without a documented exception approval. |
| Azure | Microsoft Defender for Cloud | Continuously monitors images in ACR and running containers in AKS or Container Apps for emerging vulnerabilities. Surfaces findings directly in your Microsoft Defender portal. |
| Custom CI/CD Gates | Jenkins · Azure DevOps · GitHub Actions | Your internal CI/CD pipelines can impose additional quality gates before a Layerup image version is approved for production deployment. These gates may include SAST/DAST scans, SBOM validation, and sign-off approvals from your security team. |
Layerup also provides a signed SBOM in CycloneDX or SPDX format for every released image version. Your security team can validate the SBOM against the image digest before it enters your registry. See 4 for full supply chain security documentation.
2.3 Agent execution environments
Your Platform Engineering team selects the execution environment that best fits your existing infrastructure standards. Three options are supported.2.3.1 AWS Option A: Amazon Bedrock AgentCore Runtime (recommended)
Amazon Bedrock AgentCore Runtime (released early 2026) is AWS’s native, purpose-built execution environment for AI agents. It is the recommended runtime for Layerup AI Agents on AWS for the following reasons:Session-Isolated microVMs
AgentCore Runtime launches a lightweight, isolated microVM for each agent session. Each application case processed by the agent runs in its own isolated execution environment. Memory, context, and intermediate reasoning states cannot be accessed across sessions — critical for ensuring that the context of Applicant A’s case does not contaminate the reasoning for Applicant B’s case.
Framework Agnostic
AgentCore Runtime is framework-agnostic. The Layerup agent deploys without requiring any AWS-specific SDK rewrites. The container simply executes within the runtime — your existing container operational model applies.
Managed Scaling
AgentCore Runtime automatically provisions and deprovisions microVMs in response to workload. During high-volume intake periods, the runtime scales horizontally without your team needing to pre-provision capacity or manage EC2 instance fleets.
Native Bedrock Guardrails Integration
The runtime natively integrates with Amazon Bedrock Guardrails, applying your configured compliance policies at the model inference layer before the agent can take any action. There is no additional integration work required to enable this layer.
2.3.2 AWS Option B: Amazon ECS with Fargate
For teams with existing ECS-based container orchestration, the Layerup agent can alternatively be deployed to Amazon ECS using the Fargate serverless compute engine:- No EC2 Instance Management: Fargate eliminates the need to provision or patch underlying EC2 instances. Your team defines the CPU and memory requirements for each agent task; Fargate provisions the compute dynamically.
- Task Isolation: Each ECS Task definition for the Layerup agent runs in its own isolated compute environment with a separate network interface and IAM task role.
- ECS Service Auto Scaling: Application Auto Scaling policies on the ECS service allow you to scale concurrent agent tasks horizontally based on SQS queue depth (i.e., the number of pending application packets awaiting processing).
- Existing ECS Integration: If your existing AI platform team already manages workloads on ECS, the Layerup agent slots into that operational model without introducing new tooling or operational overhead.
2.3.3 Azure Option: AKS or Azure Container Apps
On Azure, your team deploys the Layerup agent container using either of the following orchestration layers, depending on your existing platform standards:- Azure Container Apps (ACA): The lower-operational-overhead option. ACA provides a fully managed serverless container platform that handles scaling, load balancing, and service discovery automatically. Recommended for teams that prefer a managed abstraction over raw Kubernetes. KEDA (Kubernetes Event-Driven Autoscaling) on Container Apps scales agent instances directly off Azure Service Bus queue depth.
- Azure Kubernetes Service (AKS): For teams that already operate AKS clusters, the Layerup agent is deployed as a Kubernetes
Deploymentresource with a correspondingHorizontalPodAutoscaler. Your existing Kubernetes RBAC, NetworkPolicies, OPA/Gatekeeper policies, and namespace isolation apply natively to the agent pods. - In both cases, inference calls are routed to your securely managed Azure OpenAI endpoints within your Azure AI Foundry hub, governed by Azure AI Content Safety filters configured by your team.
2.4 Compute scaling and session concurrency
Layerup AI Agents process each application case asynchronously. A typical case requires between 7 and 55 minutes of reasoning time, depending on document volume and complexity. The following scaling model ensures intake volumes are handled efficiently regardless of concurrent load.| scenario | performance characteristic |
|---|---|
| Simple case (<10 documents) | 7–12 minutes of processing time |
| Standard case (10–50 documents) | 12–20 minutes of processing time |
| Complex case (50+ documents, large MIB / Rx history) | 20–55 minutes of processing time |
| Maximum observed processing time | ~55 minutes (hundreds of MB of documents across all channels) |
| Concurrency | Unlimited parallel cases — each case runs in an independent isolated session |
| AWS scaling trigger | SQS queue depth — target: fewer than 5 pending tasks per active agent instance |
| Azure scaling trigger | Azure Service Bus queue depth — KEDA scaling rule on the Container Apps environment |
The asynchronous, queue-driven processing model means that peak intake events do not degrade processing quality. New agent instances are provisioned within seconds of queue depth rising above threshold. When the queue drains, instances are de-provisioned automatically — you pay only for compute consumed during active processing.