Agents — missions, squads and the Delivery Squad

PIES AI chat builds what you ask for, one conversation at a time. Agents take the same building power and run it for you — on a schedule, from a webhook, or as a coordinated team delivering a whole application while you watch. This chapter covers what an agent is, how a squad works, and how to run and supervise a delivery mission.

Agents An agent is a deployed, versioned snapshot of instructions, tools and policy. It can be triggered by hand, by another agent, on a schedule, or by a webhook. Every run is recorded step by step — each tool call with its arguments, result or error — and every step's model is chosen through your organisation's AI governance policies, so an agent can never reach a provider your policy forbids. Heavy work (screen authoring, architecture) is automatically served by the strongest model your policy allows.

Squads and missions A squad is a team of role agents: Lead, Business Analyst, Architect, Data Engineer, Backend Engineer, UX Engineer, UX Developer, QA and Ops. Each role holds only the tools its job needs. A mission gives a squad a brief and a target application: "build an expense tracker", "redesign the home page as a dashboard". Everything a mission does is scoped to it — its cards, its chats, its app versions — and a mission can be rolled back as a unit, board and all.

How the Delivery Squad delivers

Design. The Architect designs the whole application in one pass: tables, functions, the screen inventory and each screen's purpose. Anything that already exists in the app is recognised and never re-planned. Foundations. Tables (with sample data) and business functions are created first. Read functions are guaranteed: a screen can never be left without a data source. Screens. One story per screen. On cloud models each story is delivered end to end in a single chat-grade step — screen, functions it needs, wiring and navigation. On local/private models the platform composes the screen deterministically on the design grid: header band, KPI cards, charts, tables and forms, laid out and wired by code from the data model. QA. Evidence is gathered by the platform — which designed artefacts exist, whether screens have substance, whether widgets are wired — and QA judges against it. Only QA closes work. Honest completion. The mission ends with the truth: "Mission complete: N stories delivered and QA-closed" or "MISSION INCOMPLETE: N still open". Deployment failures are reported as failures.

Watching a mission — the cockpit The mission cockpit shows the interaction map (which specialist is working), the board (stories with their tickets, phase-ordered, with live progress), the mission log, and the live activity stream with a plain-language summary of every step ("compose screen 'Dashboard' — 5 widgets: KPIs, pie chart…").

Every ticket is a chat Each ticket's run is saved as a conversation on the application — open the AI chat history and every mission appears as one collapsible group ("🤖 <mission> · <ticket>"), exactly like Pie Loop items. Open any ticket's chat to see precisely what the agent was asked and every tool call it made. A re-run or a QA fix round continues the same conversation, with full prior context.

The journey, versions and rollback Every ticket carries a timeline written by the platform at every boundary: dispatch, each tool call, each write with the app version it produced, each decision and outcome. Every app version is stamped with the mission, ticket, agent and model that caused it. From any card you can roll back exactly that ticket's changes — the app is restored to the snapshot before its first write and the card returns to To Do, with any collateral named honestly before you confirm.

Cloud and local models The squad works on both. Cloud models (Claude, GPT) deliver each screen with full chat-level quality. Local/private models (PIES LLM) are guided by deterministic composers — the platform owns layout, wiring and step grammar, so a small model's output meets the same structural bar. Model choice is yours (or your governance policy's); the pipeline adapts automatically.

See also: How AI works · the user manual · worked use-cases.