Overview

Carlos the Architect implements a multi-agent Software Development Lifecycle (SDLC) for cloud infrastructure design. The system uses 11 specialized AI agents orchestrated through LangGraph to automate the complete journey from requirements gathering to production-ready Terraform code, with historical learning from past deployment feedback.

┌───────────────────────────────────────────────────────────────────────────────────┐
│                           AGENTIC SDLC PIPELINE                                    │
├───────────────────────────────────────────────────────────────────────────────────┤
│                                                                                   │
│  REQUIREMENTS ──► LEARNING ──► DESIGN ──► ANALYSIS ──► REVIEW ──► DECISION ──► CODE │
│       │              │           │           │           │           │          │ │
│  [Gathering]   [Historical]  [Carlos]   [Security]  [Auditor]  [Recommender] [TF] │
│       │         [Learning]   [Ronei]     [Cost]         │           │          │ │
│       │              │          ║        [SRE]          │           │          │ │
│       ▼              ▼          ▼           ▼           ▼           ▼          ▼ │
│   Questions     Context    2 Designs   3 Reports    Approval   Selection    IaC  │
│              from feedback                                                        │
└───────────────────────────────────────────────────────────────────────────────────┘

SDLC Phases Mapped to Agents

Agent Architecture

The 11 Agents

┌─────────────────────────────────────────────────────────────────┐
│                      AGENT HIERARCHY                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  TIER 1: PRIMARY ARCHITECTS (GPT-4o)                           │
│  ┌─────────────────┐    ┌─────────────────┐                    │
│  │     CARLOS      │    │     RONEI       │                    │
│  │  Conservative   │ vs │   Innovative    │                    │
│  │  AWS-native     │    │   Kubernetes    │                    │
│  │  temp: 0.7      │    │   temp: 0.9     │                    │
│  └─────────────────┘    └─────────────────┘                    │
│           ▲                     ▲                              │
│           └───────┬─────────────┘                              │
│                   │                                            │
│  TIER 0.5: HISTORICAL LEARNING (No LLM - Data Query)          │
│  ┌─────────────────────────────────────────┐                   │
│  │         Historical Learning              │                   │
│  │   (Queries Cosmos DB for past feedback)  │                   │
│  └─────────────────────────────────────────┘                   │
│                                                                 │
│  TIER 2: SPECIALIST ANALYSTS (GPT-4o-mini)                     │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                      │
│  │ Security │  │   Cost   │  │   SRE    │                      │
│  │ Analyst  │  │ Analyst  │  │ Engineer │                      │
│  └──────────┘  └──────────┘  └──────────┘                      │
│                                                                 │
│  TIER 3: DECISION MAKERS (GPT-4o)                              │
│  ┌──────────┐  ┌───────────┐  ┌───────────┐                    │
│  │ Auditor  │  │Recommender│  │ Terraform │                    │
│  │  Chief   │  │  Design   │  │   Coder   │                    │
│  └──────────┘  └───────────┘  └───────────┘                    │
│                                                                 │
│  TIER 0: REQUIREMENTS (GPT-4o-mini)                            │
│  ┌───────────────────┐                                         │
│  │    Requirements   │                                         │
│  │     Gathering     │                                         │
│  └───────────────────┘                                         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Agent Details

1. Requirements Gathering Agent

• Model: GPT-4o-mini (cost-optimized)
• Role: Initial clarification of user needs
• Output: 3-5 clarifying questions about:
  • Workload characteristics (traffic, data volume, users)
  • Performance requirements (latency, throughput, SLAs)
  • Security & compliance needs
  • Budget constraints
  • Deployment preferences

1.5 Historical Learning Node

• Model: None (data query only)
• Role: Learn from past deployment feedback
• Data Source: Azure Cosmos DB (deployment feedback)
• Process:
  1. Extract keywords from refined requirements
  2. Query similar past designs from feedback store
  3. Categorize feedback by success (4-5 stars) vs problems (1-2 stars)
  4. Extract patterns that worked well
  5. Extract warnings from problematic deployments
• Output: Formatted context injected into design prompts
• Graceful Degradation: Returns empty context on failure (5s timeout)

2. Carlos (Lead Cloud Architect)

• Model: GPT-4o (main pool)
• Temperature: 0.7 (balanced)
• Personality: Pragmatic, conservative, dog-themed
• Focus: AWS-native managed services, proven patterns, simplicity
• Output: Complete architecture design with Mermaid diagram
• Philosophy: “If it ain’t broke, don’t fix it”

3. Ronei (Rival Architect – “The Cat”)

• Model: GPT-4o (ronei pool)
• Temperature: 0.9 (more creative)
• Personality: Cutting-edge, competitive, cat-themed
• Focus: Kubernetes, microservices, serverless, service mesh
• Output: Alternative architecture design with Mermaid diagram
• Philosophy: “Innovation drives excellence”

4. Security Analyst

• Model: GPT-4o-mini
• Focus Areas:
  • Network exposure & segmentation
  • Identity & access management
  • Data encryption (transit + rest)
  • Logging & monitoring
  • Incident response readiness

5. Cost Optimization Specialist

• Model: GPT-4o-mini
• Focus Areas:
  • Major cost drivers identification
  • Reserved instances / savings plans
  • Spot/preemptible instance opportunities
  • Storage lifecycle & archival
  • FinOps best practices

6. Site Reliability Engineer (SRE

• Model: GPT-4o-mini
• Focus Areas:
  • Failure scenarios & blast radius
  • Capacity planning & auto-scaling
  • Observability (metrics, logs, traces)
  • Health checks & alerting
  • Operational runbooks

7. Chief Architecture Auditor

• Model: GPT-4o (main pool)
• Role: Final quality gate
• Decision: APPROVED or NEEDS REVISION
• Output: Executive summary with strengths and required changes

8. Design Recommender

• Model: GPT-4o (main pool)
• Role: Select the winning design
• Decision: Must choose exactly one (Carlos OR Ronei)
• Output: Recommendation with justification and tradeoffs

9. Terraform Coder

• Model: GPT-4o (main pool)
• Role: Generate production-ready infrastructure-as-code
• Output:
  • main.tf – Resource definitions
  • variables.tf – Input variables
  • outputs.tf – Output values
  • versions.tf – Provider configuration
  • Deployment instructions

Workflow Graph

LangGraph State Machine

                              START
                                │
                                ▼
                    ┌───────────────────────┐
                    │  Has User Answers?    │
                    └───────────────────────┘
                           │         │
                          NO        YES
                           │         │
                           ▼         │
              ┌────────────────────┐ │
              │   Requirements     │ │
              │    Gathering       │ │
              └────────────────────┘ │
                           │         │
                           ▼         │
              ┌────────────────────┐ │
              │ Clarification      │ │
              │ Needed?            │ │
              └────────────────────┘ │
                    │         │      │
                   YES       NO      │
                    │         │      │
                    ▼         ▼      ▼
                  END    ┌─────────────────┐
            (wait for    │     Refine      │
             answers)    │  Requirements   │
                         └─────────────────┘
                                  │
                                  ▼
                         ┌─────────────────┐
                         │   HISTORICAL    │
                         │    LEARNING     │
                         │ (query feedback)│
                         └─────────────────┘
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
           ┌──────────────┐            ┌──────────────┐
           │    CARLOS    │            │    RONEI     │
           │   (design)   │  PARALLEL  │   (design)   │
           │ +historical  │            │ +historical  │
           │   context    │            │   context    │
           └──────────────┘            └──────────────┘
                    │                           │
                    └─────────────┬─────────────┘
                                  │
              ┌───────────────────┼───────────────────┐
              │                   │                   │
              ▼                   ▼                   ▼
       ┌────────────┐      ┌────────────┐      ┌────────────┐
       │  SECURITY  │      │    COST    │      │    SRE     │
       │  ANALYST   │      │  ANALYST   │      │  ENGINEER  │
       └────────────┘      └────────────┘      └────────────┘
              │                   │                   │
              └───────────────────┼───────────────────┘
                                  │
                                  ▼
                         ┌──────────────┐
                         │   AUDITOR    │
                         │   (review)   │
                         └──────────────┘
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
               APPROVED                   NEEDS REVISION
                    │                           │
                    ▼                           │
           ┌──────────────┐                     │
           │ RECOMMENDER  │                     │
           │  (decision)  │                     │
           └──────────────┘                     │
                    │                           │
                    ▼                           │
           ┌──────────────┐                     │
           │  TERRAFORM   │◄────────────────────┘
           │    CODER     │      (revision loop)
           └──────────────┘
                    │
                    ▼
                   END

https://github.com/rtrentin73/carlos-the-architect

Using AS_PATH to Prefer Routes from Oracle to the On-premises Network

Oracle uses the shortest AS path when sending traffic to the on-premises network, regardless of which path was used to start the connection to Oracle.Therefore asymmetric routing is allowed. Asymmetric routing here means that Oracle’s response to a request can follow a different path than the request.

Oracle implements AS path prepending to establish preference on which path to use if the edge device advertises the same route and routing attributes over several different connection types between the on-premises network and VCN.

Oracle honors the complete AS path you send.

Reference

https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectoverview.htm

Recommended

crypto ikev2 proposal IKEV2-PROP 
 encryption aes-gcm-256
 prf sha512
 group 19
!
crypto ikev2 policy IKEV2-POLICY 
 proposal IKEV2-PROP
!
crypto ikev2 keyring IKEV2-KEYRING
 peer SITEB
  address 162.43.158.29
  pre-shared-key local Str0ngSecret!
  pre-shared-key remote Str0ngSecret!
 !
!
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 162.43.158.29 255.255.255.255 
 identity local address 162.43.158.41
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2-KEYRING
 dpd 10 5 on-demand
!
crypto ipsec transform-set TS-ESP-GCM esp-gcm 256 
 mode tunnel
!
crypto ipsec profile IPSEC-PROFILE
 set transform-set TS-ESP-GCM 
 set ikev2-profile IKEV2-PROFILE
!         
interface Tunnel10
 description IKEv2 VTI to 162.43.158.29
 ip address 10.10.10.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 162.43.158.29
 tunnel protection ipsec profile IPSEC-PROFILE
!

For environments where GCM is not supported:

crypto ikev2 proposal oracle_v2_proposal 
 encryption aes-cbc-256
 integrity sha384
 group 14
!
crypto ikev2 policy oracle_v2_policy 
 proposal oracle_v2_proposal
!
crypto ikev2 keyring oracle_keyring_tunnel1
 peer oracle_vpn
  address 129.146.159.116
  pre-shared-key local <pre-shared key>
  pre-shared-key remote <pre-shared key>
 !      
!
crypto ikev2 profile oracle_ike_profile_tunnel1
 match identity remote address 129.146.159.116 255.255.255.255 
 identity local address 162.43.155.57
 authentication remote pre-share
 authentication local pre-share
 keyring local oracle_keyring_tunnel1
!
crypto ipsec transform-set oracle-vpn-transform esp-aes 256 esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile oracle_ipsec_profile_tunnel1
 set transform-set oracle-vpn-transform 
 set pfs group14
 set ikev2-profile oracle_ike_profile_tunnel1
!
interface Tunnel100
 ip address 169.254.0.1 255.255.255.252
 tunnel source 162.43.155.57
 tunnel mode ipsec ipv4
 tunnel destination 129.146.159.116
 tunnel protection ipsec profile oracle_ipsec_profile_tunnel1
!

IKEv2/IPSec Algorithm Cheat Sheet

Phase 1 – IKEv2 (Control Channel)

Purpose: Establish a secure, authenticated channel for negotiating IPsec.

Phase 2 – IPsec (Data Channel)

Purpose: Encrypt and protect actual traffic between sites.

Why GCM is Faster

• AES-GCM uses Counter mode (CTR) for encryption and Galois field multiplication for authentication, which can be parallelized.
• AES-CBC encrypts blocks sequentially (each block depends on the previous), so it cannot be parallelized for encryption.
• GCM also eliminates the need for a separate integrity algorithm (HMAC), reducing overhead.

Why ECDH is Faster

1. Smaller Key Sizes for Same Security
   • Classic DH (MODP) needs very large primes (e.g., 2048-bit for Group 14) to achieve strong security.
   • ECDH achieves equivalent security with much smaller keys (e.g., 256-bit for Group 19).
   • Smaller keys mean less data to exchange and fewer operations.
2. Efficient Mathematical Operations
   • MODP DH uses modular exponentiation, which is computationally expensive and grows with key size.
   • ECDH uses elliptic curve point multiplication, which is much more efficient for the same security level.
3. Lower CPU Cycles
   • Modular exponentiation involves repeated multiplications and reductions on large integers.
   • Elliptic curve operations are optimized and require fewer CPU cycles, especially with hardware acceleration.
4. Better Hardware Support
   • Modern CPUs and crypto libraries often include optimized routines for elliptic curve math.
   • ECDH benefits from acceleration (e.g., Intel AES-NI and ECC instructions), while MODP DH gains less.