SeamAI Pro Builder: a production agentic system, and what running it taught us
This is the platform we point to when someone asks whether we have run AI agents in production. We built it, we operate it, and anyone can sign up and use it. What follows is how it is put together, the rules it runs under, and two things we got wrong.
- Agents
- a coordinator and eleven specialists
- from the delegation tool catalog
- Data model
- twenty-four tables
- from the database schema
- Regions
- Europe (Nuremberg, ARM) or the United States (Ashburn, x86)
- from the region table
- Per project
- its own server, PostgreSQL database, hostname and TLS
- from the provisioner
- Way out
- ZIP export, or push to GitHub
- from the workbench
- Tests
- about five thousand automated cases
- from the test run of 7 September 2026
What it is
A user describes an application in chat. The system writes the files, installs the dependencies and starts a development server, all inside the browser, so the person watches the app come up as it is built. They can edit any file, open a terminal, and keep chatting; the model works from the current state of the project. When the app is ready, it ships to a free static host, to a cloud server with its own PostgreSQL database and domain, or out of the product entirely as a ZIP or a GitHub repository.
How it is put together
The browser holds the chat, a code editor, a terminal and an in-browser Node runtime. A single web application serves the chat stream, authentication, the cloud API and the admin panel. Behind the chat sits the AI pipeline: it analyses the prompt, picks a model by the task rather than by a fixed setting, decides whether the job needs the agent team, assembles the system prompt from the project's files, and streams tool calls back to the browser to execute.
Behind the cloud API sits the provisioner. It creates a server, installs PostgreSQL, creates the project's database, deploys the code over SSH, sets the DNS record and obtains a certificate, and it does all of that in two phases so that a failure part-way rolls back what it already created. Billing is metered through Stripe: a flat price per server size and usage-priced model tokens.
The agent team
“Agents” here means eleven named jobs, each with its own instructions, that a coordinator can delegate to on complex tasks: an architect, a database specialist, a test writer, a staff reviewer and the rest. The coordinator is the only one that talks to the user. Most requests never need the team; the pipeline gates it on the shape of the task so that a one-line change does not pay for a committee.
The guardrails it runs under
The rules we sell to clients are the rules the platform runs under. Anything that spends money or creates infrastructure, such as provisioning a server or registering a domain, requires a confirmation token that the server issues to the person; the model cannot confirm on its own. Every provisioning step has a rollback. Every deploy is a numbered release with a health check, and the previous release is one command away. The logs say what was done and by which step.
Two things we got wrong, and how we found them
In September 2026 we audited every sentence of the product's marketing copy against the code, line by line. Two findings are worth telling a client about, because they are the kind of thing an audit finds and a demo does not.
First: the “take over in the editor” promise was only half true. Edits made in the editor updated what the model saw, but never reached the running project, so they were absent from every export and deploy. The fix was a small piece of plumbing and a set of tests that pin it. It shipped the same day, and the copy now describes what the code does.
Second: the deploy process was a hand-run checklist. Moving it to a single script with a fresh build directory, a health check and an automatic rollback turned up three more defects on the first run, each of which the old process would have hidden until a bad night. That before-and-after is the workflow diagram on our home page, because it is the most honest example we have of what automating one process looks like.
What it means for a client engagement
The stack, the habits and the guardrails are the same. When we say an agent will have task boundaries, a log, an approval step and a rollback path, that is not a slide; it is how the thing we run every day is built. And when we say you will be able to leave, the export button exists because we use it.