For technical evaluators

How the reference builds are put together.

This page is the deep dive behind our working demos—document research, voice intake, and web lead capture. It is written for technical buyers who want to see data flow, security controls, and deployment layers. Office owners evaluating fit should start on Builds; we walk architecture on the assessment call. CPA and HVAC demos stay live; the research stack is spun up on demand so it is not sitting hot when idle. Models for summaries, qualification, and retrieval are optional layers on reliable intake, storage, and handoffs—not autonomous agents running the business.

Reference build

Research & document processing pipeline

A security-conscious, cloud-native pipeline for uploading documents, embedding and indexing content with SWAG semantic profiles, and running structured research workflows with SWAG+CRAG retrieval-augmented generation. Orchestration runs on managed Kubernetes with Qdrant vector search, object storage, network policies, and model inference on Amazon Bedrock. SWAG reranks and filters candidates before CRAG grading (fewer grading tokens). The edge is served over HTTPS behind Cognito authentication on a private demo endpoint. Portable SWAG core is also available separately — see the SWAG research notes.

  • Pattern: Kubernetes on AWS + SWAG rerank/filter + CRAG grading + LangGraph orchestration
  • Retrieval: heuristic SWAG profiles at ingest (no model cost); a fast Claude model for CRAG grading only (capped)
  • Edge: ALB HTTPS + Cognito on a private demo endpoint
  • Security: network policies, upload caps, API rate limits, model-scoped IAM
  • Growth path: additional corpora, SSO, on-prem vector store, hybrid inference

Infrastructure layer

CDK / CloudFormation defines the whole stack: VPC, EKS, S3, ECR, Cognito, ACM, and least-privilege, model-scoped roles.

Application workloads

Showcase UI (streaming gateway), research agents, ingestion, vector store, cache.

Edge access

HTTP NLB (active) or ALB HTTPS + Cognito (after ACM DNS validates). Network policies restrict internal traffic.

External SaaS

Amazon Bedrock (Claude for synthesis and grading, Titan embeddings), tracing, and optional web fallback.

System overview

Public HTTPS via ALB + Cognito on a private demo endpoint. Internal traffic restricted by NetworkPolicies.

flowchart TB
  subgraph external["Outside AWS"]
    User["Demo user"]
    Trace["Tracing optional"]
    Web["Web search optional"]
  end

  subgraph aws["AWS account"]
    CDK["CDK / CloudFormation"]
    SM["Secrets Manager"]

    subgraph vpc["VPC"]
      NAT["NAT Gateway"]
      NLB["NLB HTTP"]
      ALB["ALB HTTPS plus Cognito"]

      subgraph eks["Managed Kubernetes"]
        subgraph showcase["showcase"]
          UI["Showcase UI SSE gateway"]
        end
        subgraph agents["agents"]
          LG["Research agents"]
        end
        subgraph rag["rag"]
          Ing["Ingestion API"]
          Qdrant["Vector store"]
          Redis["Cache"]
        end
        subgraph system["cluster add-ons"]
          ALBC["Load balancer controller"]
          EBS["Block storage CSI"]
        end
        Node["Worker nodes"]
      end

      S3["Object storage"]
      Cognito["Cognito user pool"]
      Budget["Model budget alerts"]
      Bedrock["Bedrock Claude and Titan"]
    end
  end

  User --> NLB
  User -.->|after cert ready| ALB
  ALB --> Cognito
  Cognito --> ALB
  NLB --> UI
  ALB -.-> UI
  UI -->|SSE events| LG
  UI --> Ing
  LG --> Qdrant
  LG --> Ing
  Ing -->|SWAG filter CRAG grade| Bedrock
  LG --> Bedrock
  LG -.-> Trace
  LG -.-> Web
  Ing --> S3
  Ing --> Qdrant
  Ing --> Bedrock
  SM -.-> UI
  SM -.-> LG
  SM -.-> Ing
  CDK --> vpc
  CDK --> Cognito
  CDK --> Budget
  CDK --> SM
  ALBC --> ALB
  EBS --> Qdrant
  NAT --> Bedrock
  NAT --> Trace
Reference build: research & document processing — system overview.

Retrieval pipeline (SWAG + CRAG)

Single vector index — embeddings and SWAG profile metadata in the same payload. Search widens the candidate pool, then runs SWAG rerank + noise filter on multi-candidate requests (strict defaults: one chunk per document, no backfill padding, chrome hard gate). Optional CRAG sends a small capped set to a fast grading model. Sibling expansion is off by default. Shared by search API, UI Search, and agent tools. Modes: baseline · swag · crag · swag+crag. Configurable per corpus — see SWAG article.

flowchart LR
  Q[Query] --> R[Vector retrieve]
  R --> P[Ensure SWAG profiles]
  P --> S[SWAG rerank and noise filter]
  S --> G[CRAG grader capped]
  G -->|relevant| F[Return filtered chunks]
  G -->|ambiguous| RW[Rewrite query]
  RW --> R
  G -->|irrelevant| W[Optional web fallback]
  W --> F
  F --> A[Researcher or UI]
Reference build: SWAG + CRAG retrieval pipeline.

Showcase Search: SWAG-first demo

The Search tab in the reference deployment defaults to Vector → SWAG with baseline compare. Scripted demo paths run frozen validation queries with the right topic filter — chrome trap, AP lane, cafeteria lane. CRAG modes are labeled optional; agents still use SWAG→CRAG for safety.

Scripted pathTopic laneWhat it proves
Chrome trap (RAG body)Validation / chromeSWAG promotes body over README chrome
Chunking qualityValidation / chromeSame trap — substantive chunk at top-1
AP · three-way matchAccounts payableDomain lane + rerank on PO content
Cafeteria · food safetyOps / food safetyIsolated ops corpus, not mixed noise
CRAG · cross-domain bait (optional)All topicsFull stack may return empty on mixed-domain bait

Four retrieval modes

Same query through each pipeline with optional baseline compare. Lead demos with SWAG alone; switch to SWAG→CRAG when discussing agent safety.

ModeWhat it showsTypical outcome on messy HTML
SWAGDefault demo. Rerank + noise filterBody promoted; duplicates dropped — use lift cards
BaselineVector similarity only (naive RAG)Chrome and nav chunks often at #1
CRAGGrader scores vector top-K (optional)Some mis-ranked chunks still pass
SWAG → CRAGSWAG clean → CRAG grade (agents; optional demo)Fewer hits; empty when grader rejects

Enable Compare against baseline to see purged vs kept chunks side by side. Showcase regression and the product eval harness (messy corpora, strong baselines, retrieval + answer gates) are how we keep the demo honest. Retrieval policy knobs live in ingestion config.

Four-pillar eval harness

Each qrel defines corpus, question, expected retrieval (gold doc + traps), and expected answer. One command scores retrieval metrics and, with --generate, answer correctness + citation + hallucination rate against brutal thresholds. Honest fail is a feature — it separates demo regression from product proof.

CorpusMessinessExample trap
retail-furnitureDeprecated sizing, duplicate policiesv1 sizing guide vs v2
terraform-cloudVersion docs, acronymsTerraform 1.2 legacy vs 1.5
legal-contractsArchived MSAs, cross-refsMSA v1 $10k cap vs v3
medical-adminHIPAA/PHI/BAA2019 infection policy outdated
mixed-garbageContradictions, partial PDFsConflicting refund policies

Research run sequence

UI gateway streams agent progress. Researchers call ingestion SWAG+CRAG (not raw vector search); traces go to the optional tracing service.

sequenceDiagram
  actor User
  participant Edge as Edge HTTPS Cognito
  participant UI as Showcase UI gateway
  participant LG as Research agents
  participant Ing as Ingestion API
  participant Q as Vector store
  participant BR as Bedrock
  participant Web as Web search optional
  participant Trace as Tracing optional

  User->>Edge: HTTPS
  Edge->>UI: Forward
  User->>UI: Research topic
  UI->>LG: Start streamed run
  LG-->>UI: Run started
  LG->>LG: Coordinator plan
  LG-->>UI: Plan review interrupt
  User->>UI: Approve plan
  UI->>LG: Resume
  Note over LG,Ing: researchers use SWAG then CRAG per sub-question
  LG->>Ing: Search with SWAG then CRAG
  Ing->>Q: Vector retrieve candidates
  Q-->>Ing: Chunks plus SWAG metadata
  Ing->>BR: SWAG rerank and CRAG grade capped
  BR-->>Ing: Reranked graded chunks
  alt weak RAG
    Ing-->>LG: web fallback
    LG->>Web: Web search
    Web-->>LG: Web snippets
  else good RAG
    Ing-->>LG: Filtered chunks
  end
  LG->>BR: Synthesize findings
  LG-->>UI: Critique review interrupt
  User->>UI: Synthesize or more research
  LG-->>UI: Report
  LG-->>Trace: Traces
Reference build: research workflow sequence.

Document ingestion sequence

Uploads are size-capped and rate limited at the API gateway. Chunking uses structural markdown split (nav vs body). Indexing stores Titan vectors and heuristic SWAG profiles on each chunk in one pass.

sequenceDiagram
  actor User
  participant Edge as NLB or ALB Cognito
  participant UI as Showcase UI
  participant Ing as Ingestion
  participant S3 as S3
  participant BR as Bedrock
  participant Q as Qdrant

  User->>Edge: HTTP or HTTPS
  Edge->>UI: Forward
  User->>UI: Upload file
  UI->>Ing: Ingest request
  Ing->>S3: Store raw
  Ing->>Ing: Chunk and classify nav or body
  Ing->>BR: Titan embeddings
  BR-->>Ing: Vectors
  Ing->>Ing: Heuristic SWAG chunk profiles
  Ing->>Q: Upsert vectors and SWAG payload
  Ing-->>UI: Done
Reference build: document ingestion sequence.

Security controls

ControlImplementation
Edge authCognito @ ALB (private demo endpoint)
TLSACM-managed TLS certificate
IAMLeast-privilege, model-scoped roles per workload — each service can call only what it needs
SecretsAWS Secrets Manager + Kubernetes secrets; nothing hard-coded in images
Upload capEnforced on the UI gateway and ingestion service
Rate limitsPer-client limits on ingest and research endpoints
SSRFURL ingest blocks private IPs, metadata, and bad redirects
NetworkNetworkPolicies restrict internal traffic to required paths only
SpendAWS Budget alerts on model usage

Provisioned by layer

LayerProvisions
Core infrastructureVPC, EKS, S3, ECR, Cognito, ACM certificate, and least-privilege model-scoped roles
Cluster bootstrapEBS CSI, ALB controller, external secrets, autoscaler, and storage classes
Application workloadsVector store, cache, ingestion, research agents, showcase UI, and network policies
Edge accessHTTP or HTTPS + Cognito ingress depending on certificate status

Demo lifecycle cost modes

Reference lifecycle for demo and non-production environments—park when idle to control spend.

stateDiagram-v2
  [*] --> Parked
  Parked --> Running: deploy stack
  Running --> Stopped: stop
  Stopped --> Running: start
  Running --> Parked: park
  Stopped --> Parked: park
Reference build: deployment lifecycle states.
ModeWhat runsRelative cost
ParkedObject storage and images onlyMinimal
StoppedControl plane only — no nodes or load balancerReduced
RunningFull stack, on demandFull (only while live)
Reference build

Voice intake & reception automation

Inbound calls are handled by Amazon Connect, captured by a Node.js Lambda, stored in DynamoDB, and pushed to the team via SNS email alerts. Optional model-assisted summaries can be added where they help staff respond faster. A lean, managed-services footprint — VPC isolation added when a deployment calls for it. Provisioned with AWS CDK (CloudFormation).

  • Pattern: managed voice + serverless backend
  • IaC: AWS CDK (TypeScript) → CloudFormation
  • Runtime: Node.js Lambda, on-demand DynamoDB, Amazon Connect
  • Growth path: CRM webhooks, Lex, additional flows

Voice channel

PSTN / SIP inbound to a claimed DID, routed by an Amazon Connect contact flow.

Managed backend

Connect + Lambda + DynamoDB + SNS — pay-per-request throughout, with VPC isolation added when needed.

Optional assist

Bedrock summarization layered on top; staff alerts and durable records always land first.

Operator outcome

Email alert on every lead, leads queryable in DynamoDB, and a CRM-webhook-ready path.

System overview

A claimed phone number routes into a Connect contact flow that invokes a single Lambda handler. The handler persists the lead, publishes a notification, and — only when enabled — asks Bedrock for a short summary. The whole stack is defined in CDK.

flowchart LR
  Caller["PSTN caller claimed DID"] --> Connect["Amazon Connect inbound contact flow"]
  Connect -->|invoke function| Lambda["AWS Lambda handler"]
  Lambda -->|store lead plus raw event| DDB["DynamoDB leads table"]
  Lambda -->|publish new lead alert| SNS["Amazon SNS notifications"]
  Lambda -.->|optional summary| BR["Amazon Bedrock"]
  SNS -->|email subscription| Ops["Operator or CRM inbox"]
  CDK["AWS CDK to CloudFormation"] --> Connect
  CDK --> Lambda
  CDK --> DDB
  CDK --> SNS
Reference build: voice intake and reception — system overview.

Call handling sequence

Every inbound call runs the same path. Persistence and the staff alert are guaranteed; the model summary is an optional step that never blocks the record or the notification.

sequenceDiagram
  actor Caller
  participant C as Amazon Connect
  participant L as Lambda handler
  participant D as DynamoDB
  participant B as Bedrock optional
  participant S as SNS
  participant Ops as Staff inbox
  Caller->>C: Inbound call on claimed DID
  C->>C: Run inbound contact flow
  C->>L: Invoke function with contact data
  L->>D: PutItem lead plus raw event
  opt summary enabled
    L->>B: summarize
    B-->>L: Short summary
  end
  L->>S: Publish new lead alert
  S-->>Ops: Email notification
  C-->>Caller: Disconnect
Reference build: voice intake call handling sequence.

Components & configuration

LayerServiceConfiguration
Voice channelPSTN / claimed DIDPhone number attached in Connect; standard inbound routing
Telephony + flowAmazon ConnectManaged instance with an inbound contact flow; Contact Lens and flow logs
ComputeAWS LambdaSingle handler function; Node.js; short timeout
StorageAmazon DynamoDBOn-demand table keyed by lead, indexed by contact; retain-on-delete
NotificationsAmazon SNSTopic with an email subscription
Optional assistAmazon BedrockModel-generated summary, only when enabled
IaCAWS CDK → CloudFormationSingle voice intake stack

Security & operations

ControlImplementation
IAMLeast-privilege function role scoped to only the services it uses
DataOn-demand storage with retain-on-delete; keeps the structured lead and raw event
ObservabilityCloudWatch metrics, logs, and alarms for Lambda and Connect
IaC lifecycleCloudFormation drift detection and change sets
FootprintLean managed-services footprint; VPC isolation and Lex or a knowledge base added as needs grow
Reference build

Web lead capture & follow-up

Website visitors submit a lead form to an HTTP API. Lambda validates the payload, qualifies the request (rules-based with optional model scoring), writes to DynamoDB, and sends a notification email through SES. Static frontend hosted separately (Amplify, S3, or CMS embed). Serverless throughout — no servers to patch. Provisioned with AWS SAM (CloudFormation).

  • Pattern: HTTP API + serverless processor
  • IaC: AWS SAM → CloudFormation
  • Runtime: Python Lambda, HTTP API, DynamoDB with point-in-time recovery, tracing
  • Growth path: CRM integration, WAF, additional qualification rules

Web channel

An HTML form on a separately hosted frontend (Amplify, S3 + CloudFront, or existing CMS) POSTs JSON.

Serverless processor

API Gateway HTTP API → Lambda → DynamoDB → SES. Pay-per-use, nothing to patch.

Qualify step

Rules-based scoring by default; optional Bedrock model scoring when it earns its place.

Owner outcome

Instant email with score, grade, and summary; JSON response to the visitor; CRM-hook-ready payload.

System overview

A form POST hits an HTTP API that proxies to one Lambda. The function validates, optionally qualifies, persists, and notifies — then returns JSON to the visitor. The whole stack is a single SAM template.

flowchart LR
  Visitor["Website visitor HTML form"] -->|"POST JSON"| API["API Gateway HTTP API"]
  API --> Lambda["AWS Lambda processor"]
  Lambda -->|save lead| DDB["DynamoDB leads table"]
  Lambda -.->|optional scoring| BR["Amazon Bedrock"]
  Lambda -->|send email| SES["Amazon SES verified sender"]
  SES -->|score grade summary| Owner["Sales or owner inbox"]
  API -->|JSON response| Visitor
  SAM["AWS SAM to CloudFormation"] --> API
  SAM --> Lambda
  SAM --> DDB
Reference build: web lead capture and follow-up — system overview.

Submission sequence

Validation and persistence run on every submission; scoring is optional. The visitor gets a JSON response while the owner gets an email with the grade and summary.

sequenceDiagram
  actor Visitor
  participant API as API Gateway HTTP API
  participant L as Lambda processor
  participant B as Bedrock optional
  participant D as DynamoDB
  participant M as SES
  participant Owner as Sales inbox
  Visitor->>API: POST JSON lead
  API->>L: Invoke proxy integration
  L->>L: validate
  opt scoring enabled
    L->>B: qualify
    B-->>L: score plus grade
  end
  L->>D: save lead
  L->>M: send email
  M-->>Owner: Lead email score grade summary
  L-->>API: 200 JSON
  API-->>Visitor: Response
Reference build: web lead submission sequence.

Components & configuration

LayerServiceConfiguration
Web channelStatic frontendHTML form; hosted on Amplify / S3 + CloudFront / existing CMS
Edge / APIAPI Gateway HTTP APISingle POST endpoint with CORS preflight; access logs to CloudWatch
ComputeAWS LambdaProcessor function; Python; short timeout
StorageAmazon DynamoDBOn-demand table keyed by lead; encrypted at rest; point-in-time recovery
NotificationsAmazon SESVerified sender; email to the owner with score, grade, and summary
Optional assistAmazon BedrockOptional model scoring; rules-based fallback
IaCAWS SAM → CloudFormationSingle SAM template

Security & operations

ControlImplementation
IAMLeast-privilege function role scoped to only the services it uses
DataEncrypted at rest; point-in-time recovery; on-demand billing
CORSLocked to your site's origin in production (open only in the sandbox demo)
TracingX-Ray tracing on Lambda; API and Lambda logs in CloudWatch
HardeningProduction fronts the API with WAF and adds CRM integration
Compare at a glance

Same delivery discipline, different problem.

Research & documents

Best for teams drowning in PDFs, policies, and research requests: ingest documents, index for retrieval, and run guided research workflows with human-readable output.

Voice intake

Best for businesses that live on the phone: after-hours capture, routing by intent (appointment, sales, support, urgent), and immediate staff alerts with structured summaries.

Web lead capture

Best for marketing sites and landing pages: structured lead intake, qualification (rules or optional model assist), durable storage, and email notifications without running servers.

These examples span serverless AWS patterns and Kubernetes-based CRAG/RAG pipelines. We apply the same delivery discipline on-prem, in hybrid setups, and when standing up new infrastructure—and we can walk through which deployment and model layers fit your environment on a call.

Want a walkthrough?

We can demo any of these builds on a call.

Ask for a live walkthrough, deployment checklist, or a diagram scoped to your environment and growth plans.

Book an Assessment