How one AI agent became the first thing on our team that never stops checking atlan.com. With Dubem & Kushagra.
One evening last spring, one of us opened atlan.com on his phone and watched a blank rectangle sit where the homepage should be. Eight seconds of nothing. Then close to twenty more seconds where the page ignored every tap while the browser worked through styling the homepage never needed.
What followed was the reflex every website person has. Check the error console: green. Check the alerts channel: quiet. Run the page through a performance test: 31 out of 100.
For a website team, that’s as close to a fire as it gets. The site was failing in front of anyone who opened it, and every instrument we had said everything was fine. Nothing in our systems knew. No error fired,
and the only way we would have found out is a customer telling us.
Nothing errored because nothing broke the way software usually breaks. Our site is built so that a content update never touches code; pages are composed from a library of pre-built sections, and the build system decides, automatically, which styling each page actually needs. That automation is what lets a small team run thousands of pages. On this day it met an edge it couldn’t see: a styling bundle for a few new sections was labelled in a way that slipped past the rule deciding what’s shared and what isn’t, so it began loading everywhere; the homepage among them. No single system was wrong. The failure lived in the space between three correct ones, which is exactly why no alarm could point at it.
Once we knew, the fix took minutes. But knowing was the hard part.
When We Decided to Reimagine Everything.
That gap is why Optimus exists. It is also where we part ways with the usual AI pitch. The usual pitch is efficiency: do the same work faster. We don’t build for that. We build AI to own outcomes a human team cannot hold at all, however fast it works. Keeping every page on atlan.com fast, for real visitors, every day, through problems that trip no alarms, is one of those outcomes. And the goal is to outperform.
The homepage was not a fluke. It is the daily condition of a site that ships faster than any person can watch it.
As of last spring, almost none of our pages passed Google’s Core Web Vitals on mobile. Over 1,100 sat in the “needs improvement” bucket, effectively zero were green, and a single March regression dropped nearly 950 pages into the red overnight.
The bottleneck was never the fix. Those are often one line. It was noticing, in time, on the pages that matter. Hundreds of URLs. Vitals that move every day on real-user data. Every deploy a candidate regression. Every diagnosis, hours in DevTools, commit logs, and analytics. That’s too much for anyone to track manually. So we built Optimus to do it.
What Optimus Does.
Optimus is an AI agent that lives in Slack. It watches every page on atlan.com worth watching, every day, without being asked. Here is its daily loop.
1 · Starts smarter than yesterday. Optimus keeps a running notebook: a page to watch after a recent change, a “broken link” that is really an external site blocking us. It reads yesterday’s notes first, so each day starts where the last one ended, not from scratch.
2 · Checks what a visitor would feel. Optimus walks every tracked page, every day, and measures what a visitor feels rather than what the console reports; the blank seconds, the layout that shifts underfoot, the tap that goes nowhere; across the real devices and networks our visitors use. A regression that once needed a customer to catch, a machine catches first. And we keep feeding Optimus more to sense with search, traffic, conversion, so a slow page doesn’t just register as slow, it registers as costing us something, early enough to act on.
3 · Traces the cause. For anything it finds, Optimus traces the problem back to the recent code change most likely responsible, a tweak to a shared component that touched dozens of pages, say. That is a lead for the fix to start from.
4 · Files the fix and the guardrail. For every issue, Optimus writes two things: how to fix it, with enough detail that Mothership can implement it without coming back for context, and a guardrail, a check that would have caught this before it shipped, so the same class of mistake cannot slip through twice.
5 · Keeps its watchlist honest. From the day’s Slack chatter it adds pages that now matter, a new launch, a page suddenly in focus, and retires ones that don’t. Before it finishes, it leaves notes for the next run. That notebook is its memory across days.
Two to three days after a fix ships, Optimus re-checks the real-world data to confirm the improvement actually landed.
The Human Gate: Nothing Ships Without a Decision.
Optimus’s autonomous surface is read-only. It changes nothing in production. What it does on its own authority:
- queries analytics and runs diagnostics
- reads source code and correlates commits
- files tickets and posts findings to Slack
Code changes run downstream through Mothership, our AI development platform that reviews and gates every engineer’s code (we’ll share more about Mothership in a future piece). Mothership implements the fix and opens a pull request; a human reviews and merges it, the same gate every engineer’s code passes through. Every fix ships with a preview build linked in Slack before merge, and the loop closes only when post-merge real-user data confirms the improvement days
later.
We describe the split as a restaurant: “All of the claws are basically waiters in a restaurant. They go and talk to the chef in the back kitchen. The chef is the Mothership, taking care of everything.” Optimus takes the order, carries it to the kitchen with full diagnostic detail, and brings the result back to the table. Optimus does the thinking; Mothership does the building.
Our version of “autonomous” is a narrow one, and we think a stronger one: nothing waits for a human to notice, and nothing ships without a human deciding.
The Impact.
Optimus has had an incredible impact on the team. Here are the
numbers, and a few of the moments where it changed how we work.
94% off the page weight, no visible difference. A content update shipped three uncompressed images: 4.7 MB and a 25-second mobile load. The daily sweep caught it the same day and cut the weight by 94%.
A thousand-plus pages faster, from a two-line fix. Optimus traced a sitewide drag to two lines in a shared template that roughly 1,340 pages inherit. It named the exact file and lines; deleting them fixed all 1,340 at once.
A launch protected before its audience arrived. A brand-new page went out heavy, was caught the next morning, and was fast again before the visitors it was built for showed up.
Six seconds of load time recovered with one line. An article page lost six seconds to a single eager video embed. The fix was one line.
Every one of these was invisible to the error console, and each would have cost weeks of drift before anyone connected it to the change that caused it.
The fixes behind that drop were specific: deferred non-critical loaders, tracking moved out of the critical path, less hydration on content pages. About 1.1 seconds of blocking time, removed. And the operational queue, check this page, diagnose that regression, chase that fix, moved off people’s plates.
Add it up. By 20 July 2026, 1,516 mobile pages passed Core Web Vitals, 18 needed improvement, and zero were in the “poor” bucket, on both mobile and desktop. Desktop performance score went from 57 to 88; total blocking time from over a second to under 200 milliseconds. Fixes an agent opened, a human merged.
(The thresholds are Google’s own, measured on real-user field data at the 75th percentile: “poor” means LCP ≥ 4.0s, CLS ≥ 0.25, or INP ≥ 500ms. Source: Search Console’s Core Web Vitals report, backed by the Chrome UX Report. Before-snapshot early April, after-snapshot July 20.)
In Kushagra’s words: “A lot of work has been delegated, which basically means we focus on the bigger, better things rather than working on operational stuff. You basically teach AI how to get the job done once or maybe twice. Then you focus on how external stakeholders are experiencing pain points, fix the process, make it more seamless so everyone moves faster, rather than you just executing.”
The mental model shifted from “I do the work” to “I teach the system how to do the work, then improve the system.”
What We’re Still Figuring Out.
Optimus spins up a virtual instance, pulls in context, and understands the query before it starts working, which adds latency. We are working to make it faster.
Long-term memory is the harder frontier. The day-notes notebook works: a hunch on Monday becomes a check on Tuesday. What Optimus cannot yet do is learn from a mistake once and never repeat it, weeks later, unprompted. That kind of durable pattern recognition, an agent that genuinely gets better each week, is the next hard problem.
And today Optimus catches most problems after they happen, even if it catches them before any human notices. The next phase is to catch them before they ship: finding UI and UX issues before anyone reports them and delivering the diagnosis with a proposed fix attached, with humans still owning every merge.
Final Thoughts.
We did not set out to do the old work faster. We set out to own an outcome no human team could hold. It is early days, but Optimus is starting to get there.
The site now holds a standard it never held before: fast on every page, every day, without depending on someone remembering to look, and with a human on every change that ships. We did not get there by doing the old work faster. We got there by handing an outcome to a system built to own it. That is the version of AI-native worth building toward.