PRs that inherit every decision your team ever made.
Engineering escaped tribal knowledge by accident — the codebase is the documentation. Everywhere else, memory lives in heads. Cortex captures it from the Slack threads, incident channels, and architecture debates where it actually happens.
“Engineering escaped this by accident. The codebase is the documentation. When Francis joined as our first full-time dev, within a day he could ask the codebase anything — architecture, decision history, why a given function existed — and get a real answer. That was the moment this clicked for me. Coding AI works because software engineering is the only function where the work itself produces the institutional memory as a byproduct. Everywhere else, the memory lives in heads.”Read the founding thesis →
Customer request → researched PRD → draft PR.
A customer mentions a feature in Slack. The CS agent summarizes and escalates. The engineering agent reads the repo, finds related issues, drafts the PRD, opens a Linear ticket with acceptance criteria, and submits a draft PR with scaffolded code — all before the next standup. No PM handoff doc. No Notion sprint page. No manual spec.
See the scenario below ↓Jobs your engineering agent handles.
Turn a customer request into a researched PRD and a draft PR — without anyone manually writing a spec.
A CSM posts in #cs-escalations: 'Three enterprise customers asked for CSV export this week. Should be a quick add?'
@cortex read this thread, check if we have a related Linear issue, draft a PRD, open a ticket, and propose an implementation plan against the current repo
The three customer names, the CSM's framing, the specific files the agent read in this session.
The decision to add CSV export, the acceptance criteria, and the implementation approach — stored permanently. Any future engineer asking 'why is this CSV logic here?' gets the full context.
Architecture decisions captured as they're made in Slack, not via a documentation sprint that never happens.
Engineers debate a database schema change in #engineering for 40 minutes, then go build it.
@cortex summarize the architecture decision in this thread and write an ADR — why we chose event sourcing over CRUD here, what we considered, what we ruled out
The specific engineers involved, the exact constraints named in the thread.
The ADR fact: 'We use event sourcing for the payments service because [reason]. Alternatives considered: [CRUD, CQRS]. Decision date: [date].' Available to every future engineer and every future session.
Incident postmortem scaffolded before the war room ends — timeline, root cause, action items pre-filled.
The on-call engineer marks the incident resolved in PagerDuty or Slack.
@cortex write the postmortem for the #incident-2026-04-18 thread — timeline, root cause hypothesis, impact summary, and 3 suggested action items
The specific timeline, services affected, and engineers on call during this incident.
Incident pattern captured: 'DB connection pool exhaustion seen twice in Q1 2026, both triggered by batch jobs running concurrently with peak traffic.' Next time this signature appears, the agent surfaces it before the war room convenes.
Weekly engineering ops digest — deployments, incidents, and unresolved P0s — delivered Friday 4pm.
Scheduled Friday workflow recipe. No manual report writing.
Workflow recipe (engineering.deploy_summary): weekly deploy + incident summary across GitHub, Vercel, and Linear
This week's run parameters — date range, services scanned.
Rolling incident rate and deployment frequency stored weekly. Surfaces trend anomalies ('4 incidents this week, up from 1 last week') without any manual tracking.
Deduplicate GitHub issues before they turn a noisy tracker into a backlog nobody trusts.
Twice-weekly scheduled recipe. Fires before sprint planning.
Workflow recipe (engineering.github_duplicates): scan issues opened in the past 7 days for duplicates and related issues
The specific issue set scanned this run.
Past dedup decisions — so the agent doesn't re-surface an issue pair that was intentionally kept separate last sprint.
Answer 'has anyone done this pattern before?' without interrupting a senior engineer.
An engineer is about to submit a PR and wants to know if the team has precedent for a pagination approach.
@cortex has our team used cursor-based pagination anywhere? what did we decide and why?
The specific PR context and the engineer's question framing.
The pagination decision fact is already there from a prior ADR session. This query promotes it to 'accessed frequently' — edges it closer to permanent tier.
Working in every job above.
The engineers in this incident, the specific branch, the constraints your CTO named. Volatile by design — relevant this session, fades unless it compounds.
“We use event sourcing for payments because X.” “DB connection pool exhaustion triggered by concurrent batch jobs — seen twice.” Written once from a Slack thread, available to every engineer and every future session forever.
Turn your team's tribal knowledge into an organizational asset.
Deploy in 10 minutes. No DevOps required.