Agent Core service suite — what Layerup activates, what is optional, and what to bring to your governance board.
Amazon Bedrock AgentCore is a full suite of managed services, not a single product. When you deploy Layerup AI Agents into your private cloud using AgentCore as the execution environment, you are not activating the entire suite by default. This page defines each service in the suite, the Layerup default configuration, and the approval implications for customers whose internal cloud governance teams must approve each AgentCore component independently.This page is specifically relevant for customers deploying under Option 2 (Your Private Cloud). Customers using Option 3 (Layerup’s Cloud) do not need to manage AgentCore service activation — Layerup configures the runtime on your behalf in our dedicated tenant.
The four AgentCore services
AgentCore is composed of four distinct managed services. Each can be independently enabled or disabled. Layerup activates only what the workflow requires.| AgentCore service | what it does | Layerup default | approval implication |
|---|---|---|---|
| Runtime | Launches a session-isolated microVM for each agent case run. Manages scaling, provisioning, and deprovisioning of compute environments. Integrates natively with Bedrock Guardrails at the inference layer. | Always enabled | Required — no deployment without this |
| Memory | Provides short-term, multi-turn session context within a single case run. Allows the agent to maintain reasoning state across multiple inference calls for a single case without re-reading source documents on every step. | Enabled by default | Required for multi-step reasoning workflows; can be disabled on request |
| Gateway | Converts external APIs, AWS Lambda functions, and third-party services (Salesforce, Slack, ServiceNow, etc.) into MCP-compatible tools the agent can invoke directly during a case run. | Off by default | Only activated if your workflow requires live system reads during case processing |
| Identity | Manages agent authentication, agent-to-agent trust relationships, and access management for agent-level identities separate from your human IAM identities. | Off by default | Only activated for multi-agent orchestration deployments; not required for single-agent IDI or underwriting workflows |
What most underwriting deployments require
For the IDI underwriting workflow — and most claims and underwriting workflows — the active AgentCore services at go-live are:- Runtime (required)
- Memory (required for multi-step case reasoning)
Runtime — always required
Runtime is the execution substrate. Without it there is no AgentCore deployment — it is the component that provisions the isolated microVM, injects the container, and manages the full agent lifecycle from task receipt to task completion.
Memory — required for multi-step reasoning
IDI underwriting cases involve multiple sequential reasoning passes: occupation analysis, financial analysis, medical flagging, and cross-evidence synthesis. Memory maintains the agent’s working state across these passes within a single session without requiring the full document set to be re-passed on every inference call.
Gateway — conditional
Gateway is relevant if your workflow design requires the agent to make live API calls during case processing — for example, querying a real-time pharmacy claims database, calling a third-party IREX endpoint, or writing a status update to a CRM mid-case. For most deployments, these data sources are pre-loaded into S3 before the agent task starts, making Gateway unnecessary.
Identity — conditional
Identity manages trust between multiple agents in an orchestrated multi-agent system. It is not required for single-agent deployments. If your roadmap includes a multi-agent workflow — for example, an orchestrating triage agent delegating to specialist underwriting sub-agents — Identity would be activated at that stage.
Configuring the service scope
Your Layerup implementation team configures which AgentCore services are activated during the deployment engagement. The scope is defined in your deployment specification before any infrastructure is provisioned, so your governance team knows exactly what services will be active prior to go-live. If your internal cloud governance team has approved only a subset of AgentCore services — for example, Runtime and Memory but not Gateway or Identity — Layerup can configure the deployment to use exactly that subset. No services beyond the approved set will be activated.IAM implications by service
Each active AgentCore service carries its own set of IAM permission requirements. The following summarises the additional permissions each service adds to the agent’s execution role beyond the base set described in Identity, Access & AI Guardrails.| AgentCore service | additional IAM permissions required |
|---|---|
| Runtime | bedrock:InvokeAgent, bedrock:InvokeAgentRuntime (scoped to specific agent ARN) |
| Memory | bedrock:GetAgentMemory, bedrock:UpdateAgentMemory (scoped to session-specific memory store) |
| Gateway | bedrock:CreateAgentActionGroup, plus permissions for each downstream service the Gateway connects (e.g., lambda:InvokeFunction for Lambda-backed tools) |
| Identity | bedrock:CreateAgentAlias, bedrock:InvokeAgent across agent ARNs (for cross-agent delegation) |
security/iam plus the Runtime and Memory additions above. Gateway and Identity permissions are not added unless explicitly configured.
Activation timeline
AgentCore services are provisioned in your account during the Layerup deployment engagement. The sequence is:- Your governance team confirms which services are approved
- Your Layerup implementation engineer provides the per-service IAM policy documents and infrastructure-as-code (CloudFormation or Terraform) for your team to review
- Your cloud team applies the infrastructure changes in your account
- Layerup validates the service activation against the agreed manifest before any agent code is deployed