The person with the problem is now the person who builds the tool

The lineup at our Applied AI Showcase in New York on July 28 was Horizon, the wow CLI, Blog Bot, Wallaby, and Atlas: five tools, five owners, four different functions. On the Applied AI team at WorkOS, we continue to enable the entire org to ship code to production. The person with the problem is now the person who builds the tool, and a platform team's remaining job is the road, not the vehicles.

Nobody filed a ticket

Jacobia Johnson built Wallaby after embedding with the go-to-market org, which is to say it was built by the people who had been doing that research by hand. These are some of the problems it targets: data scattered across Salesforce, the data warehouse, and call transcripts; manual enrichment for events and lists; data rot across hundreds of thousands of CRM accounts. That list is something you come to know after a year of doing the work yourself.

Blog Bot exists because I was constantly helping others write blog posts to announce their new ships. The wow CLI exists because an engineer lives inside the workflow it fixes. Jason Barry's Horizon, our internal code factory, came out of the same instinct.

Requirements gathering was always a transfer protocol: it moved knowledge from the person with the problem to the person with the ability to build. When one person holds both, you can build against the actual pain points faster.

Claude Day turned that into a rule instead of an accident. Every person at WorkOS was paired one technical with one non-technical, the non-technical person had to drive, and 39 apps shipped to production in a single day. Each person picked a problem from their own actual work, and the engineers were told in advance that their job was to unblock rather than take over. Our writeup of the day recorded the effect.

That single constraint changed the energy of the day. The person closest to the problem was the person making the decisions.

Almost every one of those 39 teams built something they had personally been annoyed by for months.

The feedback loop is one person long

The tools that survive are the ones whose author is also their heaviest user, and the mechanism is unglamorous. There's no ticket queue between noticing a defect and fixing it, and no product manager translating a complaint into an acceptance criterion. Blog Bot improves through a feedback channel where teammates report bugs: Claude reads the channel, files a Linear issue, fixes a subtask, deploys a preview, writes its own Slack test messages to exercise the failing path, verifies, and asks me to merge. It takes three minutes from report to a verified fix in a PR.

Three minutes is only possible because I already know which of those bug reports matter. I use the thing every day. A platform team serving five functions can't hold that judgment for all five, and no amount of user research buys it.

Being the user is also how you find out you built the wrong shape. A year and a half before Blog Bot, I built nearly the same backend and launched it as a standalone web app, and it went nowhere, because a login screen sat between the user and any value. Nobody had to tell me. I was the person not using it.

The Platform Perspective and paving the road

If domain owners are building, the useful work moves upstream to whatever they build on top of. Our Applied AI team started with a charter to embed with a function, find the highest-impact problem that week, and ship something. Demand outran that model quickly. Engineering Manager Sherry Ali walked through the shift at the showcase, and our recap summarized it this way:

Demand outran the team almost immediately. The goal shifted: don't be a service that hands out AI tools. Make AI the default capability across WorkOS. That meant building core platforms and the substrate that lets anyone at the company ship.

wow machine setup installs the boring dependencies so a new hire's laptop can ship, and wow app create scaffolds an app with AuthKit for login, Cloudflare Workers for hosting, SQLite per app, Doppler for secrets, and a GitHub Action that ships on merge.

The CLI is named after our company value, earn the wow. On Claude Day, the first git push deployed a live app at their-app-name.workos.tools with a Workers backend, a D1 database, R2 for images, and zero-trust auth already wired. Secrets were pre-provisioned, so nobody had to file a ticket to reach Notion or Snowflake.

Every item on that list is a decision taken away from the builder. The go-to-market analyst doesn't get a vote on the hosting platform. We can allow everyone to go faster by paving the road and encoding engineering decisions into the platform.

Atlas is the same idea one layer higher, for agents rather than apps. Each custom agent carries its own instructions, skills, memory, integrations, and @-name, with behavior defined by a written job description. Integrations are connected per person and can be shared with the organization, so an agent isn't blocked on whoever owns a login, and it reaches more than 150 tools out of the box. We built it for ourselves before shipping it publicly on August 4.

The backlog became a governance surface

"Internal tools backlog" used to name a queue of requests you could prioritize. It now names a register of what already exists: what got built, by whom, with access to what.

The control point moved with it. Code review doesn't work on tools like these, as we argued in The legal team is shipping software now:

If your only lever is inspecting what a builder wrote, you have no lever at all, because the builder never opened a pull request you were watching.

Ngandu Kasuku, a Principal Product Counsel at GitHub, built himself a contract drafting tool called terms-ai with GitHub's own CLI agent and reports cutting his review and drafting time roughly in half. That tool's security model is whatever credential it holds.

So the constraints sit at issuance. A user-scoped API key belongs to a person and inherits their permissions, with the honest caveat that it can't be restricted below them: if the person can issue refunds, so can their tool. A tool that outgrew one person needs an org-scoped key with a narrowed permission set, so nobody's departure breaks it. And admins holding widgets:user-api-keys:manage-all get visibility across every key in the org.

Atlas encodes the same posture for agents. Every agent is scoped at creation: whether it can save files, whether it can write to memory, which integrations it may touch, which workflows it can run. Agents get isolated memory, scoped integrations, server-side secrets, and audit logs, with no standing superuser. Some limits aren't the builder's to configure at all: workos, slack, admin, security, support, everyone, here, and channel are reserved names an agent can't take.

The bill for this

The honest cost is sprawl, duplicated agents, and automations with a bus factor of one. We have an expectation that the most effective and valuable tools created during Claude Day quickly get promoted and given additional maintenance and attention to reduce this siloing.

The true value is in the transformation of behavior and expectation. Now, when someone on the team identifies a slow and tedious process, their first inclination is to start building the solution.