Agent UI mockups

An AI co-pilot embedded in Picaro that reads the operator's Amazon advertising data, proposes concrete changes, and executes only what a human approves. These thirteen screens are how that looks — drawn in the live Picaro design system rather than an approximation of it.

13 screensDraft · 2026-09-09 Static mockups · invented dataFor stakeholder review

The five rules every screen obeys

The operator instructs the agent; the agent operates the SaaS. Every proposal is verifiable on the Picaro screen they already trust.

Nothing reaches Amazon without a recorded approval. Every write is diverted into a proposal.

Decide per item, not per proposal. Approve two of five lines, edit one, reject the rest.

Japanese first. Output quality in Japanese is a product requirement, not a localisation task.

Show the work. Which tools ran, which skill is active, which context was used — not a spinner.

Design system — lifted from PicaroWebAppV2, not approximated

Sidebar

#000459

Nav active

#3A3B9B

Primary

#2563EB

Success

#199535

Warning

#F98113

Error

#F55948

Border

#D1D8DE

Page

#F8F8F9

Roboto

8px cards / 6px buttons

In the SaaS

Where the agent meets the operator: a panel docked beside whatever screen they are already on.

Agent docked beside the SaaS

The conversation is the surface. A panel docked to the right of whatever screen you are on — it already knows the seller account and the date range, so the operator's first question is the real question instead of "which account are we talking about?"

Open full size ↗

Answers in the operator's language, about the screen they are looking at
Shows which tools ran, not a spinner
Previews the data it used, then offers a way into the real table
Proposals arrive inline and go to the approvals queue

1440 × 900Main.html

One thread, three different asks

The same panel handles a broad question, a specific one, and an instruction. Only the shape of the reply changes — never the place the operator has to go.

Open full size ↗

"What should I look at today?" returns metric tiles and navigation
"Show me the ACoS trend" returns a chart with the target line
"Pause SD-Retargeting" returns an action that stops for approval

440 × 1290Conversation.html

Response blocks the agent can emit

Every reply is assembled from this vocabulary. The agent picks the blocks; the operator never learns a syntax.

Open full size ↗

Data is previewed, not dumped — a few rows, then a way into the real table
Navigation is a button, never an instruction to go find something
Anything that writes stops for a human, and reports honestly afterwards
When the ask is ambiguous the agent asks back instead of guessing

940 × 1430Blocks.html

The agent section

One nav item, five tabs. Everything that needs more room than a panel.

/agent — Chat

The full-page version of the same engine. Conversation list on the left, thread in the middle, and whatever the agent produced pinned on the right where a table can actually be read.

Open full size ↗

Threaded per account, switchable mid-conversation
Closing the tab does not lose a running analysis
Outputs pin to the right pane as tabs — table, chart, report

1440 × 900Chat.html

/agent/conversations

Every thread, searchable, with what actually came out of it. This is what answers "why did we change that?" a month later.

Open full size ↗

Proposals raised, applied, and skipped per conversation
The context the agent used to answer — goals, constraints, documents
Credits consumed, so cost is attributable

1440 × 900Conversations.html

/agent/insights — the shared record

Read-only. A proposal is not scattered across a feed: its whole life is one card — the insight that raised it, what was proposed, who decided and why, what was applied, and what the metric did fourteen days later. Event names and statuses are the SaaS task vocabulary as-is.

Open full size ↗

Decision chains carry a verdict: improved, rejected, no change
Rejections keep the operator's reason, and what the agent did about it
Campaign changes made outside the agent appear in the same stream
A market lane explains why some outcomes honestly read as "can't tell"
Two rail panels serve the agent itself: what it has learned, and what it suggests next

1440 × 1160Insights.html

/agent/knowledge

Upload the documents the agent should know — brand guidelines, promotion calendars, competitor sheets. It extracts what it learned and cites the page it came from.

Open full size ↗

Real states: ready, reading, shared, and failed with the reason
Any extracted line can be promoted into a hard constraint
You can ask a document a question directly
Uploads stay on the account; only Picaro's library is shared across customers

1440 × 900Knowledge.html

/agent/billing

A separate subscription from Picaro. Usage is metered per run and shown — but deliberately not enforced this phase, because cost per conversation varies too much to price yet.

Open full size ↗

Plan, seats, and next invoice
Daily credit consumption
Broken down by activity and by team member

1440 × 900Billing.html

Proposals up close

The approval mechanism in detail — the part that makes this safe to point at a live ad account.

Proposal — per-item approval

The idea the whole product rests on. The operator approves per item, not per proposal, and may edit a value before approving. Click a row in the preview below — the estimate and the button follow.

Open full size ↗

Current value, proposed value, and estimated impact per line
The orange row is excluded by default: its data changed after drafting
Past decisions on this pattern are shown as context, not as pressure
Nothing has reached Amazon until the operator presses the button

900 × 580ProposalCard.html

After execution

Partial success is reported as a normal outcome, not an error state. The skipped row says why it was skipped.

Open full size ↗

Per-item result: applied, or skipped with a reason
Previous values are stored, so undo is real
Effect is measured fourteen days later and returns to the timeline

900 × 450ExecutedResult.html

Admin console

Picaro staff only. What the operator must never see or set.

Admin — Skills

Picaro staff only. Every skill declares a maximum risk that cannot be raised at runtime or talked up by a prompt — a read-only audit skill can never be handed a write tool.

Open full size ↗

Explicit tool allowlist, with write tools marked
Native-Japanese sign-off is a column, not a convention
Rollout per skill: all accounts, beta only, or off

1440 × 900AdminSkills.html

Admin — Models & limits

A model pinned per job, so conversation quality and OCR cost are tuned separately. Keys rotate here rather than through a deploy.

Open full size ↗

Per-job model, key, call volume and health
Concurrency and step ceilings
An emergency stop that blocks every Amazon write while leaving analysis working

1440 × 900AdminConfig.html

Admin — Features

How a half-finished surface ships safely: built, hidden in production, visible to a handful of pilot accounts.

Open full size ↗

Three states per feature — all, beta, hidden — with account counts
The beta grant list underneath
Auto-approval enforcement is deliberately pinned to hidden

1440 × 900AdminFeatures.html

Before you read too much into it

Everything here is a static mockup with invented data. The one exception is the proposal card, where ticking a row updates the estimate and the button — because per-item approval does not read from a still image.

Some of this exists and some does not. Chat, approval cards with per-item editing, undo with recorded prior values, history, goals and constraints, the knowledge retrieval and the scheduled task engine are all built today, most of them switched off in production. The approvals badge, real charts in the agent, the pattern grouping behind “approved 13 of the last 14 times”, and the insights timeline are new work.

One open design question. The docked panel competes with the existing support chat bubble in the bottom-right corner. Docking the agent to the edge, as drawn, is one answer; merging both into a single launcher with two tabs is the other.