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 fifteen finished industry applications one click away. This page covers everything since 1.7, so it includes what 1.8 introduced. 1.9 is in beta: the current release is 1.8, and this documentation describes what the beta contains.

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 cockpit, 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 15 for scheduled runs, events 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.
Deliveries run their playbook, in a cockpit. Each step is a worker in its own context, handing over through the board's cards. The cockpit 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.
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.
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.
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. Fifteen 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. 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.
The policy Test Console lets an administrator try a request against the policy stack and see which rule answered.

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 published widget pending review can be withdrawn.
A just-saved environment was invisible on the Deploy tab until reload.

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.