Cortex

Cortex — AI Chief of Staff that detects hidden risks, stalled decisions, and burnout signals across your engineering org before they become incidents. One dashboard. 30 seconds to clarity.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Cortex# Cortex — AI Chief of Staff

Inspiration

I've watched engineering leaders struggle with the same invisible problem: the bigger your team gets, the less you actually see.

At 10 engineers, a CTO knows everything — who's blocked, who's frustrated, which decisions are stuck. At 50+, critical signals get buried. A security vulnerability sits open for 17 days because the engineer fixing it didn't want to escalate. A DevOps engineer works 56-hour weeks for two sprints straight — nobody notices until they quit. A policy disagreement between two leads blocks three people across two teams for 14 days, and it never reaches leadership because neither side thinks it's "their job" to escalate.

The data to detect all of this already exists — in Slack DMs, email threads, Jira tickets, GitHub PRs, and meeting transcripts. But no tool connects the dots across all four. Jira shows tickets, not the human conflict behind them. Slack shows messages, not the pattern of someone going silent. Pulse surveys show sentiment weeks after the damage is done.

I wanted to build the tool I wish every CTO had: an AI that reads everything, connects everything, and tells you — in 30 seconds — what's about to break and what to do about it.

What It Does

Cortex is an AI-powered chief of staff that gives engineering leaders real-time organisational intelligence across four dimensions:

  • Conflict Detection — Identifies cross-team disagreements blocking decisions, with severity, evidence, and one-click resolution
  • Burnout & Health Monitoring — Scores every employee's health from work patterns (hours, blocked tickets, communication gaps) without self-reporting or surveys
  • Shadow Topics — Surfaces emerging risks being discussed in DMs and side threads with no formal owner — the things nobody escalates until it's too late
  • ARIA Assistant — A voice-enabled AI executive assistant powered by Amazon Nova that attends meetings, extracts decisions, and briefs you every morning

The demo runs a complete narrative: a fictional 18-person engineering team at "Nexus Technologies" with interconnected storylines — a critical security violation, a caching infrastructure policy deadlock, an approaching SOC 2 audit, and an engineer at burnout threshold. All data flows through MCP (Model Context Protocol) services simulating real Slack, Email, Jira, and GitHub integrations.

How I Built It

Architecture: Full-stack application with clear separation between data ingestion, intelligence processing, and presentation.

Frontend: Next.js 14 with App Router, TypeScript, and Chakra UI. Dark theme designed for quick scanning — a CTO should understand the state of their org in under 3 seconds on any screen. Interactive org chart built with Cytoscape.js, health trends with Recharts.

Backend: FastAPI serving a PostgreSQL database (with pgvector for semantic search), Neo4j knowledge graph for relationship mapping, and Redis + Celery for async processing. The backend runs conflict detection algorithms, health scoring, and decision extraction.

AI Layer: Amazon Nova Pro handles the core intelligence — ARIA chat, meeting transcript analysis, conflict severity classification, and briefing generation. Nova was chosen specifically for its structured output quality (critical when extracting specific names, ticket IDs, and deadlines from long transcripts) and low-latency inference through Bedrock. ElevenLabs provides voice output for the executive assistant.

Data Integration: Four MCP services (Email, Slack, Jira, Git) each expose a standardised tool interface. A shared narrative module (shared_narrative.py) provides the interconnected demo data — 5 email threads, 5 Slack channels with threaded replies, 10 Jira tickets, and 3 pull requests, all cross-referencing the same storylines.

Infrastructure: Fully containerised with Docker Compose — 10 services (frontend, backend, worker, PostgreSQL, Neo4j, Redis, and 4 MCP services) orchestrated to start with a single command.

Challenges

Cross-source correlation was the hardest problem. Detecting that a Slack DM from Carlos about being exhausted, a blocked Jira ticket (INFRA-024), an email from his manager to the VP, and a 56-hour work week pattern are all the same story required building a knowledge graph that links people → tickets → messages → decisions. Getting Amazon Nova to reliably extract these entity relationships from unstructured text — and not hallucinate connections that don't exist — took significant prompt engineering.

Designing for the 3-second rule. Engineering leaders are the most time-constrained users imaginable. Every screen had to communicate its most important signal immediately. This meant killing features that added complexity without adding clarity — I removed three full dashboard sections that were technically impressive but made the core insight harder to find.

Docker orchestration at scale. Running 10 interconnected services locally with correct startup ordering, health checks, and shared volumes was unexpectedly complex. The backend needed access to MCP service data before those services were fully running, which led to the volume-mount approach for shared narrative data.

Making the narrative feel real. A demo with fake data is only convincing if the data tells a believable story. I spent significant time crafting the Nexus Technologies scenario so that every data point reinforces the others — the security violation connects to the shadow PR, which connects to the SOC 2 audit timeline, which connects to the burnout signals. Judges should be able to click into any page and find the story holds up.

What I Learned

  • Amazon Nova Pro is remarkably good at structured extraction — once you give it clear schemas and examples, it reliably pulls decisions, action items, and risk signals from messy meeting transcripts
  • The knowledge graph (Neo4j) was the right call — SQL alone can't efficiently answer "show me everything connected to this person across all data sources"
  • MCP as an integration pattern scales well — adding a new data source means writing one service with a standard interface, not touching the core backend
  • Design restraint wins — the most impactful design decisions were things I removed, not things I added
Share this project:

Updates