Projects

Problem

Running a tech content operation solo requires handling research, writing, code review, social distribution, and community engagement — tasks that don't scale with one person.

Architecture Decisions

• →Chose a multi-agent architecture over monolithic AI: each agent has a single responsibility and communicates through a shared event bus (PostgreSQL-backed GBrain)
• →Built 5 specialized agents: Research (content discovery + summarization), Writer (draft generation), Reviewer (code + content QA), Publisher (multi-channel distribution), Community (Discord engagement)
• →Event-driven coordination instead of sequential pipelines — agents react to events, not rigid schedules. This makes the system resilient to individual agent failures
• →Used PostgreSQL as the "brain" (shared memory) instead of vector DB — simpler ops, better debugging, and structured queries for agent state

Outcomes

• ✓Running autonomously for 6+ months with <2% intervention rate
• ✓24/7 content research, code review, and community response
• ✓Reduced manual content ops time from ~3hrs/day to ~15min/day (92% reduction)
• ✓Handles 50+ daily tasks across Discord, GitHub, and blog publishing

What I Learned

• •Agent reliability matters more than intelligence — a dumb agent that always works beats a smart one that fails 10% of the time
• •Shared memory architecture (GBrain) is the single most important design decision. Without it, agents can't build on each other's work
• •Cost control needs to be a first-class concern: implemented token budgets per agent, request deduplication, and graceful degradation when approaching limits
• •Observability for non-deterministic systems is hard — built custom dashboards tracking task completion rate, cost per task, and failure patterns

Problem

Publishing content across multiple channels (blog, newsletter, social) requires a fragile chain of manual steps. One missed step = inconsistent state across platforms.

Architecture Decisions

• →Config-driven architecture: every content piece defined in a config file (schedule, channels, variants) — the system executes the config, humans don't touch the pipeline
• →AWS ECS for scheduled tasks (reliable, cheap for burst workloads) + K3s for persistent services (newsletter API, analytics)
• →Supabase as the content database + auth layer — chose it over custom Postgres for faster iteration on admin UI
• →GitHub Actions as the orchestration trigger (schedule → build → distribute) rather than building a custom scheduler

Outcomes

• ✓Zero-touch publishing pipeline: content goes from draft → published → distributed with no human steps
• ✓Handles blog posts, newsletters (500+ subscribers), and social distribution on configurable schedules
• ✓Monthly cost: ~$12 (ECS Fargate spot + Supabase free tier + Resend starter)
• ✓Reduced publish-to-distribute time from hours to under 3 minutes

What I Learned

• •Config-driven beats code-driven for operations — non-engineers can change publish schedules without touching code
• •ECS Fargate Spot is criminally underpriced for batch jobs that can tolerate 30s startup latency
• •Building on Supabase: fast for MVP, but the Edge Functions cold start (2-4s) and 50MB limit become pain points at scale
• •GitHub Actions as a scheduler works until you need sub-minute precision or complex dependency chains — fine for content ops, wouldn't use for real-time systems