What's new in PIES Studio 1.9

PIES Studio 1.9 is the release where the platform learned to run work for you, not just with you. Agents are posted on an environment and supervised from one feed, a delivery running a playbook step by step builds and changes applications, and the new Agentic AI manual shows every screen; every application gets enterprise sign-in without leaving the editor; and a template store puts 35 finished industry applications one click away. This page covers everything since 1.7, so it includes what 1.8 introduced.

If you are upgrading an installation, read Upgrading as well — the upgrade steps have not changed, but the notes below on sessions, templates and previews affect what you will see afterwards.

Agents, playbooks and deliveries

Agents arrived in 1.8. In 1.9 the whole area was rebuilt around three kinds of work — a delivery changes an application, an errand does one thing to a running one, a post stands watch on an environment — with three entries under Agents in the sidebar (Agents, Playbooks, Activity), one door into all of it, and one feed where every kind reports.

The Agentic AI manual is new. The Agentic AI manual walks through every agent screen with pictures: New agent, Configure field by field, posting, playbooks, the delivery control panel, errands, approvals, templates with test data, and troubleshooting. The Agents page is the concepts in brief.
Design in the editor, operate on the deployment. The editor's Build → Agents holds an app's agent designs: brief, access, triggers, guardrails — with no Post, Pause or Fire there. The deployment page's Agents tab is where you post an agent, run an errand, pause, resume and fire. The Studio sidebar's Agents lists every post across apps.
New agent is Who, Brief, Freedom. From inside an app, Who is already answered and it walks two steps. Freedom sets autonomy, the access group it runs as, its reach and when it runs. There is no Role picker: the role on the roster is worked out from the agent's reach and triggers. The Build or change an app card opens Start work for a delivery.
Posts per environment. Posting freezes a snapshot of the brief, tools and guardrails, takes an agent seat and arms the triggers. The same agent can be posted on several environments at once, each post independent. Brief, access, triggers and guardrails reach a running agent only when you Post again; pause, resume, tool auto-allow and memory apply at once. Firing one post stops only that environment's runs; a post cannot be placed on a preview.
Autonomy is Supervised, Autonomous or Locked down. Supervised (the default) parks writes for approval, Autonomous never asks, Locked down parks every call. Who is asked sends a parked call to whoever posted it, the app's operators, or named people.
When nobody answers, the run carries on. A parked call waits 5 minutes for Run now and an hour for scheduled runs, events, webhooks and errands, unless the agent sets its own window. Unanswered, the change is skipped, the agent is told, and the report ends "1 change was not approved, so it was not made."
Approvals you can read before you answer. An approval card shows who started the run, the function or query with its parameters, the agent's reason, the steps so far and a link to the run. Allow, Deny with a note the agent reads, Allow this for the rest of the run, or Always allow. Every decision is written into the run, signed.
Webhooks and app events per post. An app event runs within seconds when a deployment or build fails or a bug is reported from the preview. A webhook's signing secret is issued at the first post and kept by Post again; its endpoint runs every unpaused post of the agent, and ?deployment_id= calls one environment's post.
Runs as an access group. An app agent acts as one of your app's access groups, and the app enforces that group's permissions — including which tables it may read directly. Rows it writes are signed PIES Agent · <group>. Each deployment issues one credential per access group.
Errands are new. One action on a running application, one run, nothing standing — started from Start work or Run an errand on a deployment. An errand always runs Supervised; approvals go to you and the environment's operations approvers, and the first answer decides.
Playbooks have their own page, and every workspace starts with three. Rules plus ordered steps, each with a role, tools, a model tier of Small / Mid / Strong and a per-card toggle. Full delivery route, One builder and a verifier and Fixer are marked Stock. The page has a workspace bar, search, a Stock / Made here filter, sorting, and Start delivery on every row.
A fourth stock playbook, the Self-improvement loop, needs no brief. Start it on a built application and it audits the app, files each finding as a card with an exact probe, fixes and verifies each card, and leaves a GUARD block on every closed one. The next run re-probes those guards first, so what it checks only grows, and a Reflect step ends each run with a scorecard card and up to three proposals for you to apply.
Deliveries run their playbook, in a delivery control panel. Each step is a worker in its own context, handing over through the board's cards. The control panel shows the header and status, brief and board, the Route of steps, a Live trace with a box to steer the running step, and Pause, Resume, Stop, Retry, Skip, Roll back and Delete. Status is Running, Paused, Awaiting decision, Stopped, Done or Failed — a delivery you stop is saved as Stopped, not Failed.
Every run that ends short says why. Stopped by you, Replaced by a newer run, Ran out of time, Waited for an answer and gave up, Interrupted by a restart, Environment unreachable from the platform, or the last tool error. After a restart an interrupted delivery offers Run again.
Budgets and long runs. Iterations, tokens and minutes per run, and monthly tokens; at its monthly limit an agent is not started at all. At three quarters of its iteration budget a run compacts its history and continues, up to three times.
Templates come with agents and test data. Every system template installs an agent pack and sample data shaped so the agents find something on their first run; the gallery's What the agents will find names the rows. The agents are posted for you when the app is deployed.
Publishing keeps your data. Changing the data model and publishing never deletes data or reloads sample rows over it. Removed tables and columns stay in the database and are listed under Your data was kept; a type change that could lose data is refused.
Building a preview warns before it resets the data. A preview Build reloads the preview database from your Data tab rows, so records added or changed in the preview are lost. Build now asks first — This resets preview data to your Data tab rows — with Cancel, Build and Don't show again. Don't show again applies to that application only, and Show dismissed warnings again on your Profile brings the question back. Building for a deployment does not ask, and publishing keeps data as before.
Activity is the one feed. It replaced the Comm Center, the inbox drawer and agent notifications: Needs you, Running, Today, Failed and Everything, filterable by kind.
The API keeps the old word. Playbook endpoints are still /agents/squads/… and the rules field is still charter on the wire. If you script against PIES Studio, nothing you wrote for 1.8 changes.

See the Agentic AI manual, the Agents page and chapter 10 of the user manual.

Authentication is now configured once on the application, in Users & Access, and every deployment inherits it; an environment can override which methods it offers.

Sign-in methods: password, Sign in with PIES Studio, Microsoft, Google, Apple, OpenID Connect and SAML — as cards, in a guided, numbered setup.
Sign-in policy: SSO-only, allowed email domains, and whether self-registration is open and which group a new account lands in (never an administrator group by default).
Session policy: session length, single logout, two-step verification for password sign-in, and group-mapping rules per provider so an identity provider's claims decide the access group.
Set Password is a designed screen like Login and Register; forgot-password sends a real email that opens it. Previews and builds carry an email server so this works before deployment. The Forgot Password screen tells you what happened when you press Send: it asks for an email address if the box is empty, and shows a red message when the email is not registered or the application has no email server set up, or a green one when the reset email was sent.
No default administrator password. You set the application's administrator password in Users & Access; Open as administrator on the deployment page signs you into a running application without it.
Invite user under Users & Access gives someone access to a deployed application: pick their email, access group and deployment, and they receive an email to choose a password. The App users list shows who has access to each deployment.
Switch role in a running application. A user in two or more access groups gets a role picker beside their name in live preview and deployed applications: All roles, or one group at a time. The application narrows screens, menus, functions and data to the chosen group on the server, and signing in again returns to all roles.
A built-in Public access group lets guest users reach data, so a storefront or a public catalogue can exist.

Access model — teams, roles and operations

Teams and roles you can actually change: roles are presets of capabilities, and a person's capabilities are their role plus explicit grants. Invite people as a role, not with an administrator checkbox, and invite people who do not have an account yet.
Operations grants. An Operations panel on the deployment says who runs an application; hand operations over in one act, and the people who run an application can read it without a build seat. Agents inherit their application's operations grants, and their approvals route to whoever runs the app.
The navigation follows your capabilities: what you cannot do is not shown.

Template store

The template gallery became a store: browse by category, open a template to see screenshots, What's inside (screens, tables, roles, functions, documents) and About, and install. Every bundled agent is an operator, posted on an environment of the installed application when you deploy it, never a builder — and each template's sample data is shaped so those agents find something on their first run; dates the agents judge against are set relative to the day you install, so a "due next week" row never goes stale. The catalogue is exactly what ships: a renamed or duplicated entry (an older "Courier & Delivery" beside "Courier and Delivery") is retired on start-up, and applications already installed from it are untouched. Thirty-five finished industry applications ship with the platform — hospitality, fitness, beauty, trades, professional services, education, events, logistics, telco site monitoring and field events, visitor management, retail banking analytics and more — each with sample data and, where useful, a bundled agent pack that is installed with it. Sample rows with no value are stored as empty, not as blank text, so they never link to a record by accident; and in Telco Site Monitoring and Alarm Correlation an incident added without an IM number is given the next one automatically (IM numbers are required and unique). An application installed from an earlier version keeps its data until you install the template again. A template that needs an external system finishes with its own connect flow and offers the integrations you have already saved. The store opens instantly and remembers the gallery for the session.

The navigation is two layers grouped by what you are doing: Build (Applications, Library), Agents (Agents, Activity), and the rest; pinning the rail keeps both visible inside an application, and Agents is one click away from inside an app.
Workspaces moved into the applications page as a pill bar: one row at any scale, application counts on each pill, overflow behind a searchable +N more. Each application shows how many agents it carries.
The explorer colours objects by kind, demotes folders and draws indent guides; dropping onto a folder nests into it.
Getting started: a first-login tour of the workspace and the editor, a Getting Started checklist that ticks itself off as you create, model, build and run, and Help → User Manual links that open the matching chapter of this documentation. Press ? for shortcuts.

Application chrome, theming and the home page

Header Builder. The header's brand column now matches the sidebar exactly; text colour, divider colour and divider thickness are editable, with automatic defaults. The Menu tab previews the header with the same renderer as the canvas, and a dark header gets a logo tile.
A new application starts with a Home Page — a welcome band, three get-started cards and a PIES AI tip — and opens on it with the canvas fitted.
The generated React application now matches the IDE canvas — one dark surface, sidebar brand block, page-title header, quieter menu — so what you design is what you ship.
Chatbot appearance for the in-app assistant is a form with a live preview under the application's settings, and the widget follows the app's theme tokens. Templates ship with the chatbot enabled.

In-app notifications

A Notify User step in the Comms group sends an in-app notification — title, body, parameters and actions, with variables interpolated — to users of the generated application, which now has a notifications API and a header bell whose click routes on the notification's id.

Building, previewing and deploying

Previews start faster: a shared dependency cache is cloned into each new preview instead of a cold install; dependency installation has its own clock and a timeout is never mistaken for corruption.
Previews are capped and admitted: every preview container is limited in memory, CPU and processes, and a preview host refuses new previews past its capacity rather than degrading the ones already running.
Deployments say what they are serving. An active deployment on a stale build carries an amber Serving previous version badge; a failed publish that keeps the old version up no longer looks healthy. Deployments have an Agents tab, and hosted deployments expose container logs and stats.
The data model is validated during the build, not at deploy; foreign keys index their parent column; a dropdown whose option columns do not resolve refuses to generate.
Mobile builds survive restarts and reach the backend from a real phone; the Show Message step honours the editor's custom input on React and Flutter alike.

Data and external sources

An external source with no credentials prompts for them, and supplying them finishes the source rather than creating a second copy.
Joins work against a schema-qualified external source; the schema stays recoverable when a source is disconnected.
Chart filters reject an unknown operator instead of silently dropping it.

AI governance

Heavy work — screen authoring, architecture — is routed to the strongest model your policy allows; that routing is policy data, not something the engine decides on its own.
Governed calls are attributed to the agent that made them, embeddings no longer bypass governance, and one subscription is one governance regardless of how the tenant is addressed.
Scanned PDFs uploaded to the Knowledge Base or as artefacts are read by Claude only when your AI policy allows it; every attempt is audited, and under Air-Gapped the document is refused rather than sent out.
Every AI build now runs on the current build engine (plan, build, then check). The Build engine choice in AI Settings is gone: the page shows Build engine: v2 for reference, and an earlier setting that picked the previous engine is ignored. Builds are governed the same way throughout: the same request selects the same model, is redacted the same way and writes the same audit record, and Claude calls record their token usage so they count towards token budgets.
The policy Test Console lets an administrator try a request against the policy stack and see which rule answered.
Personal-data detection now recognises international and local phone formats (such as +61 412 345 678, (02) 9876 5432 and +44 20 7946 0958), Australian Tax File Numbers and Medicare numbers (with their check digits), and labelled dates of birth. Requests containing them meet your personal-data policy rules and are masked as [REDACTED:phone], [REDACTED:tfn], [REDACTED:medicare] or [REDACTED:dob]; ordinary dates and counts are left alone.
The audit log records a request as redacted only when a policy actually masked it; a request whose policy has no redaction set is recorded as allowed.
A question in the AI chat that says not to change the app (for example "Do not change the app") is answered in the chat, even when its wording mentions things like cards or phones, instead of starting a screen build.
Asking the AI for an empty screen, or a screen with just a heading, builds exactly that: one heading section, without the getting-started cards it adds to landing pages on apps that have no tables yet.

For administrators

Sessions survive restarts. Signing keys are stored in the platform database, so replicas share one key set and a restart no longer signs everyone out.
Templates ship in the image and are seeded on first start, so a fresh installation has the full catalogue without a network fetch.
Applications with timestamps written by older tools are repaired on start-up; an application that fails to load now logs the real reason instead of not found.
Deleting an application deletes its agents; an application belongs to the tenant in the session, never the one in the URL.

Fixed since 1.7

Among the tickets closed from the preview programme:

Table default length, database menu not closing, and the function error tab.
Add Record did nothing on a new or template table.
A phantom duplicate section header in the explorer after an AI build.
Dropping an item onto a folder reordered it as a sibling instead of nesting it.
The configure popup loaded functions without their real context; its dropdowns render above the dialog and the action-type selection registers.
Dragging a panel blanked the canvas; a widget resize can no longer store an invalid size.
Saving a code block with non-Latin characters.
The PIES AI panel opens regardless of module connection status.
Radio labels in the builder honour the authored font colour, as the preview does.
Document template sections keep their identity when reordered; the Generate Document step has an input-parameters editor. A table section fed by a Find Records result now prints every row (it printed only its header), and $now or $today in a document's text prints today's date instead of the literal word.
A published widget pending review can be withdrawn.
A just-saved environment was invisible on the Deploy tab until reload.

Updates since release (October 2026)

Hobby, the free desktop

Installers for macOS (Apple silicon and Intel), Windows (64-bit; the installer is not code-signed yet) and Linux (.deb and AppImage). No sign-up: the first launch creates a local account.
Fonts, icons and the full template gallery ship inside the download, so the editor renders and the gallery is full with no network.
The free plan is enforced by the local services, not just the editor: hosting and deployment, boards, mobile builds, team invites and agent hosting answer This needs a paid PIES plan, while downloading the generated source code is free, and every build uses the default stack (MySQL, Go, React), web only. Team and server features in Admin show a padlock; server-only settings are left out. See Hobby.
Hobby's AI is PIES Private AI Micro, free and running on your machine. AI Settings on Hobby shows only Micro (on/off, one-time download, status and requirements); cloud models and PIES Private AI Lite and Ultra are shown as Enterprise / PIES Cloud cards with no key fields, and work when the desktop is connected to an Enterprise server or PIES Cloud. The chat chip reads PIES Private AI Micro, and asking for a cloud model offline explains how to get one instead of asking for a key. See Hobby.
The local models have one name and two sizes: PIES Private AI Lite (a 96 GB Apple Silicon Mac or one 94 GB GPU) and PIES Private AI Ultra (a 256 GB GPU server). The AI chat chip, the build receipt and AI Settings all show these names, and the chip now fits its row with the full text in its tooltip. A policy that names a retired model still works and shows as PIES Private AI (legacy). See Private AI.

Agents

A Record change trigger runs an agent when rows in a table of the deployed app are created or updated, optionally filtered by one column.
The New agent wizard and the Post dialog say up front when the app is not deployed yet and offer Deploy the app; Run now explains why it is disabled until the agent is posted. With a single access group, Runs as is picked for you.
An approval waits 5 minutes for Run now and an hour for scheduled runs, events, webhooks and errands, and the wait no longer counts against the run's minutes budget.
Activity folds repeated items from one agent into one row, dismisses in bulk, and shows how many records it lists. Playbooks → All workspaces groups the stock copies by name. The Agents Map captions clusters with app names and post counts.

PIES AI and governance

PIES AI → Memory lists what PIES AI remembers — Organisation, App and Agent notes — with who wrote each and when; administrators can add, edit, delete and promote notes. Organisation notes reach every build, Studio AI answer and agent run in the organisation. The page shows how many notes each scope holds, filters by scope tab and search, and marks each note's scope with a colour, in light and dark themes.
Memory notes are masked and versioned. Every Organisation, App and Agent note goes through the same personal-data classification and masking as the Knowledge Base before it is saved — an email or card number is stored as [REDACTED:email] or [REDACTED:credit_card], and a note is not saved if the check cannot run. Each edit or delete keeps the earlier text with its author and time: History on a note offers Restore, and Recently deleted brings a deleted note back.
A data-only request builds only the data. Ask PIES AI for just a table — "add a table named Notes with a text column title, nothing else", "data model only", "no screens" — and it adds the table without list, form or detail screens, functions, events or sample rows. Delivery steps that word their own data-only change are read the same way, so a verifier no longer finds screens nobody asked for. Name a screen, page, form or dashboard and the full build runs as before.
Governance policies match every class detected in a request, so a card number in an app classified PII still meets PCI rules.
Knowledge Base text is classified and masked at upload, every change is audited, and opening a source shows its real classification, scope and origin.
Knowledge Base search no longer needs an OpenAI key: without one, documents are indexed by a built-in local embedder that never leaves your network, so search keeps working under Air-Gapped. It matches on shared wording rather than meaning.
The AI audit log names the user and the app instead of showing ids; the policy editor picks applications by name.
PIES Private AI is a Preview in 1.9 — great for chat and simple builds, with larger redesigns still improving — and it carries a Preview badge in AI Settings, on the Private LLM tab and in the model pickers. The recommended model is Claude Opus with your own Anthropic key, marked Recommended in AI Settings, in Force one model and in a policy's preferred-model picker. See PIES Private AI.
AI Settings shows each provider key's real health (Key rejected, Out of credit, Rate limited), and administrators see a banner while a provider that a governance policy actually routes to is out of credit; a key no policy uses does not raise it.
Force one model accepts only a model whose provider is connected. Choosing a model from a provider with no API key (or Azure without its endpoint) is refused with <Provider> is not connected. Add its API key under Providers before choosing <model>. and the active model is left unchanged, so every AI turn no longer fails against a provider you never set up.
AI-built screens lay out KPI cards in one row of up to four, even when PIES AI adds several groups at once, use the full width of the canvas for charts, tables and other content, place sign-in, sign-up and password-reset forms in a centred card about 560 pixels wide, place add and edit forms in a centred card about 720 pixels wide with Cancel and Save inside it and a screen only as tall as the form, and pair charts on a shared content grid, take colours from the app's theme, no longer add a second button with the same label, and no longer put "Ready to get started?" panels or a stray "or" under an add or edit form — the form's own Cancel and Save are its only actions.
Add and View screens generated from a table with only a few columns sit in a narrower card, and a form of three fields or fewer stacks its fields in one column, instead of spreading them in half-width columns across the full width with an empty slot beside the last field and a large blank area below.
Text colours on AI-built screens are checked for readability against your app's theme on every save, whichever model answered and however the screen was changed (new screen, whole-app build, inline edit, style change or widget patch), so white text on a white page is saved in a readable colour instead.
A theme PIES AI generates is saved as a theme of its own, and its sidebar is always readable: when the requested sidebar text would not show on the sidebar background, the sidebar takes the theme's darker brand colour. Apps whose AI theme was saved earlier keep their old sidebar until the theme is saved again (re-run the theme prompt or save it in Themes).
Asking PIES AI to add a button to an existing screen ("Add a button labelled Greet to the home page") now adds and saves the button, instead of rejecting the edit with nothing changed.
Asking PIES AI what a button should do when it is clicked ("When Greet is clicked show a message saying Hello") now adds a click event to that button that shows the message, and leaves the rest of the screen as it was. If the screen has no such button, the receipt says the event was not applied, instead of rebuilding the page and reporting success.
Asking PIES AI to make a screen the home page ("Add a Dashboard page as the home screen") now makes it the screen the application opens on, and the reply says so only when it was set.
Asking PIES AI for a dashboard ("KPI cards, alarms by severity pie and incidents table") builds it from the stock KPI card, chart and table widgets, which follow your theme, instead of writing custom widgets; a custom widget is written only when you ask for one. A build turn can no longer empty a screen's widgets unless you asked to clear it. An AI-built dashboard opens with a compact page header instead of a tall landing-page banner, and PIES AI no longer stacks a second banner on a screen that already has a title band, so there are no large empty bands above or below your content.
KPI cards PIES AI builds count the right rows. A card whose figure lives in a different table from the rest of the row (for example Problems to Confirm adding up a count kept on grouped alarms) is now built on that table instead of being left out, and a filter such as not Acknowledged counts every row that is not Acknowledged instead of none. Screens built before this keep their saved cards; ask PIES AI to rebuild the KPI row to pick it up.
Asking PIES AI for a whole game or app built around a coded view ("Build a Tetris game app … the game board as a custom widget") places exactly one board custom widget on the gameplay screen it planned, without list, chart or form scaffolding beside it. The board sits directly under the page header, full width and centred, with its height fitted to the game grid, and the rest of the screen moves down below it, so the game is the first thing you see instead of a small board at the bottom of the page. Rebuilding never adds a second board to a screen that already has one.
A data custom widget PIES AI writes over several tables ("a gauge showing the percentage of sites that have at least one Critical alarm, using the sites and alarms tables, and add it to the Dashboard screen") is loaded with the rows of every table it names and links them on columns those tables really have, so the gauge shows the real figure instead of always 0%. Gauge, ring and progress tracks are drawn in the theme's border colour, so they stay visible on dark themes.
Asking PIES AI for a widget such as a star rating ("Add a star rating widget to the Home Page") now searches the widget library first, instead of designing a new page around the request; when nothing in the library fits, PIES AI writes a custom widget and places it on the screen.
A chat request that names no screen ("add a text box") is made on the screen open in the editor instead of PIES AI asking which screen you mean, and "this" or "it" means the widget you have selected.
The build receipt lists what the run changed and no longer mentions lookups PIES AI retried and recovered from on its own.
A PIES AI build cut off by a service restart now ends as an interrupted turn with pies-ai restarted while this build was running. Click Continue to resume. and offers Continue, instead of a finished turn saying no changes were made. See Error reference.
When you send the first message of a new PIES AI chat, it appears in the chat and the message box clears as soon as you press Enter, with a ⏳ Sending… bubble while the chat is created, instead of the text staying in the box for several seconds when the platform is busy.
After a screen change the build receipt is built from the saved screen: it lists the widgets Saved on screen and flags any widget the summary names that is not there, so a summary can no longer claim widgets that were never saved. The receipt also re-checks text readability on the saved screen and reports Design check failed: illegible text when text would not show against its background, and a redesign always updates the screen's last-saved time.
A screen edit that would leave an empty card, container or banner, a placeholder-only widget or a default Page title header is not saved: PIES AI is told what was empty and fills it in or removes it, so a redesign no longer reports success on a hollow page.
Landing pages and screen redesigns are built from a set of ready-made page sections (a hero banner, a split hero with the copy on one side and a picture on the other, feature cards, a call to action, a table page, a KPI row, a compact band of headline figures, a grid of two to four charts laid out two per row, each in its own titled card, and a map with a location list) that take their colours from your theme, instead of being styled freehand, so they look consistent whichever model does the design. A split hero shows an image from your app's media library when you name one; otherwise it draws an illustration in your theme's colours, so an offline installation never shows a broken picture.
A whole app PIES AI builds now gets a look that fits what it is for. After the plan, PIES AI picks one of seven design presets — Clinical, Vibrant, Corporate, Warm, Fresh, Elegant or Industrial (dark) — and saves it as the app's theme (Design: Vibrant, for example), so every screen of the app matches and a clinic app no longer looks like an events app. The preset sets the colours and type; PIES AI never chooses colours freehand, and every preset passes the readability check. Asking for one screen in a style saves the preset as the app's theme in the same way, so the screen's colours come from the theme rather than fixed colour values, and form Save and Cancel buttons follow it. An app that already has a theme you made keeps it. Asking for soft pastel colours or for purple (restyle the page in purple; violet, lilac, lavender and plum work too) switches the app to the Design: Pastel or Design: Purple look in place of the one PIES AI picked. Asking for green or your brand green (green and white) switches it to Design: Green, green #2E7D32 on white. New page layouts arrive with it: a split panel (a list beside a summary chart) and a sectioned dashboard grouped under Overview, Insights and Records.
Asking PIES AI to add to a screen it built ("add a chart of tasks by status", "add a KPI row") adds the new section where you say — at the top, at the bottom, or above or below an existing section — and moves what is below it down, so nothing overlaps. "Put the table and the chart side by side" places the two in one row. Each change saves a new version of the screen you can rewind. Moving or resizing a single widget, or a phone layout, is still done by hand in the editor, and PIES AI says so.
PIES AI no longer adds a second copy of a table to a screen that already lists that table, and a table it places lower on a screen is moved up under the content above it, so a list or form screen no longer shows a duplicate grid or a large blank band. Screens built with an earlier version keep their widgets until you ask PIES AI to rebuild them.
Ask PIES AI for a map of a table that has latitude and longitude columns, such as your sites, and it builds a map with a marker for each row in your theme's primary colour, with a list of the same locations beneath it. A table without coordinates gets the location list only, never an empty map.
Ask PIES AI for a filter bar over a table and it adds a bar with one dropdown per filter column, such as status or category. Picking a value narrows the table to the rows with that value, and All shows every row again, in both React and Angular apps. A search or filters section PIES AI plans for a screen with a table now becomes a filter bar on that table, instead of a heading-and-text band with no control in it; a section with a button that opens another screen stays as it is.
Tables open without the row of filter boxes under the header and without a labelled Columns button. A filter icon in the table's toolbar shows the filter boxes when you need them; the row stays open while any filter has a value, and when it is closed with filters still set the icon shows how many (for example Filters (1)). Clear the filters and close it to hide the row again. Choosing columns is now an icon menu in the same toolbar. To keep the filter row always open on a table, set its filterRow constraint to open; turning off filtering or column choosing still removes them entirely. The editor canvas shows tables the same way, in light and dark themes. This applies to React applications.
A table can open already sorted. Give it a default sort column and direction ("list readings newest first by point date") and the built application opens the table in that order, with the arrow on that column's header; clicking a header still re-sorts as before. Without a default sort, a table opens in the order the rows were added. This applies to React applications.
A table can be edited in place. Set its editable constraint and choose a save function (saveFunction), and users can change cells directly in the built application: each column gets a text, number, date, dropdown or checkbox editor, and a column can be required or given a minimum and maximum. Changed cells are highlighted, and Save changes (2) calls the save function once for each changed row, with only those rows and their edits; set saveMode to bulk to call it once with all the changed rows. A row that fails shows its error and stays pending, Undo edits discards what has not been saved, and Add row (allowAddRow, with an optional addFunction) adds a blank row. For now these settings are made in the screen's JSON; an Editing section in the table properties is coming. This applies to React applications.
Ask PIES AI to colour code a table by a column ("colour code the requests by priority") and each value in that column is shown in bold, in its own readable colour: urgent and high in red, medium and pending in amber, low and done in green, open in blue. The colours also show on the editor canvas, which no longer drops colour rules saved on a table column.
A detail screen PIES AI builds for one record, such as a contact or a ticket, now loads that record from the id in the page address and shows its values in the built app, instead of a dash for every value. Detail screens built with an earlier version keep showing dashes until you ask PIES AI to rebuild them.
A detail screen PIES AI builds for one record now opens with a header and a Back to button that returns to the list (for example Back to Clients), then the record card. It no longer adds a table, KPI cards or a chart for the whole table under the record.
When you ask PIES AI for a friendly message for when there is nothing to show ("No tasks yet"), it becomes the table's empty message, shown in the built application only while the table has no rows, instead of a band that stays on screen above a populated table. The editor canvas still shows No data yet for an empty table. On a screen without a table, or when the message comes with a button ("Add your first task"), PIES AI builds a centred empty-state card with a dashed border in your theme's colours instead.
A list of records in a built application, such as a low-stock or open-orders list, now shows a centred No data yet in the list's own text colour when no records match, instead of an empty box. Apps generated with an earlier version show it after they are built again.
Asking PIES AI to rename a table now renames it in place: the table keeps its columns and rows. When the table you name does not exist, nothing is saved and PIES AI says it was not found, instead of creating a new table under the new name.
PIES AI now keeps to edit existing items only. When you ask it not to create any table, screen or function ("no new tables", "existing items only"), or ask it to rename something or fix the casing of names, it changes only what is already in the app; anything new it tries to add is refused and it edits the existing table, screen or function instead. Before, such a request could still add a new screen or save lowercase copies of your tables.
Asking PIES AI to delete backend functions ("Delete these three backend functions … Change nothing else") now deletes them, and the receipt lists each one deleted; a version of the app is saved first, so the deletion can be rewound. Before, PIES AI kept the functions as disabled stubs and reported them as updated.
Asking PIES AI for an event now builds it directly: a button that opens another screen (with the record's id), asks for confirmation before it acts, goes back, sets a field or shows a message, and a screen that runs a function when it opens. Each is saved as a working event, and anything that could not be built is named in the receipt instead of being guessed.
Asking PIES AI for a data model on its own ("create a data model for a clinic") now builds the tables, columns and foreign keys directly in one step, using an id key on every table, and the receipt lists what was saved. Data-model and event requests finish faster and use far fewer tokens than before.
Asking PIES AI to add a field to an existing table ("add a priority field (Low, Medium, High) to jobs and a chart of open jobs by priority") now adds the column to that table first, fills it in on the rows already stored, and then builds any chart or screen you asked for over the new column. Before, such a request could build only a new screen with placeholder cards and leave the table unchanged. Asks to remove or rename a column, or to add a search or filter box, are not treated as new fields.
When the model a policy chose is busy or rate-limited, PIES AI waits and retries that model for up to about a minute before handing the request to the policy's fallback model, so a design request is not quietly finished by a smaller model. The model chip still names the model that answered.
PIES Private AI: the Private LLM card shows the seed training data and can refresh it, and every fine-tuning job trains on it unless you opt out. See PIES Private AI.
PIES Private AI builds faster: each build, inline edit or chat request shows your private model only the tools that kind of request needs (a screen redesign sends roughly a quarter of the earlier prompt), and the model can ask for another group of tools mid-build when it needs one. Cloud providers are unchanged.
A whole app built by one PIES AI agent no longer reports Build complete after saving only tables. When the agent adds tables but no screens, PIES AI runs one more pass for list, add and edit screens over them; if it still adds none, the build ends with Build finished — added N table(s) but no screens. See Error reference.
PIES Private AI Home screens look finished: a hero no longer repeats the starter Home page's placeholder sentence, and a table the model asked for with a single column shows the table's first four columns, the requested one first.
AI-built screens come out complete with every model: the AI cannot finish a build while a screen it created has only a title band and no content, a table never shows the same column twice, and a page title the AI did not position is placed at the top of the screen rather than below the content.
A table PIES AI builds now shows its real column headers and values when the model lists the columns by name only, instead of undefined in every header and cell. Screens built with an earlier version keep their table until you ask PIES AI to rebuild it.
PIES Private AI edits change the screen in place: asking it to change a chart's type updates that chart instead of adding a second heading and chart below the table.
Asking PIES AI to redesign a screen in an application that has no tables yet builds a content-only page (a hero, feature cards and a call to action pointing you to Build → Database) instead of inventing tables that do not exist and saving nothing. The build receipt says The app has no tables yet, so I built a content-only page; add a data model to get tables/charts.
A redesign keeps the screen's purpose, with every model. Asking PIES AI to redesign this screen on a Login, Register, Forgot Password or Set Password screen gives it a better layout (a hero, the sign-in form, a call to action) but never adds tables, KPI cards or charts, and the sign-in form is not tied to one of your tables. Redesigning any other screen keeps the kinds of sections already on it and adds data sections only when you ask for them (add a chart of…). A form tied to a table that names no fields shows up to eight key fields instead of every column, and every section of an AI-built screen lines up to the same page width.
AI-built screens look more finished. KPI cards get an icon, a coloured accent bar and, when the table has a date column, the change against the previous 30 days; charts get axis titles and a legend, and a chart on its own sits in a titled panel; tables get search, filters, column choice and sorting; a landing page hero gets an illustration in your theme's colours. A single screen built on its own now picks a design style the same way a whole app does, with every model including PIES Private AI, and a theme you made yourself is kept.
Asking PIES AI to add icons to make the page easier to scan now puts an icon on every feature card, with every model; before, some models left the cards without icons.
PIES AI builds the buttons and columns you name. A request such as a table of data sources (name, kind, status, last sync) and buttons Test Connection and Sync Source now gets every listed column and every named button; if the first pass leaves one out, PIES AI adds it before the build ends.
PIES Private AI agents can answer in plain words: an agent run whose first reply answers the question without a tool now finishes with that answer, as on a cloud model, instead of being pushed into a tool call and ending paused. A reply that only describes a plan is still sent back to act.

Building and running

A table whose header text colour matches its header background no longer shows a blank bar: the column names are drawn near-white on a dark header or near-black on a light one. Rebuild the preview to pick this up.
In a React application, KPI card numbers and labels and text-widget text whose colour would be unreadable on the card or band behind it (such as white on white after a light restyle) are drawn in a readable dark or light colour; readable colours are kept as you set them. Rebuild the application to pick this up.
A chart's axis labels, axis names and legend now use the font colour set in the chart widget's style instead of a fixed grey, so they are readable on a dark chart panel. A chart with no font colour set looks as before.
A donut chart PIES AI builds, or a chart you ask it to change to a donut, now shows with its hole in the editor and in the preview instead of as a full pie; changing it back to a pie fills the hole again. A donut chart saved before this update still shows as a pie until you ask PIES AI to change it to a donut again.
Tables in the editor canvas show the font, background and header colours set in their widget style, as built applications already did; a colour that would be unreadable on its background is drawn in a readable dark or light colour instead.
In a generated application with a dark theme, or on a dark section of a page, tables no longer appear as white boxes: they take dark surfaces, borders and header with light text, and the Columns button gets readable text and a visible border. Light sections look as before. Rebuild the application to pick this up.
In a React application, the Admin Console and its dialogs follow the app's theme: with a dark theme the console is dark and readable instead of white, and light themes look as before. Reopen Live Preview or rebuild the application to pick this up.
Custom widgets: New Custom Widget starts on Screen Widget (API apps get Function (Go) only), starter code keeps your widget's name, and Library → Widgets explains what belongs there.
Generated event handlers now tell their caller what happened: a handler returns its Call Function result as { ok, data, error } even without a Return Data step, and a failure returns { ok: false, error } instead of nothing. A custom widget that saves or deletes a row can check the result and show the error, rather than re-reading the table to find out.
A custom widget given a percentage width, such as 100%, now fills that share of its screen in built applications instead of shrinking to a narrow strip, so a fixed pixel width is no longer needed. Parameter values set in the widget's code block now reach the widget when no screen-level values are set; screen-level values still take precedence. Rebuild the application to pick this up.
Library → Widgets opens on a System tab with the built-in and registry widgets, each with Customise; tabs are System, Designer and My published. Library → Templates shows the system templates with Use, and its sidebar count matches your own templates.
Every transactional email (deployments, invitations, password resets) uses one branded layout with your logo and a plain-text part.
The Data tab shows the page holding a record you just added and confirms the save. Installing a template prefills a free application name.
Sign in with PIES Studio works from a preview opened in a new tab. In Hobby, it signs you in as your local account without asking for a password. Open Preview keeps waiting while a preview is still starting and says why if it gives up.
On a self-hosted Enterprise installation, a preview now loads its tables and sample rows the first time it is built. Before, the preview database could start empty, so tables and charts showed no data and actions failed even though the build said the sample rows were added. Rebuild the preview to pick this up.
Opening a preview that is not running now starts it. If a build ended without restarting the preview, or the preview's processes stopped, the preview address shows a starting page and the app opens by itself a few seconds later, instead of a preview error you could only clear by building again. See Error reference.
A failed deployment shows the reason it failed, and a hint where there is one, in the editor's deploy console and on the deployment, instead of no reason was recorded. See Error reference.
A shut-down deployment shows its services as Stopped, with Open turned off on the Frontend and Backend until you start it again, and scheduled starts and shutdowns appear in the deployment's Activity Log. A deployment schedule is checked every minute, so a short start or shutdown window is no longer missed; a scheduled action that fails, for example because the build engine is unreachable, is retried every 30 minutes, and the Activity Log names the action that failed.
A Find Single Record step whose lookup value cannot be read now shows an Incorrect Configuration problem naming the step and quoting the value, instead of a vague function could not be generated message; wrapped forms such as ${id} or {{id}} are read as $id. See Error reference.
Selecting a step that has no settings in an event or function, such as Navigate to Previous Screen, Close Popup, Parallel, End Parallel, Break, Finally or End Try, now shows a short note in the Properties panel explaining what the step does, instead of an empty panel.
Downloading an application's code from Deploy & Publish no longer times out on a large or busy application. The code is generated in the background while the dialog shows Generating application code… with the time so far, and the zip downloads when it is ready. The zip now leaves out installed packages and build output (node_modules, .next), so it is much smaller; the packaged Dockerfiles install them when you build.
A screen or function name must be 3 to 255 characters long. File → New → Screen and Function now tell you so in their own words (Screen cannot be added…, Function cannot be added…), not with the old Layout cannot be added message or a generic Please provide a valid name.
The File → New → Screen and Function dialogs have a × close button and also close when you click outside them or press Esc, without creating anything.
Asking the AI to add a form to the screen you have open, for example add a new request form above the list, now adds just the form where you asked, instead of re-laying out the whole screen and putting the form below the list.
A table can show a search box above its rows: tick Search box (above the table) in the table's properties. Typing in it hides the rows that do not contain the text in any column, in both React and Angular applications. The table's filter dropdowns now also show on the Studio canvas, and asking the AI for a search box or filters above a list turns the search box on for you.
A table row action that raises an event now runs that event when the row's button is clicked; before, an action set to an event could do nothing. An AI assistant building through PIES Studio's tools can now add up to three row actions to a table, each opening a screen with the row or raising an event for it.
When your request to the AI names a screen, for example a Customer List screen, the screen is now saved under exactly that name, not a near variant such as Customers List.
Every screen the AI creates for a generated application, in a whole app or a follow-up request, is now added to the application's navigation menu (sign-in and sign-up pages excepted), instead of the menu listing only the landing screen.
A code block that opens a database transaction and never commits or rolls it back no longer makes every request to the application hang: the transaction is rolled back after 5 minutes (PIES_TX_TIMEOUT changes this) and its connection is freed. Always end a transaction with Commit or Rollback. See Error reference.
In an event's Simple action → Call Function, choosing the function now fills each of its parameters with the matching element on the screen, for example $form_hospital for a hospital parameter, instead of leaving them blank. A parameter stays blank when no element, or more than one, matches; Save still refuses a $ reference to an element the screen does not have.
Asking the AI to add a field and chart or show it, for example add a priority field to jobs and a chart by priority, now fills sample values into the new field on your existing rows, so the chart is not empty. Asking for only the field still leaves existing rows empty. See Quickstart.
A Count Card has a Record mode (value vs capacity): instead of totalling a table, it shows one record's value against its capacity, filtered for example on $routeParam.id, with the percentage, a bar coloured by threshold (green, amber from 80%, red from 95% by default) and a sub-line such as Spare {spare} {unit}. In its properties the record-mode switch comes first and hides the totalling settings, the card uses a single unit, and the filter offers route parameters and fields to pick from; on the Studio canvas each card shows sample figures with its own percentage. Threshold colours you set are now kept when the AI restyles the application. See the user manual.
In a function's flow, a code-block step is now labelled Code block with the block's name underneath, on the canvas card, in the step list and in the inspector, instead of Custom Widget with the language name. Saved functions are unchanged.
When the AI builds or extends an application, a button that does only one thing (open a screen, go back, or call one function) now gets a Simple action on the button itself instead of a separate named event. The Explorer lists only events with more than one step, so a generated app no longer shows one event per button. Events your application already has keep their names.
An event's Simple action can now use two more steps: Go back returns to the previous screen, and Save form saves a form on the screen that you pick. Save form runs the form's own Save, with the same checks, and saves the record once. Neither step is offered for a table's row actions.
The Decisions CSV export uses the table's columns and labels, and a submitted prompt in Ask PIES AI has a copy button.

About this documentation

The documentation is now versioned with the product: use the switcher in the top bar to read the pages for 1.7, 1.8 or 1.9, and every page states the release it describes.