Atlas Platform
Twenty systems on one platform, running a New York media agency since January 2026.
Innovation & Strategy Analyst · inventor of Atlas · Jan 2026 → present
I was the planner. The platform began as the three things I hated doing by hand. It is twenty systems now, and the people I used to sit next to run on it.
In sixty seconds
Atlas’s platform map: where account analysis, print proofing and operations fit together.
- was
- Every tool its own silo; every launch, audit, proof and ticket a hand-off between people.
- now
- A shared application with separate workflows; the map provides context for the contribution studies.
- the decision
- Specialised agents over one general agent: when one fails you know where to look.
- the run
- Creative Matrix demo →
- where it sits
- the map →
Opened · What the agency ran on
Ad spend across Google, Meta, DV360 and the rest, run through spreadsheets, email and memory.
Every platform was its own silo. A campaign launch was days of setup, naming and QA by hand. Print proofing was a person reading every page by eye. Budget problems surfaced after the damage, in the report. Every new hire learned an undocumented set of workarounds from whoever sat next to them.
Dollar figures and rates from that time are not published yet. Each case study says what it will carry when its receipt is released.
Every system had a person inside it doing the routing.
Blocked · The cost
Nothing talked to anything, so every request was a coordination exercise between tools and people.
The breaking point was a campaign that launched under the wrong naming convention and was not found until reporting, weeks later. Nobody had done anything wrong; the system had no place where the mistake could have been caught. The same shape repeated in audits, in proofs and in tickets: the work was fine, the hand-offs were the cost.
The fix had to be one platform, not one more tool.
Reassigned · The approach
One platform, one login, built around the decisions people were already making.
Four rules, in order. A person stays in the loop wherever judgment is needed, so every automation ends at a gate. One module per agency domain, so a planner who learns one has learned them all. The three systems that paid first shipped first: ops routing, the Google Ads audit, print proofing. And nothing could ask a planner to learn a new app.
The build decisions followed from those. One codebase for every module, so auth, roles and the component library are shared. Specialised agents with narrow roles instead of one general agent, so when one fails you know where to look. Data layers chosen by job: transactions in Postgres, the live feeds in Firestore, history in BigQuery. Single sign-on through Azure because the agency's IT required it. Built solo alongside the day job, with Claude Code and Cursor, shipped through pull requests with review.
What I did not do
- One general agent
- Each agent has a narrow, auditable role; when the taxonomy agent fails you know exactly where to look. A general agent is a black box at scale.More orchestration to run, far easier debugging.
- A nightly batch job
- Campaign budgets need reallocation within hours; a batch job at midnight is useless when the spend alarm fires at two in the afternoon.Live feeds cost more to run than a batch.
- Hosting where it was convenient
- The agency's IT required single sign-on through Azure. Compliance, not preference.Less convenience for the developer; the only viable path for the agency.
- A separate codebase per module
- One codebase for every module means shared auth, roles and a component library without drift.A larger initial build.
Then I drew the map.
In progress · The map
The map is drawn from the real system list; the chains are the real routes. Nothing on it is live.
Twenty systems in five layers, and the five chains a request travels through them.
Read it bottom to top: the foundation, the data, the tools, distribution, automation. A packet runs each chain in turn and lights the systems it passes through. Hover or tap any system for what it does, what it feeds and what it is fed by. Three of these systems have their own pages below.
One decisionSpecialised agents over one general agent. When the taxonomy agent fails you know exactly where to look; a general agent is a black box at scale.
What brokeThe first QA runner walked pages with Playwright and reported false positives by the hundred. It was rebuilt five times between March and May until it could resume where it crashed, read the API response behind a green toast, and check the database row behind a click.
When it breaks
- A test run crashes mid-way
- the system The QA runner resumes where it crashed instead of starting over.
- seen by The person watching the run
- A bug hides under a green toast
- the system The runner reads the API response behind the toast and the database row behind the click.
- seen by The deploy decision
- Something breaks in production
- the system The platform says what broke before anyone has to report it, and the team hears it in Slack without checking every tool.
- seen by The team
Three of those systems have their own pages.
Closed · The change
The map gives context. The contribution studies explain the implementation.
Proofing is used since January, according to my account; the later V2 study covers snapshots, worker ownership and partial results. PPC Auditor is in beta, with a study of model-output recovery, evidence and methodology. The twenty nodes describe this map, rather than a deployment or adoption count.
The demonstrations use invented inputs. The contribution narratives distinguish implementation, reported use and measured outcomes.Explore all Atlas contribution studies →
What I would do again is the order.
Next
Do again
Ship the three things people hated first, then the platform around them. Keep a person at every gate.
Not again
Build the platform first and look for uses after. The map only made sense once three systems were already paying for it.
The order is the pattern: the hand-done check, encoded; the gate, kept; the platform, around them. I am looking for an applied-AI engineering role at a company with real operations to automate.
Ask me about
- How do twenty systems share one login and one component library without drift?
- One codebase for every module, so auth, roles and the component library are shared. A planner who learns one tool has learned them all.
Built with
Hire me
I'd build this for your team.
I am looking for an applied-AI engineering role at a company with real operations to automate. The résumé is one page.