Give your agent a login, not the keys to everything.
You wouldn't give a new hire every password and no rules. Semantius gives your agent what a good employee gets: its own login, the records it needs, clear steps, and someone who approves what matters. Your people work in the same system, in the browser on their phones.
Where agents struggle, and what Semantius does about it
Semantius is the system of record your AI agents work in. Agents are good at understanding what you want, and bad at being exact, careful and consistent every single time. Semantius catches some of those mistakes, such as invalid values, broken links and steps or actions your rules forbid: your agent proposes, and the rules you define decide what reaches your records.
It forgets between sessions.
Every session starts cold, so field names, formats and conventions drift, and each agent's notes become a memory nobody else can use. In Semantius, every record type, field and relationship carries its description, and your agent can read the model at the start of every session, so each session can start from the same understanding, as good as the descriptions in it. What one agent records, the next agent and your team see too, as far as their role allows. It helps your agent find its way; it doesn't make it right.
It sees your business in pieces.
When customers, orders and tickets live in different tools, your agent matches them by name and guesses the connections. In Semantius, the records your business runs on live in one connected model, linked by ID, with full-text search across them, once your data has been moved in. There are no built-in connectors to other tools.
It writes what looks right, not what is right.
A status spelled differently, an ID that doesn't exist, a total added up wrong. Semantius checks every write against your rules, your value lists and the links between records, so invalid values and broken links are refused, and totals and other derived values can be computed by the database instead of by your agent. Your agent writes records, not whole files. A value that passes your rules but is wrong still gets through, picking the wrong existing record is still possible, and two writes to the same record can still overwrite each other.
It follows your rules most of the time.
A rule in a prompt fades over a long session, and text inside a record can try to override it. In Semantius, the rules live in the database and are checked on every write, from any app, API or agent login, and text in a record can't widen what a role allows. What the agent can still do is whatever its role allows, which can be broad. When a change is refused, your agent gets the reason and can look up who has the permission. Self-hosted, direct database access bypasses these rules, and so does a database owner or superuser.
It does more than you asked.
"Clean up the pipeline" can turn into deleting deals. In Semantius, each agent works under its own login and role, and records move only through the steps you've set up. Human-in-the-loop approvals mean that, where you've set them up, only the right person can move a quote, a purchase request or a client sign-off on. A wrong action that its role allows still goes through.
It sees more than it should.
A folder or a shared spreadsheet has no permissions, and an agent with one broad key sees everything: prices, payouts, every client. In Semantius, each agent and each person reads only what their role allows, checked in the database for every app, API and agent login, where you've defined it.
Afterwards, nobody can tell what it did.
Work done while nobody watches spreads errors before anyone notices. In Semantius, every change to data and to the model is logged: who made it, person or agent, and when. It tells agents apart when each agent has its own login.
It has to know when to act.
An always-on agent checks in regularly, but it needs to know what changed. Semantius puts the changes that matter, such as a new record, a status change or an approval waiting, into queues with event and rule triggers, and your agent picks them up on its next check.
Deterministic checks, bounded outcomes
The same change, from the same role, against the same record, always gets the same answer.
Guaranteed, where defined
- Only valid data under your rules
- No broken references
- Only defined steps
- Only the allowed role takes a step
- Only the person who has to approve can approve
- Every change logged
- No app, API or agent login can go around the rules
Not guaranteed
- That the agent chose the right action
- That a valid value is the right one
- That a role doesn't take a wrong action it's allowed to take
- Protection from a database superuser or table owner, who can bypass row-level security
For IT
- Every agent your staff bring meets the same rules
- Who changed what, and when
- People sign in with their Microsoft 365 or Google account
The visual face of your agents
Your agents work through the API; your people see the same records in the app generated from the model, including every change an agent made.
One definition. Three outputs. No code.
Active data dictionary
"Set up quotes for our clients. I approve every quote; you prepare them."
The model view the agent built from this request: the entities Clients and Quotes, the fields of Quotes, the steps a quote goes through, the two roles and what each may do. Not supplied yet.
The one rule: hours must be greater than 0, as written in the demo workspace. Not supplied yet.
The app screenshot: the quote form generated from the model, with the owner's Approve button. Not supplied yet.
The refusal: the agent tries to set a quote to approved, and Semantius refuses it, with the reason as the agent receives it (the missing permission). Not supplied yet.
The log entries: who did what, person or agent, and when. Not supplied yet.
The agent prepares the quote, but its role can't approve it. The owner approves it from their phone, and every change is on record.
Specification
The specification of Semantius as a secure database runtime for LLMs and AI agents.
| Database | PostgreSQL 18+ |
|---|---|
| Implementation | 100% PL/pgSQL, no external dependencies |
| Business rules | Extended JSONLogic, stored and evaluated in Postgres; used for validation, computed fields and attribute-based access |
| Access control | RBAC and ABAC, row-level security on JWTs, enforced for every caller |
| Data model | Entities with descriptions; relationships with cardinality; subtypes and extensions |
| Lifecycles | State machines with permission gates |
| Audit | Every change to data and to the model |
| Events | pgmq queues with event and rule triggers |
| Search | Full-text search |
| Access | PostgREST API; the CLI and agent skill for any agent that can run commands |
| App | React app generated from the model, in the browser on any device |
| Sign-in | OAuth2/OIDC with PKCE. Cloud: Google and Microsoft 365 accounts. Self-hosted: Microsoft Entra ID or any JWKS identity provider |
| Agent skills | Business analyst and data architect playbooks the agent works from |
| Backups | Cloud backups; point-in-time restore coming soon |
| Self-hosting | Docker Compose and Dokploy |
| License | MIT |
| Tests | 3,000+ pgTAP tests |
Let your agent do the routine work
Tell your always-on agent, such as Meta Muse, OpenAI Dots or Grokbot, what your business runs on. It sets everything up under its own login, keeps your records current and moves work to the next step. Your people get the app in the browser on their phones, each seeing only their part, and they approve what matters.
Start from one of these
Your agent works from a business analyst's and a data architect's playbook, so it sets up the records, the rules and who sees what properly.
A client-and-project tracker for your agency
Set up a client-and-project tracker for my agency in Semantius: clients, projects, deadlines and client approvals. Each team member sees only their own clients. Import our client list from this spreadsheet.Turnovers for your rentals
Set up turnovers for my two rentals in Semantius, shared with my cleaner and my co-host. The cleaner sees only her turnovers and checks them off on her phone.A punch list you share with your builder
Set up a punch list in Semantius that I share with my builder. Each item has a room, a description, a due date and a status. The builder can mark items done; only I can close them.
- Rules and validation
- Row-level security TBDNo docs page exists yet.
- The CLI