Enable alternate providers

Overview

Loom currently deploys agents to a single target: AWS Bedrock AgentCore. Every stage of the deployment lifecycle — artifact packaging, runtime creation, endpoint creation, updates, deletion, and registry publication — is hardwired to boto3 calls against bedrock-agentcore-control and AgentCore-specific artifact/runtime conventions (a zip uploaded to S3, PYTHON_3_13 runtime, opentelemetry-instrument src/handler.py entrypoint, AgentCore ARNs). Add support for deploying agents to alternate agent platform providers — e.g. Databricks, Salesforce Agentforce, Anthropic Managed Agents, OpenAI Frontier — so builders are not locked into AWS as the only deployment target.

This is distinct from the existing provider field on agent/model config (see agents/strands_agent/src/config.py, AgentRegistrationForm.tsx), which selects the LLM model provider (bedrock/openai/anthropic/litellm) used inside an agent. This issue is about the deployment platform the agent itself runs on and is managed by.

Context

Current State

• backend/app/services/deployment.py is a thin, AWS-only wrapper with no provider abstraction:
  • build_agent_artifact() (L93-170) copies agents/strands_agent/src/, pip-installs requirements.txt targeting manylinux2014_aarch64/Python 3.13 (L125-139), zips the result, and uploads it to S3 (LOOM_ARTIFACT_BUCKET, L108, L163-166)
  • create_runtime() (L173-250) and update_runtime() (L358-427) call boto3.client("bedrock-agentcore-control") and hardcode "runtime": "PYTHON_3_13" and "entryPoint": ["opentelemetry-instrument", "src/handler.py"] (L218-229, L403-415)
  • create_runtime_endpoint() (L253-283) calls create_agent_runtime_endpoint on the same client
  • There is no factory/strategy seam anywhere in this file — every function assumes AgentCore
• backend/app/models/agent.py (L17-64) has no platform/provider column for the deployment target. Fields like arn, runtime_id, execution_role_arn, endpoint_name/endpoint_arn/endpoint_status are all AgentCore-shaped (the arn docstring hardcodes the AgentCore ARN format arn:aws:bedrock-agentcore:...)
• backend/app/routers/agents.py (4482 lines) calls the deployment.py helpers and also makes additional inline boto3.client("bedrock-agentcore-control") calls directly in route handlers (e.g. _deploy_agent_background L1062/1298/1459, _deploy_harness_background L2117 with inline calls at L2278/2343/2398, delete_agent L3031 with delete_runtime_endpoint/delete_runtime at L3149-3154) — there is no single chokepoint to intercept for an alternate platform
• backend/app/routers/registry.py and backend/app/services/registry.py wrap AWS Bedrock AgentCore's own Agent Registry feature (ARNs of the form arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}, registry.py L17-19). RegistryClient builds descriptors and pushes name/description/ARNs/status/approval state to the AWS registry service (router L150-289) — there is no generic, provider-agnostic metadata store to publish alternate-platform agents into
• IaC (shared/iac/role.yaml, shared/iac/infra.yaml, and related templates) provisions an IAM execution role trusted by bedrock-agentcore.amazonaws.com with inline bedrock-agentcore:* policies, plus generic hosting infra (S3 artifact bucket, KMS, ECR, ALB) for Loom's own frontend/backend. There is no separation between "provider-specific" and "generic" resources
• The frontend has no notion of a deployment-target/platform selector. DeploymentType = "custom" | "managed" (frontend/src/api/types.ts L173) only distinguishes self-managed AgentCore Runtime from harness-managed AgentCore — both still target AgentCore exclusively

Prior Precedent

The closed issue "Add support for alternate LLM providers" (tmp/archive/issues/074-alternate-llm-providers.md) solved an analogous but distinct problem — pluggable model providers — via an abstract Provider interface, concrete implementations per provider, a factory, and a registry of available providers/models. The same pattern-language (interface + factory + registry) is a reasonable starting point here, but the interface surface is different: instead of normalizing model invocation/streaming/token-usage, this issue needs to normalize artifact packaging and deployment lifecycle (create/update/delete/status) across heterogeneous platforms with very different packaging formats (zip-to-S3 vs. container image vs. platform-native bundle) and lifecycle semantics.

Key Files

• backend/app/services/deployment.py — all artifact build / runtime create/update/delete logic, 100% AgentCore/boto3
• backend/app/routers/agents.py — deploy/update/delete route handlers and background tasks; also contains inline AWS calls outside deployment.py
• backend/app/models/agent.py — Agent ORM model, no platform field
• backend/app/routers/registry.py, backend/app/services/registry.py — AWS-only registry publication
• shared/iac/role.yaml, shared/iac/infra.yaml — AWS-only IAM/infra provisioning
• frontend/src/components/AgentRegistrationForm.tsx, frontend/src/api/types.ts — deploy form and types, no platform selector
• agents/strands_agent/ — current custom-code implementation; packaging assumes a Python zip artifact, not a container or platform-native bundle

Technology Stack

• Current Deployment Target: AWS Bedrock AgentCore Runtime (Python 3.13, ARM64, zip-to-S3 artifact)
• Proposed Additional Targets: Databricks (Mosaic AI Agent Framework), Salesforce Agentforce, Anthropic Managed Agents, OpenAI Frontier (naming/APIs subject to each vendor's current offering at implementation time)
• Backend: Python, FastAPI, SQLAlchemy, SQLite
• Frontend: TypeScript, React, Vite, shadcn/ui, Tailwind CSS
• IaC: AWS CloudFormation / SAM (shared/iac/, backend/iac/, frontend/iac/)

Requirements

R1: Provider-agnostic artifact bundling

Support bundling deployment artifacts per the packaging specification of the target provider, rather than the current AgentCore-only zip-to-S3 format.

• Define a bundling interface (e.g. AgentPlatformProvider.build_artifact()) that each provider implementation satisfies, replacing the hardcoded logic in build_agent_artifact() (backend/app/services/deployment.py L93-170)
• Support at minimum: a zip/archive format (current AgentCore behavior, preserved unchanged for backward compatibility), a container image format (build + push to a registry, e.g. for Databricks/Agentforce style deployments), and any platform-native bundle format required by Anthropic Managed Agents / OpenAI Frontier once their packaging contracts are known
• Dependency resolution (pip install target platform/Python version, or equivalent for other runtimes) must be parameterized per provider rather than hardcoded to manylinux2014_aarch64/Python 3.13
• Existing AgentCore/Strands artifact bundling must continue to work unchanged — this is an additive abstraction, not a rewrite of the existing path

R2: Alternate provider deployment support

Support deploying agents to alternate agent platform providers alongside AWS Bedrock AgentCore.

• Add a platform (or similarly named) field to the Agent ORM model, deploy request/response types (backend and frontend), and the deploy form, defaulting to agentcore so existing behavior is unchanged when unset
• Implement provider-specific deployment classes (e.g. AgentCoreProvider, DatabricksProvider, AgentforceProvider, AnthropicManagedAgentsProvider, OpenAIFrontierProvider) behind a common interface, selected via a factory (mirroring the pattern in the closed alternate-LLM-providers issue, but for deployment lifecycle rather than model invocation)
• Each provider implementation owns its own authentication/credential handling (e.g. AWS IAM roles for AgentCore, API tokens/service principals for others), sourced from AWS Secrets Manager per existing conventions — no plaintext credentials in etc/environment.sh or checked-in config
• frontend/src/components/AgentRegistrationForm.tsx must expose a platform selector so builders can choose a deployment target at agent creation time; the rest of the form (model provider, MCP/A2A/memory integrations, tags) should remain platform-agnostic where the target platform supports equivalent capabilities, with unsupported capabilities clearly disabled/flagged per platform (see R5)

R3: Full lifecycle management across providers

Support create, update, and deletion of agents for every supported provider, matching the operational guarantees already provided for AgentCore.

• Each provider implementation must support: create (artifact build + deploy + endpoint creation, mirroring create_runtime()/create_runtime_endpoint()), update (mirroring update_runtime(), including redeploying artifacts and rotating endpoints), delete (mirroring delete_agent()'s cleanup of runtime, endpoint, and any provider-side resources), and status polling (mirroring get_runtime()/deployment_status)
• backend/app/routers/agents.py's deploy/update/delete route handlers must dispatch to the correct provider implementation based on the agent's platform field rather than calling deployment.py/inline boto3 calls unconditionally
• Failure modes must be handled consistently across providers: partial-deploy cleanup, timeout/retry behavior, and error surfacing to the frontend should not regress for AgentCore and should be defined (even if minimal) for each new provider
• Existing AgentCore lifecycle behavior (harness path included) must remain unchanged

R4: Registry integration for published resources

Integrate alternate-provider agents into Loom's registry alongside AWS Bedrock AgentCore Registry entries.

• Since backend/app/services/registry.py currently wraps AWS AgentCore's own Registry service exclusively, determine whether alternate-provider agents can be published into that same AWS registry as metadata-only records (no live AgentCore ARN), or whether a provider-agnostic registry/catalog needs to be introduced in Loom's own backend (e.g. a registry table keyed by (platform, external_id)) that AgentCore-backed records also migrate to
• Whichever approach is chosen, published records must carry enough platform-specific identifying information (ARN, Databricks endpoint ID, Agentforce agent ID, etc.) for downstream consumers (A2A/MCP discovery, approval workflows) to resolve and invoke the agent regardless of platform
• Existing registry search, approval (submit_for_approval/approve_record/reject_record), and descriptor-building behavior for AgentCore-backed agents must continue to work unchanged

Additional Considerations

• R5: Capability parity matrix — Providers will differ in which Loom features they can support (streaming SSE vs. WebSocket bidirectional invocation, MCP tool attachment, A2A interop, HITL/approval interrupts, memory integration, code interpreter). Document a per-provider capability matrix and ensure the frontend disables/flags unsupported capabilities per platform rather than silently failing at deploy or invoke time.
• R6: Invocation routing — backend/app/routers/invocations.py currently assumes an AgentCore invocation contract (SSE/WebSocket event shapes emitted by agents/strands_agent/src/handler.py). Alternate providers will have their own invocation APIs and event/response shapes; a normalization layer is needed so the existing chat/trace UI can consume responses uniformly regardless of platform.
• R7: Telemetry and cost tracking parity — OpenTelemetry spans (agent.invocation, tool.call, model.call) and cost tracking currently assume AgentCore/CloudWatch. Alternate providers may have their own telemetry/billing APIs (or none); define how trace and cost data is collected, normalized, and surfaced consistently in the existing traces/costs UI.
• R8: Credential and network model per provider — Each platform has its own auth model (IAM roles, OAuth client credentials, API tokens, service principals) and network reachability requirements (some providers may only be reachable over the public internet, not via VPC PrivateLink like AgentCore). IaC and backend/app/dependencies/auth.py-style credential handling need a per-provider extension point, following this project's existing SSRF-hardening and secrets-management conventions rather than introducing new unvalidated outbound calls.
• R9: IaC separation of generic vs. provider-specific resources — shared/iac/role.yaml and shared/iac/infra.yaml currently mix AgentCore-specific IAM policies with generic Loom hosting infra. Introduce a clear separation (e.g. per-provider IaC modules/parameters) so enabling a new provider doesn't require modifying the core stack, and so unused providers don't provision unnecessary AWS resources.
• R10: Migration/coexistence — Existing deployed agents have no platform value; migrations must backfill platform = "agentcore" for all existing rows, and mixed fleets (some agents on AgentCore, others on alternate providers) must be listable/manageable from the same UI without special-casing.

Testing

• Run backend tests: cd backend && make test
• Run frontend typecheck: cd frontend && npx tsc --noEmit
• Verify platform defaults to agentcore and existing AgentCore deployments, updates, and deletions are unaffected (regression)
• Verify artifact bundling produces the correct package format per provider, with no cross-contamination between provider-specific build logic
• Verify full lifecycle (create → update → delete) against at least one non-AgentCore provider implementation end-to-end, including error/cleanup paths on partial failure
• Verify registry publication for a non-AgentCore agent is discoverable and resolvable through existing search/approval flows
• Verify capability-gated UI: unsupported integrations for a given platform are disabled/flagged in AgentRegistrationForm.tsx, not silently accepted and dropped at deploy time
• Verify telemetry/cost data for a non-AgentCore invocation appears in the existing traces/costs UI in a form consistent with AgentCore-based agents

Out of Scope

• Committing to specific vendor SDKs/APIs for Databricks, Salesforce Agentforce, Anthropic Managed Agents, or OpenAI Frontier in this issue — those integrations are expected to be tracked and implemented as follow-on issues per provider once this abstraction lands
• Multi-platform composition (a single logical agent spanning multiple providers simultaneously)
• Migrating existing AgentCore-deployed agents to an alternate provider
• Changes to the LLM model provider abstraction (agents/strands_agent/src/config.py, closed issue 074-alternate-llm-providers.md) — this issue is strictly about the deployment/runtime platform, not the model backing an agent