by Ilia SadykovA month ago I wrote that we had shipped the boring half of AI site generation — the bucket, the certificate, the DNS record — and exposed it as an API your product could call on behalf of your own customers. That post ended on a sentence I have been quoting back at myself ever since: your users never learn that an agent was involved, and never see our name unless you want them to.
That was a promise about one page. This is the same promise about a whole product — and, more to the point, about the thing you build it in.
The sentence that keeps arriving
“Our customers keep emailing to ask where their case is. We want them to just ask, and see it.”
It arrives in some form in nearly every conversation we have — from a clinic, a law firm, a logistics operator, a school. What they are describing is never a chatbot. It is a product: the customer signs in, asks for something, and watches it get done. Records that persist. Roles that mean something. A bill at the end of the month. A support inbox when it breaks.
And that is where it stalls, every time, for the same reason. The interesting 10% takes a weekend. The rest — accounts, sessions, password resets, a domain, a certificate, background jobs, an admin view, metering, somebody watching it at 3am — takes a quarter, and it is a quarter of work that is identical for every one of them.
We have now built that quarter once, and turned it into something you build in.
Two words, kept apart
A portal is the product your customers land in. Their sign-in, their records, their assistant, their invoice, your name on all of it.
Atrium is the tool you create and manage that portal in. You work in it; your customers never see it and never hear the word.
If you have run a CMS or a CRM admin, the shape is deliberately familiar: pages and blocks, collections and roles, copy, theme, domain, who can see what. What is different is what the blocks are. Instead of a hero and a rich-text field, the library holds an assistant that acts, a process with states, background work that survives a closed tab, voice, metering.
What arrives with a portal, already working:
- Real accounts. Sign-in by email or Google, one account per customer, with their own data and the session handling done.
- An assistant that acts. It streams answers, takes files and voice, and then does the thing — creating a record, running the work, coming back with a result rather than a suggestion.
- Work that survives a closed tab. Jobs run in the background and report back.
- A cost line per customer. What each one consumed this month, in money, before you decide what to charge them.
Each of those is a finished piece rather than a starting point. You switch one on and it appears in your customers’ portal, in the place they would expect to find it. And switching one on next March is the same kind of act as switching one on today — a named change with a preview in front of it, not a project.
Forge, meanwhile, becomes the platform under the hood — the agent runtime, the model gateway, the deployment machinery. You can still use it directly, and if you already have a product and want to add one capability to it you should: you call an API from your backend and your customers never leave your product. That door is still there.
Atrium is the door where none of that has to be learned, chosen or wired. For a business with fifteen people and no platform team, the useful version of this is not an SDK — it is a conversation about what your customers should be able to do, and a portal that gets composed accordingly. The platform is underneath; it is just not your problem.
Why this is not a prompt-to-app builder
It would be easy to file this next to the tools that turn a paragraph into a running app, and the difference is worth being precise about, because it is not speed.
Those tools put the intelligence in the factory. You describe an app, a model writes the code, and what your customers end up using is a conventional CRUD application made of forms. It is genuinely good at getting you to a demo. Then it hands you the part nobody enjoys: permissions that were only ever enforced in the UI, keys sitting somewhere they should not be, multi-tenancy, the 3am pager. The industry’s own numbers on this are not flattering, and the usual next move is to hire somebody who is good at driving Claude or Codex and spend the quarter you were trying to skip.
Atrium puts the intelligence in the product. The portal your customers sign into is agent-first because the assistant, the process engine and the background work are components that already run in production — not code written fresh for you this afternoon and audited later. That is why the boring parts arrive finished rather than plausible, and why there is no hardening phase between the first version and a real customer.
Which also removes a step that has quietly become normal: you no longer need a person in the middle who knows how to get a coding agent to build this sort of thing. That step disappears.
Fast is table stakes now. Being the same system on week fifty as on day one is the part that is hard.
Your product, your domain, yours
Your customers sign in at your address and see your name. Nothing about the portal says who built it — not in the app, not in an email, not in an error message — and that boundary is enforced by the code rather than by a policy page, the same way it has been since the site-generation post a month ago .
Ownership is the same story told shorter. By default the portal opens on a subdomain we run and operate; a CNAME moves it to a domain of yours; and if you ever want the repository and the deployment configuration, you take them and run it yourself. I would rather put that in the announcement than in a contract annex. It is the honest answer to the lock-in question, and we can only give it because what you would be taking is an ordinary deployable application rather than a tenancy you can never leave.
What changing it feels like
A month in, you want a new field on a record, or the intake step split in two, or the word “case” to read as “matter” everywhere your customers see it.
You say so. An agent makes the change and a preview is waiting for you — the real portal, with your data in it, at an address only you can reach. You look, you publish, your customers see it. If it was wrong, you say that instead and nothing reaches them.
No ticket, no release window, no Friday surprise where something you did not ask about also moved. That is the part I would care about if I were buying this, more than how fast the first version appeared.
The honest state
Portals are real and running. The parts they are composed from are in production, and the agent-first experience works in front of real customers today.
Signing up is self-service. You do not book a call, and you are not assigned an account manager — you describe who your customers are and what they come to get done, and agents trained specifically on Atrium compose the portal out of that library. Shipping it is handled by the same automated delivery fleet that builds and deploys Forge itself. Neither you nor we sit in the middle of it. Day-two changes work the same way: you describe the change, an agent makes it, and a preview is waiting for you before your customers see anything.
What is still growing is the library. Everything is composed from parts that already run, which is exactly why a portal is trustworthy on day one — and also why a requirement nobody has asked for yet may need a new block before it can be switched on. When that happens you get told, rather than quietly handed a plausible-looking screen. I would rather write that here than have you find it in week two.
Everything about Atrium — what it does, how it is bought, how it is documented — lives at atriumdev.app .
If you have the sentence at the top of this post somewhere in your inbox, tell us what your customers should be able to do . That is the whole brief.