Swan says agents now produce the vast majority of its code

Pritzker walks through a single incident from July 9, when a partner's webhook sent a burst of events that broke a database job. A Cygnet job queried Datadog on its own, found the burst, and opened a ticket with its query, the time window, and a guess at the cause. Three investigator agents then reran that evidence in parallel. Two reached the same root cause and the third dissented, and all three write-ups went onto the ticket. A separate group of agents proposed a fix, and a human approved the resulting spec by adding a label. The pipeline opened a pull request that afternoon and tried to prove the fix worked by driving the change through a real browser in an offline environment. That proof run failed, so a human took over, reproduced the bug locally, confirmed the fix, and merged it.

The system puts two controls on agent memory. Memory writes triggered by a "remember this" Slack reaction require a human reply before anything is stored because, Pritzker writes, "memory poisoning can lead to security issues or worse outcomes." A lesson only gets promoted from an internal note into a shared, agent-loadable skill after evidence accumulates from multiple sources, though a single correction is enough to flag a problem: "when someone says 'no, not like that,' we don't need to wait for it to happen again." Swan reports going from zero agent-authored commits two years ago to what it calls the vast majority of its code today, and says ten people with no prior engineering background are now shipping code through a paired onboarding program called Wingspan.

Why it matters: Swan separates immediate corrections from durable agent memory. A human approves every shared-memory write, and repeated evidence is required before a lesson becomes a standing skill. Those controls address the risk that one interaction could alter future agent behavior. The commit and headcount figures are Swan's own account, with no outside audit.