The Work

Four domain agents — Revenue, Operations, Customer, Security — each read their own corner of the business and emit structured evidence. A Chief of Staff (Coordinator) aggregates the four findings into one context package. A General Manager (Orchestrator) reasons across that package and emits typed insights — Risk, Opportunity, Coordination Gap, or Drift — each with severity, cross-domain connections, recommended actions, and a historical precedent. The value is the connective tissue: a security anomaly, a support surge, a falling health score, and an imminent renewal on the same account are recognized as one cascading event, not four tickets.

The Coordinator fires all four domain agents simultaneously with a ThreadPoolExecutor(max_workers=4) over RequestResponse Lambda invokes — never a sequential chain. Reading the four domains concurrently instead of in series is what keeps a full cross-domain synthesis (API Gateway → Orchestrator → Coordinator → 4 agents → Nova Pro → Aurora write) at ~8s end-to-end; the pgvector lookup against the memory table is negligible next to the Nova Pro reasoning call, which is the real floor on latency.

Most numbers Magnivonic shows are deterministic formulas in code, reproducible from their inputs:

• Security & Operations — additive rule-based formulas over real telemetry and live GitHub signals. No model judgment, fully auditable.
• Revenue & Customer — weighted / signal-severity formulas from the real account metrics (renewal window, health, close-probability, sentiment; the six churn signals).
• General Manager confidence — a corroboration-weighted formula: how many of the four domains corroborate an insight, blended with their severity-weighted confidence.

Amazon Nova Pro's job is reasoning and narration — finding the cross-domain pattern, classifying the insight type, and explaining the computed scores in plain language. It does not invent the numbers. Every formula is printed on the Confidence page.

Past incidents are embedded with Amazon Titan Embed V2 into 1024-dimension vectors and stored in Aurora PostgreSQL + pgvector behind an HNSW index using cosine distance. The embedding deliberately concatenates summary + outcome + lessons_learned — a 3-field strategy that gives retrieval more semantic surface than the summary alone, so a match can be driven by what was done and learned, not just what happened. Against the current memory set, live cross-domain queries retrieve their closest precedent at roughly 0.40–0.49 cosine similarity — the engine treats ≥ 0.35 as genuinely relevant. On every run the General Manager pulls the most similar past events and folds their lessons into the recommendation.

• AWS Lambda (Python 3.12) — all 6 agents + the API handlers, on a shared layer.
• Amazon Bedrock — Nova Pro (us.amazon.nova-pro-v1:0) for synthesis/narration; Titan Embed V2 for memory vectors.
• Amazon Polly (neural) — converts a Debrief answer to speech on demand, so a decision-maker can hear the synthesized brief, not just read it.
• Aurora PostgreSQL Serverless v2 + pgvector — both the relational store (customers, risks, recommendations, agent_events, slack_alerts) and the HNSW vector index for memory.
• API Gateway (REST) — the judge-facing endpoints; EventBridge for background agent events; Secrets Manager for Aurora / GitHub PAT / Slack webhook.
• Real outbound integrations: GitHub API (live delivery signals) and Slack (executive alerts).

Every agent returns a structured fallback rather than crashing the run: a parse failure or a missing signal yields low-confidence fallback evidence, so one bad agent never takes down the cascade. The memory search returns an empty set (not an error) if embedding is unavailable. The Slack notifier logs slack_secret_missing and the pipeline completes normally if no webhook is configured. Warm-up pings are guarded so they cost nothing.

Cross-domain reasoning needs two things from one store: the relational facts (accounts, risks, recommendations, agent events, alerts) and semantic recall over past incidents. Aurora PostgreSQL Serverless v2 + pgvectordoes both in a single managed engine — so an insight and the memory it cites live in the same transactional store, with no separate vector database to provision, sync, or keep consistent. That was a deliberate architectural choice, not a convenience: it's what makes “reason now, grounded in what happened before” a single query instead of a distributed join.

It also scales the way this problem grows. Memory recall is an HNSW index lookup — an approximate nearest-neighbour search whose cost grows logarithmically, not linearly — so the same architecture serves twenty incidents or tens of thousands without a schema change, and a larger memory corpus improvesretrieval quality (more precedents to match) rather than slowing it down. Aurora Serverless v2 autoscales compute on demand to absorb bursts of concurrent agent runs, and the design leaves clear headroom to add read replicas as an organization's signal volume climbs.

A public marketing site and the gated live platform (this app) share one identity, built on Next.js 16 + Turbopack. The marketing site was built with v0, and both surfaces deploy on Vercel— the “Vercel” half of the zero-stack, AWS × Vercel build. The platform talks only to the real AWS endpoints; every score, citation, and alert on these pages comes from a live call, not a fixture.