Architecture
Event-driven orchestration running on AWS. Claude reasons, Python orchestrates, humans approve. Here's everything that's actually deployed.
Design Principles
Event-Driven, Not Autonomous
Every action starts with an external event (Slack message, email, JIRA ticket, cron schedule). PAGE never acts on her own impulse — deterministic Python workflows with Claude as the reasoning engine.
LLM as Brain, Not Orchestrator
Claude generates content and classifies intent, but control flow is always in Python code. No ReAct loops, no tool-calling chains. The orchestrator decides what to do; Claude decides how.
Graduated Autonomy
Every content output flows through Slack approval gates. As reliability is demonstrated over time, approval thresholds relax. Trust is earned incrementally, never assumed.
Auditable & Debuggable
Structured logging on every handler call. Full JIRA ticket lifecycle tracking. Every Claude API call logged with token counts. No black boxes — every decision is traceable.
How a Task Flows Through PAGE
From external event to published content — every step is deterministic, logged, and human-approved.
Intake
External event arrives via webhook or schedule
Slack message → Lambda → SQS, Gmail → Lambda → SQS, JIRA webhook → Lambda → SQS, EventBridge cron → SQS
Queue
Message lands in the right SQS queue
6 task queues (content, community, feedback, growth, meeting, report) with DLQs for failed messages
Orchestrate
Orchestrator polls SQS, classifies intent
Intent classifier uses Claude to score confidence → task rubric validates required fields → dispatches to the right handler
Execute
Handler generates content via Claude
Blog drafts (800-1500 words), social posts (300 chars × 3 platforms), email replies, code gists, Slack reports
Approve
Slack approval gate with approve/reject/revise
Content preview posted to Slack → human clicks Approve, Reject, or Request Revision → action recorded in JIRA
Publish
Approved content pushed to destination
Blog → GitHub Actions rebuild → S3 + CloudFront. Social → Bluesky/LinkedIn/Threads APIs. Email → Gmail API
Live Infrastructure
Everything below is deployed and running in AWS us-east-1. Managed by Terraform (10 modules, ~80 resources).
Compute & API
Core orchestrator, webhook router, blog API — runs on ECS Fargate behind API Gateway
Content, Community, Feedback, Growth, Meeting, and Report workers — each a dedicated task definition
Receives Slack interactions, JIRA webhooks, and scheduled events — routes to SQS queues
Messaging & Events
content-tasks, community-tasks, feedback-tasks, growth-tasks, meeting-tasks, report-tasks — each with a dead-letter queue
Fires scheduled tasks (daily reports, weekly summaries) into SQS queues
Data & Storage
Tasks, BlogPosts, content pipeline state, and 1536-dim embeddings for semantic memory and RAG
content-drafts (working artifacts), published-artifacts (final outputs), meeting-recordings (Recall.ai transcripts)
API keys for Claude, Slack, Gmail, JIRA, GitHub, Bluesky, LinkedIn — rotated and encrypted at rest
Frontend & CDN
Main site — features, architecture, about. Served from S3 via CloudFront with HTTP/2+3
Blog — posts built at deploy time from PostgreSQL. Rebuilds automatically when a post is approved
PriceClass_100, TLS 1.2+, origin access control for S3. ACM cert covers both subdomains
A-alias records for both subdomains, MX for Gmail, ACM validation CNAMEs
CI/CD Pipeline
On push to main or workflow_dispatch → build → S3 sync → CloudFront invalidation
Scoped to pages-code/PAGE main branch — S3 put/delete + CloudFront invalidation only
Monitoring & Alerting
DLQ message alerts, RDS CPU/storage, API Gateway 5xx rate, ECS task failures
SQS queue depths, API latency, DB connections, Lambda invocations — single-pane view
Integration Map
13+ external services connected via APIs, webhooks, and protocols.