PIES Studio 1.9 · Documentation
The words PIES Studio uses, in the sense it uses them. Where a term means something slightly different here than elsewhere, that is said explicitly.
Application — one product you are building: its data, its screens and its logic, versioned and deployed as a unit. Everything else on this page lives inside an application.
Application definition — the stored description of your application. Not code: a structured document that PIES Studio compiles into code every time you build. Editing on the canvas edits the definition, and so does PIES AI.
Workspace — the list of applications you can open, and the place you create new ones.
Explorer — the tree on the left of the editor: screens, the data model, events, functions and everything else the application contains. If something exists, it is in the explorer.
Data model — all the tables in one application, and the relationships between them.
Table — a collection of records of one kind, with typed columns. Tables become real database tables when you build.
Column — one typed field on a table. The type matters: it decides what widget a form uses and what a filter can do.
Relationship — a link between two tables, so a record on one can refer to records on the other.
Record — one row. The step types that read and write rows (Find Record, Find Multiple Records, Set Record Value, Save Record) are the only way an application touches the database.
Screen — one page in your application. Screens hold widgets and can run an event when they open.
Widget — one thing on a screen: a table, a form, a button, a chart, a container, a text block. Widgets have style (where they sit, how big) and constraints (what they are bound to).
Binding — the link between a widget and the data it shows. An unbound widget renders empty; that is the single most common reason a screen looks blank.
Drawable area — the usable width of the canvas, once the editor's own panels are accounted for. A widget pushed past its right edge is off-screen in the built application even though it looks fine while you drag it.
Custom widget — a view PIES Studio has no built-in widget for — a calendar, a Gantt chart, a specialised layout — written as a code block and given data by the screen.
Code block — the code inside a custom widget. It receives data through named parameters; it does not fetch its own.
Event — something that happens in response to the user or the screen: a button click, a row click, a screen opening. Events drive the interface and call functions; they do not write to the database themselves.
Function — reusable logic that does the work: reading and writing records, calculating, calling out. Functions contain no interface steps.
Step — one instruction inside an event or a function. Steps are linked in order, start to end.
Onload event — the event a screen runs when it opens. This is how a widget that needs data gets it before the user sees the screen.
Build — generating the complete application from the definition and compiling it. Build produces real source code, not an interpretation layer.
PROBLEMS — the panel listing what the build found. Read it before the preview; see the error reference.
Preview — your built application, deployed and running, with a real database. Not a mockup and not a simulation.
Deployment — publishing a built application somewhere it stays running.
PIES AI — the assistant inside the editor. It edits the same application definition you do, through the same rules.
Plan — what PIES AI proposes before it changes anything. It waits for Continue so you can correct the plan rather than the result.
Build receipt — the list of exactly what a PIES AI run changed. The authoritative record of the run.
Rewind — undoing a PIES AI run, taking the application back to before it. Rewinding removes what the run created, so anything you built on top of it goes too.
Pie Loop — the automatic repair cycle: when a build fails, PIES Studio feeds the errors back and tries to fix them, repeating until the build is clean or it cannot make progress.
Artefact — a file or document produced by a run and attached to it.
These terms match chapter 15 of the Agentic AI manual, which shows each one on screen.
Agent — an operator design: brief, access, triggers and guardrails. It becomes a post when you post it on an environment, and it never changes the app's design. Builders are not agents; build work is a delivery.
Post — an agent running on one environment, frozen at a version, on an agent seat. Post again puts a newer version live; Fire ends it. The same agent can be posted on several environments at once, each post independent. Until you post again, edits to the brief, access, triggers and guardrails change nothing on the running agent.
Playbook — rules plus ordered steps for build work, run by a delivery. Each step has a role, the tools it may use, a model tier (Small, Mid, Strong) and whether it runs once per delivery or once per card. Stock ones: Full delivery route, One builder and a verifier, Fixer, Self-improvement loop. Nothing in a playbook is posted, versioned or seated. The API still calls a playbook a squad and its rules a charter.
Delivery — build or change work on one app and one branch, with a board of cards and a baseline to roll back to. Its status is Running, Paused, Awaiting decision, Stopped, Done or Failed; a delivery you stop is Stopped, not Failed. Deliveries were called missions before 1.9.
Errand — one action on a running app: one run, nothing standing. An errand always runs Supervised.
Card — one requirement on a delivery's board, with acceptance criteria the Verify step can probe.
Run — one bounded conversation between the model and the app's tools, with a budget of iterations, minutes and tokens. Deliveries, errands and posts are all made of runs.
Activity — the one feed of everything running and everything waiting on you: Needs you, Running, Today, Failed and Everything.
Environment — a deployment of an app: where posts live and errands act. A post cannot be placed on a preview.
Brief — an agent's job description, and the only place an app agent's instructions live. Written in New agent and under Configure → Brief.
Runs as — the app access group an agent acts as. The app enforces that group's permissions on everything the agent does, including which tables it may read directly.
Autonomy — what parks for approval. Supervised (default) parks any call that writes; Autonomous never asks; Locked down parks every call, reads included. Who is asked decides where a parked call goes: whoever posted it, the app's operators, or named people.
Role — the label on the roster, worked out from what the agent can do (its reach and its triggers). There is no Role picker.
Start work — the one door into deliveries and errands: from the Activity header, an app's Deliveries tab, the chat's Build something menu, New agent's Build or change an app card, and Start delivery on a playbook.
Cockpit — the view of a delivery: header and status, brief and board, the route of steps, the live trace with a box to steer the running step, and the actions.
Worker — what runs one playbook step in a delivery, in its own context. It is not a record and does not remain when the delivery ends.
Allow for the rest of the run — approving an action and not being asked about it again until that run ends, unlike Always allow, which adds a standing rule to the agent.
Wait window — how long a parked call waits for an answer: 5 minutes for Run now and 15 minutes for scheduled runs, events and errands, unless the agent sets its own. Unanswered, the change is skipped and the run carries on to its report.
Compaction — at three quarters of the iteration budget a run folds its history into a handover and continues, up to three times. A run still at its step limit after that stops as Paused and waits in Needs you; Resume continues it.
Local IDE — the editor running on your own machine. It ships in every plan; what changes is what it connects to. Download it at pies.io/download; see the manual, chapter 2.
Hobby — the free plan: the full editor, offline, no account. See PIES Studio Hobby.
Enterprise — PIES Studio installed on infrastructure your organisation controls.
PIES Private AI — the AI engine running inside your own network, so no prompt and no application content leaves it. See the Private AI manual.