The platform
Eight primitives. One way to plug them in.
Everything the agent builds for you, whether integrations, logic, data or screens, is made from eight primitives. Standard building blocks that are all defined the same way and plug in the same way. Every action they take is signed into the same audit log. That's why the agent can build your system and run it in the same environment and why you can inspect any part of it the same way. This is the spec sheet behind the front page. How it works, not how it's pitched.
The primitives
Everything you run is made of these eight.
A primitive is a building block the agent can build and put to work in the same environment. There are no others. This is the whole catalogue.
01 · task
Where work happens.
One job, held in one place. The state, connections, logic and screens it needs. Add the agent and the task gains a builder. Remove it and the task still runs.
02 · connection
One doorway per system.
Stripe, Gmail, Microsoft 365, or any API with published documentation. The agent sets up the connection live. It reads the API's definition, checks what permissions it's been granted and puts it to work in the same environment.
03 · codeLibrary
Your rules, as tested code.
Business logic written as typed code and verified against how your systems actually respond before anything is committed. Grounded, not guessed.
04 · customData
Tables you own.
Your records in your own database, in tables you approve before they're created because schemas are hard to change once data is in them. Actual rows, plain SQL.
05 · app
Screens your team clicks through.
The agent drafts an app, tests it until it runs cleanly, and saves it. Built in minutes, in use the same day with no release cycle and no second tool.
06 · taskStore
Memory you can see.
Everything a task knows lives in one structured, versioned store, not a context window. The agent reads and writes it by address. You see the same data as panels, tables and forms.
07 · schema
One contract for everything.
A single set of definitions describes the data, screens, actions and approval gates. The agent sees exactly the actions your team sees so it can't invent ones that don't exist.
08 · sysConnection
The platform is a primitive too.
Users, access, schedules and billing. Panaptic's own controls plug in like any other connection. So the agent can help manage the system it runs on within the permissions you grant and with changes waiting for your approval by default.
Eight primitives isn't a limitation. It's why everything fits together and why the agent never meets a part of your system it can't read.
See what teams build with themThe AI is a connection too
The agent plugs in the way Stripe does.
The AI isn't a sidebar bolted onto the tool. It's a connection you add to a task, alongside your payments and your customer table, set up and governed the same way as everything else it touches. That's why one agent can do three jobs. Run the work, build new parts of your system, and help manage the system itself. Always within the permissions you grant.
- It can only use what exists. It works from the same catalogue of actions your team sees so it can't call anything that isn't there.
- It's optional, task by task. Remove the agent and the task is just software and it still runs.
- Bring your own model. Use your own API keys for any LLM provider, set per organisation. Mix a frontier model for building with a fast one for high-volume work.
// same shape, same import, same audit log
On the record
Signed by whoever took it. Every time.
A person approves an invoice. The agent sorts an email. The scheduler runs the nightly reconcile. All three are recorded in the same log, the same way. The actor, the action, the inputs, the moment. Building is recorded like running. When the agent registers a connection that's a signed action too.
- Nothing free-form. Every entry maps to a defined action.
- Safe to retry. Actions are idempotent so anything that must only happen once can't happen twice.
- Not a feature you switch on. The log is the layer everything runs through.
Included
The infrastructure is already on.
None of this is installed, provisioned or deployed. Every capability below is there as soon as your organisation is, governed by the same actions and the same audit log as everything you build.
scheduler
Scheduled work
Run tasks on a clock, using cron or calendar rules, with state that survives between runs. No server to keep alive.
postgres
Your own database
Every organisation gets its own PostgreSQL database. Your tables, standard SQL, isolated from every other organisation.
sql
Query anything
Query your tables, join live API responses, or read archived files in a bucket, with one language across all three.
documents
Documents & PDFs
Reports render from templates so layouts live where you can change them, not buried in code.
blobs
File storage
Durable files with signed links, managed for you or pointed at your own bucket.
spend
Spending caps
Set caps in dollars per person, team or organisation, by task, day, week or month. One bad run can't blow the budget.
observability
Observability
Logs, traces and errors for any past run. Exportable to the stack you already use.
models
Bring your own model
Your own API keys for any LLM provider, including Claude and Gemini, set per organisation. Mix tiers to match the work.
Where your data lives
Typed records by default. A data lake only if you need one.
customData
Your records
CRM rows, cases, invoices, config. Typed tables in your own database. Most reporting is a direct query against them so you don't need to build a pipeline to read your own records.
duckdb
Archived files, queried in place
Point a connection at Parquet or CSV files in a bucket and query them where they are. It's built for large analytical data that doesn't belong in your operational tables.
Panaptic isn't a data warehouse and it won't make you build one just to answer a question.
Begin
Watch it build. Then run it.
Open a workspace, describe one thing your business does and watch Panaptic build it and run it in the same environment.