The job
“Our customers keep emailing to ask where their case is. We want them to just ask, and see it.”
That sentence turns up in some form in almost every conversation we have. The wanted thing is not a chatbot. It is a product: the customer signs in, asks for something, and watches it get done — with records that persist, roles that mean something, a bill at the end of the month, and a support inbox when it breaks.
Building that is not one project. It is accounts, billing, a domain, a certificate, an assistant, background work, an admin view, and somebody watching it at 3am. Most teams prototype the interesting 10% in a weekend and then stall for a quarter on the rest.
What Atrium is, and what a portal is
Two words, and keeping them apart is the whole explanation.
A portal is the product your customers land in. Their sign-in, their records, their assistant, their invoice, your name on all of it. It is the thing being sold and the thing being used.
Atrium is the tool you create and manage that portal in. You work in it; your customers never see it, never hear the word, and never have an account there.
If you have run a CMS or a CRM admin, the shape is familiar on purpose — 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. The AI-first parts are already in place; you are arranging them, not inventing them.
Creating one goes like this:
- You sign up and describe it. Who your customers are, what they arrive wanting, what has to be true before you would put a real one in front of it. No call required.
- Agents compose it. Agents trained specifically on Atrium pick the parts and put them together — sign-in, records, a process with states, the assistant, background jobs, an admin view, metering — and the delivery is handled end to end by the same automated fleet that ships Forge itself. Nobody is assigned to your account, on your side or ours.
- A preview you approve. You look at the thing your customers would see, and it goes live when you say so — under your name, on a working address.
Then the other half, which is the half you spend the next two years in:
- Managing it. Turn a block on. Move it above the other one. Rename “case” to “matter” everywhere your customers read it. Add a collection, add a pricing tier, change the theme, point it at a different domain. Each of those is a named, bounded change that an agent applies and puts a preview in front of — not a ticket, and not somebody editing files.
The part that makes any of this possible is boring and is the whole point: there is a library of parts that already work. Nothing interesting gets built from a blank file.
Agent-first, for the people who never asked for software
The portals people actually want are not ones their customers have to learn.
Your customer arrives with a sentence — “where is my case”, “book me the Thursday slot”, “send last month’s invoices to my accountant” — and that sentence is the interface. The assistant does the thing: creates the record, runs the work, comes back with a result rather than a suggestion, and keeps going after the tab is closed.
The conventional screens are still there, and some of your customers will prefer them. They are just no longer the price of entry.
That is what we mean by agent-first, and it is the reason a portal built this way is not the same product as the same features arranged as forms.
What arrives already working
| Accounts | Real sign-in by email or Google, per customer, with the session handling done |
| Assistant | Streams answers, takes files and voice, acts on requests rather than describing them |
| Background work | Jobs that run after the tab closes and report back |
| Hosting | Run by us by default; your own domain via one CNAME; the whole thing handed over if you want to run it |
| Metering | What each customer costs you, per month, in money |
| Data | Yours, everywhere, and only yours |
Each of those is a finished piece. Switch one on and it appears in your customers’ portal, working, in the place they would expect to find it.
Your product, your domain, yours
Your customers sign in at your address and see your name. Nothing about the portal says who built it, in the app or in an email or in an error message — that boundary is enforced by the code rather than by a policy page, and it has been since we shipped it for site generation 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. The reason there is no lock-in argument to have is that what you would be taking is an ordinary deployable application.
What this is not
It is not a prompt-to-app builder, and the difference is not how fast the first screen appears.
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 app made of forms. It gets you most of the way to a demo and then hands you the part nobody enjoys — the permissions that were only enforced in the UI, the secrets sitting somewhere they should not, the multi-tenancy, the 3am pager. The usual next move is to hire someone who is good at driving Claude or Codex, and spend the quarter you were trying to skip.
Here the intelligence is 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 — not code written fresh for you this afternoon. Composition is why the boring parts arrive finished instead of arriving plausible, and it is why there is no hardening phase between the first version and a real customer.
Fast is table stakes. Being the same thing on week fifty as on day one is the point.
What changing it feels like
You want a new field on a record. You want the intake step split in two. You want the word “case” to read as “matter” everywhere your customers see it. You want a page for a situation nobody anticipated when the portal opened.
You say so. An agent makes the change, and a preview of the result is waiting for you — the actual portal, with your data in it, at an address only you can reach. You look, you publish, and your customers see it. If it was wrong, you say that instead and nothing reaches them.
What you never do is file a ticket, wait for a release window, or find out on Friday that a change also moved something you did not ask about. Every change is one named thing, and every change is reversible.
Three kinds of team this fits
You prototyped it, and it stalled. The assistant works in a notebook. Accounts, billing, a domain and a support inbox are three months you do not have. Keep the idea, skip the plumbing.
You run an agency or integrate for clients. One portal per client, each on its own address — a subdomain we run, or the client’s own domain — each billed and measured separately, none of them aware of the others.
You have a product already, and want an assistant inside it. Put a working assistant in front of your existing customers without rebuilding what you already have.
Agents all the way down
This is the part that is easy to skim past, so it is worth saying plainly.
Agents build the portal. Not a template engine, and not a services team with a backlog — agents trained specifically on Atrium’s library, composing from parts that already run.
Agents ship it. Delivery goes through the same automated fleet that builds and deploys Forge itself: review, tests, deploy, the lot. There is no queue you are waiting in.
Agents use it. The portal that comes out is agent-first for the people who sign into it, and it is equally addressable by their agents — the assistant your customer talks to is an interface a machine can drive just as well as a person can.
Neither you nor we have to sit in the middle of any of that. That is the whole point: a portal is a thing you ask for, not a project somebody staffs.
The honest state
Portals are real and running. The parts they are composed from are in production, the agent-first components work in front of real customers, and the boundary described above is enforced today rather than planned. A portal opens on <your-portal>.atriumdev.app — or <your-portal>.atriumdev.ru for customers who need everything inside Russia — and moves to your own domain whenever you point a CNAME at it.
What is still growing is the library. Everything is composed from blocks 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 will be told, rather than quietly handed a plausible-looking screen. We would rather write that here than have you find it in week two.
Signup, pricing and the documentation all live at atriumdev.app .
Where this sits next to the rest of Forge
Forge is the platform underneath: the agent runtime, the model gateway, the deployment machinery, the site and voice capabilities. You can use it directly — that door is right here , and for a team that already has a product and wants to add one capability to it, calling an API from your own backend is exactly the right shape.
Atrium is the door where you do not have to. Nothing about Forge has to be learned, chosen or wired: what happens instead is a conversation about what your business actually needs your customers to be able to do, and the portal is composed accordingly. The platform is still underneath — it is just not your problem.