The 5 Screens an AI Agent Dashboard Needs (From Running an Approval-First Setup)

The 5 Screens an AI Agent Dashboard Needs (From Running an Approval-First Setup)

Our "staff" are AI agents, and the person in charge doesn't write code. That combination creates one hard requirement: nothing goes public until a human clicks Approve, and that human should never need a terminal to do it.

So on our first day we had a small local web dashboard built (by an AI coding agent) with exactly that job. It runs only on the founder's PC. After a day of real use, including one rejected approval and a couple of mistakes, here are the five screens we'd insist on again, and what each one taught us.

If you're a non-developer asking someone (or something) to build you an agent dashboard, treat this as a requirements checklist.

1. A task board with honest statuses

Every instruction becomes a numbered task that moves through seven states: waiting, in meeting, working, in review, awaiting approval, done, failed.

Why seven and not "to do / done"? Because the dangerous moment is the gap between "the agent thinks it's finished" and "a human has signed off." Giving *awaiting approval* its own status, with its own color and a badge count, makes that gap impossible to miss.

Ask for: a status that means "blocked on you," shown on every screen.

2. An approval box with a note field

Each approval request shows exactly what will happen ("publish these two posts") with two buttons, Approve and Reject, and a note field.

The note field turned out to matter more than the buttons. When the founder disagreed with a recommendation, they didn't need a separate conversation. They rejected with a short note, once just the file name of a different thumbnail, once "name: AprideTeam" to change the public name on our About pages, and the agents reworked from that.

We also made approval requests carry the recommended option plus "reject with a note to pick another," so one click covers the common case.

Ask for: a note on every decision, and a rule that agents can't take a gated action without a recorded approval.

3. A messenger, one channel per task

Agents post progress into a channel for each task: who's working on it, what the reviewer rejected, what changed. The founder can drop a message into any channel at any time.

One lesson: the dashboard's instruction box and the chat with the AI agent are two different places, and it's easy to type into the wrong one. On day one the founder typed the command meant for the agent ("process pending instructions") into the dashboard as a new task. We added a gentle check that asks "did you mean to say this to the agent?" when that happens.

Ask for: per-task history you can read later, and guardrails for the mistakes a non-technical user will actually make.

4. Memory you can read

Agents forget between sessions unless you give them a place to remember. Our dashboard has a memory tab that shows three plain-text lists:

  • How we do things. Step-by-step procedures, written in the open Agent Skills format (checked 2026-09-27), so any agent tool that supports that format can follow them.
  • What failed. A failure log. Anything on it may not be reused until the cause is fixed.
  • Who did what. A short work journal per agent.

Because these are ordinary text files, the founder can search them without learning anything new.

Ask for: procedures and failures stored as readable files, not buried inside one AI tool's memory.

5. Usage, limits, and alerts

AI subscriptions have usage limits, and image generation burns through them faster. One screen records every engine call, marks any that hit a limit, and shows when the daily backup last succeeded. An alerts screen lists pending approvals and dated reminders, like domain renewal.

On day one, the image engine refused our very first request because the subscription's limit window was already used up elsewhere. Because the dashboard logged it as a limit hit (not a mystery failure), we simply waited for the reset.

Ask for: a log that separates "hit a limit" from "broke," plus backup status.

The design choice underneath all five

The dashboard doesn't call any AI tool. It's a small local web app with its own database, and agents talk to it only through files and a few simple commands. Everything in the database is also exported as plain JSON.

That means we could swap which AI agent does the work tomorrow and keep the dashboard, the history, and the procedures. If you remember one thing from this post, make it that: don't let your dashboard belong to your agent.

Checklist

  • ☐ A status that means "waiting for a human," visible everywhere
  • ☐ Approve / Reject with a note, and no gated action without a recorded approval
  • ☐ Per-task message history that a human can join
  • ☐ Procedures and failure log in readable files
  • ☐ Usage log that flags limit hits, plus backup status
  • ☐ No lock-in: the dashboard works no matter which AI does the work

*How this post was made: drafted by an AI agent, reviewed by a separate AI agent, and approved by our human founder. Everything described happened on our setup on September 26–27, 2026.*

Comments

Post a Comment

Popular posts from this blog

Day One With an AI Agent Team: 6 Things That Broke (and the Fixes)

Image
  On September 26, 2026, we set up a small "company" whose staff are AI agents. Claude does research, writing, and review. OpenAI's Codex and Google's Antigravity make images. The person in charge doesn't write code. Most setup guides show the happy path. This post is the other half: the six things that actually went wrong on day one, why they happened, and what we changed. Every item comes from our internal failure log, so none of this is hypothetical. If you're a non-developer wiring AI tools together on a Windows PC, at least one of these will probably save you an hour. 1. The image tool had no quota left before we started What happened. Our first image request to Codex failed instantly with "You've hit your usage limit," and a time when it would reset. Why. Codex usage on a ChatGPT plan is shared across the places you use it. OpenAI says the same limits apply in the app, the CLI, the IDE extension, and the cloud ( OpenAI Help Center , ...
Read more

Automating Blog Posts With AI, Safely: What the Blogger API Can't Do (and Our Workarounds)

Image
For our first few posts, publishing meant the founder copying HTML from our dashboard and pasting it into Blogger by hand. It worked, but it was slow and error-prone: once, the wrong page's text ended up on our Privacy Policy. So we automated it with Google's official Blogger API. Now the founder does one thing: click Approve . Everything else, including the thumbnail, labels, a clean URL, and checking the live page, happens automatically. Here's how it works, the two things the API can't do, and one mistake that briefly took both blogs offline. Rule one: no approval, no post Before anything else, the publishing script checks our dashboard's approval records for that task. If there's no approval, or a decision is still pending, it refuses and says why. It also refuses to publish the same draft twice. We tested both refusals before the first real run. If you automate publishing, build the "no" path first. The one-time setup (about 15 minutes) Cre...
Read more