Product
Observability & Audit
Every run on the record
What was requested, what was checked, what committed: each run's full path is recorded, not sampled.
Request-level analytics
Every API request is logged and measurable: latency, error rates, volume over time.
Tamper-proof audit
The audit record is append-only. Rewrites and deletes are refused by the storage layer itself, not by application code.
Change history
Definition changes land with a diff and a date, so you can trace exactly when a rule took effect.
A run, as the system recorded it
- Workflow
- Engineer skill review
- Status
- Production
- Built in
- two person-weeks
held = asked and continued · blocked = write refused
- 09:14Follow-up askedheld by quality rule
A thin answer hit the quality rule. The agent asked for project scope before touching the sheet.
- 09:22Publish attempt rejectedblocked by process rule
Publishing was requested before review. The write never landed.
- 09:31Approval openedwaiting on manager
The pending change, its reason, and the affected record went to the manager.
- 09:36Commit recordedsealed outside the agent
The approved write was stored with who, what, why, and when.
They say agentswon't follow rules
They're right — self-restraint doesn't scale. So Perstack doesn't rely on the agent behaving: every operation passes a rule engine, outside the model, before anything commits.
A rule's life
Who writes the rules, where they live, what enforces them, and how they change — the four questions that decide whether control is real.
Written
By you, in plain text. The design AI drafts rules from your description; you read and edit them like any document. What runs is the version you approved.
Where it lives
Inside the workflow definition — not in a prompt. Versioned, with every change recorded.
Enforced
The rule engine checks every operation request before commit. The agent's cooperation is not required.
Changed
As a definition change, with a diff and a date. You can audit when a rule took effect.
Four rules, as written in a definition
- DataAn amount is always positive; an invoice number never repeats
The shape of the data itself — a write that violates it cannot exist.
- ProcessReceived → matched → posted, in that order
The shape of the process — steps cannot be skipped.
- OperationA payment over the cap stops as “Amount exceeds the cap”
Each operation declares how it can fail, and stops there.
- ApprovalCommitting a payment is a person's decision
Where a person decides is written in the definition, not left to the agent's judgment.
Commit control
The model asks. Runtime decides what commits.
Operation intent enters the system, deterministic checks run outside the model, and only passed or approved operations write.
Operation: publish a skill sheet
- Actor
- Interview AI
- Policy
- Write guard
- Commit
- held
- Record
- append-only
1. Intent
from the agent
The agent asks for a named operation, with its inputs and the business state it depends on.
request queued
2. Decision
outside the model
Runtime returns pass, wait-for-approval, or block — before any write reaches the database or a gateway.
pass / wait / block
3. Record
outside the agent
Who asked, what was checked, what happened, and when — stored outside the agent. Append-only is enforced by the database itself: updates and deletes are rejected at the storage layer, not by code an agent could route around.
audit line appended
Commit gate
pending approval
No write reaches the database until the check clears or you approve.
The agent can retry from feedback. It cannot approve its own write.
The harness
every operation passes through here
1. Routine operation
passes → executes
2. Critical operation
approved → executes
3. Rule-breaking operation
blocked → rolled back
AUDIT RECORD
All three outcomes, recorded outside the agent's reach
The incident ledger —which defense stops what
The failure classes teams have actually met with agents, and the mechanism that makes each one structurally impossible here.
Money out the door
Over-cap payments, duplicate payments, paying a fraudulent invoice
Judgment overreach
Deciding credit, HR, or contract calls on its own
Data destruction
Bulk deletes, “cleanups” that hit production
External communication
Mass mis-sends, promising terms to a customer
Confidentiality & compliance
Data exfiltration, skipped credit or sanctions checks
Internal control violations
Self-approval, changes with no trail, cutoff violations
Runaway loops
Retry storms, duplicated orders, exploding API bills
Each tag maps to one of the seven parts on the Product page.
Operating principle
Works exactly as written.Does nothing that isn't.
The agent can reason, ask, retry, and delegate. What exists, what can happen, and what must wait — the definition decides, and runtime enforces.
How we work
We don't ask you to trust the AI.We make the work inspectable.
We say no when a lighter tool fits
If the job is drafting or search, Perstack is not the recommendation — and security, procurement, and data-residency constraints get settled before production starts.
The system comes first
What you evaluate is a running workflow — data, operations, rules together — not a chatbot pretending to operate.
Policy lives outside the model
Prompts may explain a rule. Runtime enforces it before the write lands.
Evidence before scale
You see the definition and the run records before any rollout conversation.