Add alternate agent frameworks

[heeki]

Add alternate agent frameworks

Overview

Expand the types of agents that builders can create by integrating additional agent frameworks alongside the existing Strands Agents SDK. Builders should be able to select an agent framework during creation — defaulting to Strands for general-purpose agents, with LangChain Deep Agent for deep research workflows and OpenDevin for coding agent use cases. Each framework should have its own agent source directory, deployment artifact, and runtime configuration while sharing the same AgentCore deployment pipeline.

Context

Current State

• All agents use a single implementation: agents/strands_agent/ — there is no framework selection mechanism
• The agent source is a static template that is copied and zipped by build_agent_artifact() in deployment.py (lines 93-170), which hardcodes the path to agents/strands_agent/src/
• Agent customization is entirely configuration-driven via the AGENT_CONFIG_JSON environment variable (system prompt, model ID, integrations) — no code generation or templating occurs
• The entry point is fixed: ["opentelemetry-instrument", "src/handler.py"] using BedrockAgentCoreApp from the bedrock-agentcore SDK
• The Agent ORM model (backend/app/models/agent.py) has no agent_framework or agent_type field
• The frontend AgentRegistrationForm.tsx has no framework selector — the deploy form collects name, description, system prompt components, model, role, network mode, and tags
• The AgentDeployRequest type has no framework field
• Dependencies are installed for manylinux2014_aarch64 / Python 3.13 targeting AWS AgentCore runtime

Key Files

• agents/strands_agent/ — Current single agent implementation directory
  • src/handler.py — HTTP entry point using BedrockAgentCoreApp
  • src/agent.py — Builds Strands Agent from config (model, tools, hooks)
  • src/config.py — Configuration dataclasses (AgentConfig, IntegrationsConfig)
  • requirements.txt — Dependencies: strands-agents[a2a], strands-agents-tools, bedrock-agentcore, mcp
• backend/app/services/deployment.py — build_agent_artifact() (hardcoded to agents/strands_agent/), create_runtime()
• backend/app/routers/agents.py — _deploy_agent() pipeline, SUPPORTED_MODELS list, AgentDeployRequest
• backend/app/models/agent.py — Agent ORM model (no framework field)
• frontend/src/components/AgentRegistrationForm.tsx — Deploy form UI
• frontend/src/api/types.ts — AgentDeployRequest, AgentResponse TypeScript types

Technology Stack

• Agent Runtime: AWS Bedrock AgentCore (Python 3.13, ARM64)
• Current Framework: Strands Agents SDK (strands-agents)
• Backend: Python, FastAPI, SQLAlchemy, SQLite
• Frontend: TypeScript, React, Vite, shadcn/ui, Tailwind CSS
• Packaging: pip install to temp dir, zip, upload to S3

References

• Strands Agents SDK: existing implementation in agents/strands_agent/
• LangChain Deep Agent: https://docs.langchain.com/oss/python/deepagents/overview
• OpenDevin: https://github.com/AI-App/OpenDevin.OpenDevin

Requirements

R1: Strands Agents SDK as default framework

Users who do not require specific customizations should continue using the Strands Agents SDK. The existing experience should remain unchanged when no alternate framework is selected.

• Add an agent_framework field to the Agent ORM model with a default value of strands — backfill existing agents with this value via a migration or default
• Add an agent_framework field to AgentDeployRequest (backend) and AgentDeployRequest (frontend types) with a default of strands
• Add a framework selector to AgentRegistrationForm.tsx (e.g. a dropdown or radio group) that defaults to "Strands Agent"
• When strands is selected, the deploy form should behave exactly as it does today — same fields, same system prompt components, same model selection, same deployment flow
• build_agent_artifact() should accept a framework parameter and route to the correct agent source directory (e.g. agents/strands_agent/ for Strands)
• The existing agents/strands_agent/ directory, handler, agent builder, and config should remain unchanged

R2: LangChain Deep Agent framework

Users who want to create a deep research agent should be able to select LangChain's Deep Agent framework.

• Create a new agent source directory agents/langchain_deep_agent/ with:
  • src/handler.py — Entry point compatible with BedrockAgentCoreApp (same HTTP contract as Strands handler)
  • src/agent.py — Builds a LangChain Deep Agent from configuration
  • src/config.py — Configuration dataclasses appropriate for Deep Agent (system prompt, model, research depth, etc.)
  • requirements.txt — Dependencies including langchain, Deep Agent packages, and bedrock-agentcore
• The handler must implement the same streaming response interface (async generator yielding events) so it works with the existing SSE invocation pipeline in invocations.py
• Add langchain_deep as a framework option in the frontend selector with label "LangChain Deep Agent"
• When langchain_deep is selected, the deploy form should show relevant configuration fields — at minimum: name, description, system prompt, and model selection
  • Additional Deep Agent-specific fields (e.g. research depth, tool configuration) can be added if the framework supports them
• Update build_agent_artifact() to package agents/langchain_deep_agent/ when the framework is langchain_deep
• Update create_runtime() to set the correct entry point for the Deep Agent handler
• The AGENT_CONFIG_JSON environment variable pattern should be reused for configuration injection, with a schema appropriate for the Deep Agent

R3: OpenDevin coding agent framework

Users who want to create coding agents should be able to select the OpenDevin framework.

• Create a new agent source directory agents/opendevin_agent/ with:
  • src/handler.py — Entry point compatible with BedrockAgentCoreApp
  • src/agent.py — Initializes and runs an OpenDevin agent from configuration
  • src/config.py — Configuration dataclasses appropriate for OpenDevin (workspace settings, model, sandbox config, etc.)
  • requirements.txt — Dependencies including OpenDevin packages and bedrock-agentcore
• The handler must implement the same streaming response interface for SSE compatibility
• Add opendevin as a framework option in the frontend selector with label "OpenDevin (Coding Agent)"
• When opendevin is selected, the deploy form should show relevant configuration fields — at minimum: name, description, system prompt, and model selection
  • Additional OpenDevin-specific fields (e.g. workspace configuration, sandbox settings) can be added as appropriate
• Update build_agent_artifact() to package agents/opendevin_agent/ when the framework is opendevin
• Update create_runtime() to set the correct entry point for the OpenDevin handler
• Evaluate whether OpenDevin's runtime requirements (sandbox, file system access) are compatible with the AgentCore runtime environment — if constraints exist, document them and surface appropriate warnings in the UI

Testing

• Run backend tests: cd backend && make test
• Run frontend typecheck: cd frontend && npx tsc --noEmit
• Verify framework selection UI:
  • Default selection is "Strands Agent"
  • Selecting each framework shows the appropriate form fields
  • JSON import/export (issue feat: tagging page and custom tags (closes #24) #27) includes the agent_framework field
• Verify Strands deployment (regression):
  • Deploy an agent with the Strands framework — behavior identical to current
  • Existing agents display strands as their framework
• Verify LangChain Deep Agent deployment:
  • agents/langchain_deep_agent/ is packaged correctly
  • Agent deploys to AgentCore and reaches READY state
  • Invocation streams responses via SSE
• Verify OpenDevin deployment:
  • agents/opendevin_agent/ is packaged correctly
  • Agent deploys to AgentCore and reaches READY state
  • Invocation streams responses via SSE
• Verify artifact isolation:
  • Each framework's artifact contains only its own dependencies
  • No cross-contamination between framework packages

Out of Scope

• Custom agent framework upload (bring your own framework)
• Framework-specific UI for monitoring or debugging agent internals
• Multi-framework composition (chaining agents from different frameworks)
• Local development or testing harness for alternate frameworks
• Framework version management or pinning beyond requirements.txt