Skip to main content

CAP Engine (cap-engine-langgraph-lite)

Core AI Functionality​

The engine is the core of the platform, including LLM integration, prompt management, and agent orchestration. You can have multiple engines in your organization, each with its own LLM, prompt management, and agent orchestration.

The CAP ENGINE LangGraph Lite is a basic implementation of the CAP ENGINE. It is a simple engine that allows you to practice the use of CAP.

Another implementation of the CAP ENGINE is the CAP ENGINE LangGraph MCP. It is a more complex engine that allows Model Context Protocol (MCP). This is an open protocol that enables seamless integration between LLM applications and external data sources and tools.

Find more engines in the Engine Catalog as well as in the LangGraph Catalog.

Key Features​

  • LLM integration framework
  • Prompt management system
  • Agent orchestration
  • Response generation
  • Performance monitoring

Repository Structure Guide​

Monorepo vs. Separate Repositories​

While in a test and development scenario you might have separate repos for each agent or agent group, in production you would prefer a small number of monorepos.

A monorepo approach puts each agent in its own subdirectory rather than maintaining one agent per Git branch. Each subdirectory contains its own Dockerfile, resulting in multiple Docker images—one per agent—for deployment on ECS Fargate.

Why Use Subdirectories Instead of Branches?​

1. Branches Are for Versioning/Features​

  • Git branches are for feature development, bug fixes, or release versions
  • Using separate branches for agents loses the single "main" trunk advantage
  • Updates affecting all agents become harder to integrate

2. Subdirectories Enable Code Sharing​

  • Maintain a common libs/ or shared/ folder for shared libraries
  • Each agent gets its own folder (e.g., agents/agent-hr, agents/agent-finance)
  • Logical separation while maintaining repository unity

3. Better Visibility and Single Source of Truth​

  • All agents, Dockerfiles, and shared code visible in one place
  • Normal branching workflow for features or fixes across all agents

Implementation Guide​

1. Folder Structure​

my-monorepo/
├─ agents/
│  ├─ agent-hr/
│  │  ├─ Dockerfile
│  │  ├─ main.py
│  │  └─ ...
│  ├─ agent-finance/
│  │  ├─ Dockerfile
│  │  ├─ main.py
│  │  └─ ...
│  └─ ...
├─ shared/
│  └─ ... (common libraries, data models, utility scripts)
└─ terraform/
   └─ ...

2. Docker Configuration​

  • Each agent has its own Dockerfile
  • Shared code referenced from ../shared/ as needed
  • Distinct image tags for each agent

3. AWS Integration​

ECR Setup​

resource "aws_ecs_task_definition" "agent_hr" {
  family                = "agent-hr"
  container_definitions = <<DEFINITION
  [
    {
      "name": "agent-hr",
      "image": "${aws_ecr_repository.agent_hr.repository_url}:latest",
      "cpu": 256,
      "memory": 512,
      ...
    }
  ]
  DEFINITION
  ...
}

resource "aws_ecs_service" "agent_hr" {
  name            = "agent-hr-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.agent_hr.arn
  desired_count   = 1
  launch_type     = "FARGATE"
  ...
}

CI/CD Pipeline​

1. Development Workflow​

  1. Developer commits code to agent subdirectory
  2. CI system detects changes
  3. Pipeline builds affected agent images
  4. Updated images pushed to ECR
  5. Terraform deploys changes
  6. ECS performs rolling update

2. Deployment Strategy​

  • Automatic or manual Terraform deployment
  • Rolling updates for zero-downtime deployment
  • Blue/green deployment option available

Best Practices​

  1. Repository Organization

    • Use subdirectories for agents
    • Keep shared code in common location
    • Maintain clear separation of concerns

  2. Build Automation

    • Detect changes per subdirectory
    • Build only modified components
    • Use consistent tagging strategy

  3. Deployment

    • Separate ECS services per agent
    • Configure appropriate scaling
    • Monitor resource usage

Next Steps​

Implementation Details​

For implementation details and solutions, see our technical implementation guide