Definition
What an AI-nativebusiness system is
The contents of a business system haven't changed in thirty years: data, operations, rules, approvals, records. What changed is the operator. A conventional system is built for people at screens, with AI bolted on outside. An AI-native system is built for an agent that calls permitted operations through a rule engine — and the screen becomes optional.
The structural difference
Same work, opposite construction. Below: the operations a team grinds through a UI on the left, and the same operations run by the agent inside the system on the right — with people approving the calls that count.
AI-native business system
Agent (AI)
Credit-limit change
awaiting approval
UI, optional and headless
Anatomy
The seven parts,and what each one refuses
The agent never floats free. Every component around it exists to make one class of failure structurally impossible.
The harness
Agent (AI)
every operation -> Rule engine
follows / reads & writes / external calls / learns & recalls / delegates
Dedicated database
Each workflow's data lives in its own isolated database. The agent never touches it directly — only through operations.
Named operations
The only write path that exists. Named, typed, with declared failure modes. Nothing else can be called.
Rule engine
Every operation request passes through it before commit: caps, separation of duties, state transitions. Pass, wait, or block.
Approval checkpoints
The decisions you name wait here for a person. The agent cannot approve its own write.
Audit record
Who, what, why, when — appended where the agent can't reach, never rewritten.
Gateway
The only door to external services. Credentials live here, never with the agent.
Agent
The worker: instructions and memory, requesting operations, retrying from feedback — inside this box.
What “headless” means
Not that there is no screen — that the screen is optional. Operations exist as APIs and definitions, so the operator can be a person or an agent. That is the entire trick that makes an AI operator possible.
- Inside your product
- Inside internal tools
- In chat
- No interface at all
It is also why you'll find almost no product screenshots on this site. The thing worth looking at isn't a screen — it's the workflow definition and the run record, and you can read both on the proof page.
So what do you actually get?
Concretely — what arrives when you sign up or send us a workflow:
A hosted platform
Perstack turns your description into a workflow definition, then provisions and runs the system behind it: a dedicated database, its operations, its rules.
Studio
The management surface — where you read definitions, approve what's waiting, and follow run records. One of the optional screens, not the system itself.
Two ways in
Self-serve: start on Starter or Pro and describe the work yourself. Or send us the workflow and we build the first definition with you.
Why nothing worked so far
The two dead ends
Everyone putting AI into operations hits the same two walls. Both are the same problem underneath: whose process, and whose rules.
Vertical AI products
The dead end
The rules come predefined — for the vendor's idea of your process. You migrate onto their standard, customize your way back, and re-justify your internal controls from scratch.
On Perstack
Perstack builds the system from a description of the process you already run. Nothing migrates; your controls stay your controls.
The test: Is their “standard process” actually yours?
General-purpose agents
The dead end
Your process can stay — but the agent won't follow your rules. Making it obey means building a custom harness, which takes someone fluent in both your operations and agent engineering. Those people are almost never on your payroll.
On Perstack
The harness is the product. A built-in rule engine enforces your rules on the agent — nothing to build, no one to hire.
The test: Can the agent break a rule if it tries?
Getting started
Bring one workflowthat already hurts
Rough notes are enough. No requirements document, no process map, no company-wide AI plan.
What to send
The workflow
What starts it, what finishes it, which handoffs make it slow.
One hard rule
The thing the AI must never do.
The system edge
The database, SaaS, or internal API it reads or writes.
What comes back
A short memo, before any commitment:
- Fit or not — if a lighter tool is enough, we say so
- A first definition: trigger, finish line, rules, approvals
- A sample of the run record you would inspect
Before you buy
Fit
Pick one operation
We map it into a first definition together. If it does not fit, that is the answer.
Month 1
Production
Core workflow live
Schema, integration, core operations — about 2 person-weeks of build.
Month 2
Steady state
Exceptions and routine
External edges, exception paths, monitoring, and the runbook.
Give AI one workflow.It can't break your rules.
Rough notes are enough: what starts it, one rule that cannot break, the system it touches. A short memo comes back — fit or not, a first definition, a sample run record.