Review queues
Work waiting for a person, with the record and the source side by side.
Guide · Composable UI
How to build internal tools with AI that a business can rely on.
Review queues, admin panels, approval screens, operations dashboards: AI can now build them in hours. Whether they survive contact with real users depends on what sits underneath.
Internal tools are the screens employees use to run the business. AI changes two things about them: who can build one, and what the tool itself can do. This guide compares the three ways to build internal tools with AI, gives a five-step method that starts from the data and the roles rather than the screens, shows where AI belongs inside the finished tool, and lists the security checks that research says AI-written code needs.
Updated · 5 sources
Five layers of every internal tool
01
Screensqueues, record pages, dashboards and forms people work in
what people see02
Actions and approvalsapprove, assign, update, export — and who must confirm each
what people do03
AI stepsread a document, sort a request, draft a reply, flag an exception
work the tool does04
Permissions and auditwho may see and change what, and a record of every change
enforced on the server05
Datathe records, their states and the systems they come from
the foundationHow do you build internal tools with AI?
To build internal tools with AI, start from the data and the roles, not the screens: define the records the tool works on, their states and who may see or change each one. Then have an AI build the screens — by writing code with a coding assistant, by prompting a low-code builder, or by composing tested parts on a platform that already holds the data and permissions. Put AI inside the tool only where it does real work, keep a person’s approval on consequential actions, and review security before go-live, because AI-written code often fails security tests.
What they are
What internal tools are, and why teams spend so long on them.
Internal tools rarely appear on a roadmap, yet every operation runs on them. They are small, numerous and long-lived — and each one needs the same plumbing: sign-in, roles, data connections, an audit trail.
Admin panels
Look up a customer, correct a record, reset an account.
Approval screens
Refunds, exceptions, credit limits: approve or decline, with a reason.
Operations dashboards
Volumes, backlogs and service levels, with a click through to the cases.
Data-entry forms
Structured capture with validation, instead of a shared spreadsheet.
Back-office consoles
Several of the above joined into one app for one team.
Choosing a route
Three ways to build internal tools with AI, compared.
All three can put a working screen in front of you within an afternoon. They part company on what happens next: who maintains it, who checked its security, and where permissions are enforced.
| AI coding assistant | Low-code builder with AI | Composable platform with an AI builder | |
|---|---|---|---|
| What the AI produces | Application code in your repository | An app inside that builder | Pages assembled from the platform’s tested parts |
| Data connections | Written by hand or by the AI | Connectors the builder offers | The platform’s collections and connectors |
| Permissions | Whatever the code implements | Set up per app | The platform’s, enforced on every read |
| Audit trail | Built if someone remembers | Varies by tool | Recorded by the platform |
| Security review | Every line, every change | The builder plus your custom logic | Each part once; screens inherit it |
| Who maintains it | A developer, indefinitely | The app’s owner in that tool | The business team, with the AI |
| Best fit | A tool that is a product in its own right | Simple apps over existing databases | Many operational tools on shared data |
Which route fits your tool?
It has unusual logic or a public faceWrite code with an AI assistant, and give it the same review, tests and security scan as any other code.
It is a form or table over one databaseA low-code builder with AI is quick; check where permissions and audit live.
It is one of many tools over shared business dataCompose on a platform that already holds the data, roles and audit, so each new tool reuses them.
The method
How to build internal tools with AI in five steps.
Start from the records and the roles, not a screen mock-up. They decide every screen, every permission and every audit question that follows — and a mock-up hides all three.
- Name the job and the people
One sentence of what the tool is for, and each role that uses it: requester, reviewer, manager, administrator.
- Model the records
The things the tool works on, their fields and the states they move through — submitted, in review, approved.
- Set who may do what
For each role: which records it sees, which fields it changes, which moves it may make.
- Have the AI build the screens
A queue per role, a record page, a dashboard. Review the plan before it builds, then try each screen with real data.
- Add AI work, then go live
Extraction, sorting or drafting where it saves time — with approval on consequential actions, tests on real cases and an owner named.
Tool: Refund exceptions console
For: support agents (request), team leads (approve),
finance (view, export)
Records: refund request — customer, order, amount,
reason, evidence files, status
States: submitted → in review → approved | declined
Rules: agents never approve their own requests;
over 500 needs a team lead and finance
Screens: my requests · review queue · request page ·
weekly dashboard by reason and amount
AI: read the evidence, suggest a reason code;
a person approves every refundWhy the brief is shaped this way
- Roles firstEvery screen and permission follows from who uses the tool.
- States namedQueues, dashboards and audit all hang off the states.
- Rules in wordsSeparation of duties is stated, so it can be checked.
- AI boundedWhat the AI does is written down, and so is what it may not do.
AI as a feature
Where AI belongs inside an internal tool, and where a person decides.
Building the tool with AI and putting AI in the tool are different decisions. Inside the tool, the question is how much the AI may do on its own. OWASP names “excessive agency” — too many tools, too many permissions, too much autonomy — as a top risk for LLM applications.
Costly if wrong
Suggest, then a person actsRisk scores, fraud flags, suggested decisions — shown beside the evidence, never applied silently.advice
A person approves firstRefunds, payments, account closures, messages to customers. The AI prepares; a person confirms.approval
Cheap if wrongLet it runSummaries, suggested reason codes, draft replies — produced automatically, shown for the person to use or edit.automatic
Act with a trailTagging, routing, filling an extracted field — applied automatically, logged, and reversible in one click.logged
Reads and suggestsChanges recordsRules for AI inside the tool
- Fewest toolsGive the AI only the actions this tool needs, with the narrowest rights.
- The person’s own rightsThe AI acts as the signed-in person, never as an all-powerful service account.
- Authorisation downstreamThe system that holds the data decides what is allowed — not the model.
- Approval on high impactAnything costly or hard to undo waits for a person.
Before go-live
Security checks for AI-built internal tools before anyone relies on them.
Internal tools sit close to customer data and money. When the code comes from an AI, the measurements below argue for more review.
Before an internal tool goes live
- Company sign-inSingle sign-on, no local passwords, accounts removed when people leave.
- Permissions on the serverEvery read and write checked where the data lives, not hidden in the screen.
- An audit trailWho changed what, when, and from which screen — kept where the tool’s owner cannot erase it.
- No secrets in codeKeys and passwords in a vault, never in the generated source.
- Output escapedAnything a model wrote is treated as untrusted before it is shown.
- Versions and rollbackEach change is a version; the last good one is one step away.
- An ownerA named person answers for the tool after the builder moves on.
- Real data testedTried on real records and edge cases, by the people who will use it.
On Botminds
How Botminds lets you build internal tools with AI on a governed platform.
On Botminds, internal tools are composed from the same parts as everything else — queues, dashboards, review screens and admin pages share one model, one look and one set of permissions. Piper builds them from a sentence, after you approve the plan.
An internal tool on Botmindscomposed from tested parts, governed by the platform
149 card typestables, charts, queues, viewers, chat with an agent
Five layoutsplus page and pack templates to start from
No wiringcards filter each other on the page
Readable rulesfour verbs join pages into one app
Roles decidethe server decides what each person may read
Phone layoutsa layout of its own on the same page
Custom cardsbuilt as data, cleaned or sandboxed
Ships as a packageversioned, moved between environments
An internal tool, by conversation
You
Add a Supplier detail page: each supplier’s invoices as a table, with a status chart. Clicking a supplier on Payables overview should open it, filtered.
Agent
Plan: 1) a new split page with a records table and a status chart over Invoices; 2) a rule on Payables overview — a click on a supplier opens Supplier detail filtered to that supplier; 3) check both pages with live data. Shall I go ahead?
You
Yes, go ahead.
Agent
Done — Supplier detail has its table and status chart, and the rule is on the bar chart. I read each change back. Here is the link.
Read the full design in composable UI and how Piper builds whole solutions in enterprise vibe coding. Build your first page in the Academy: pages and cards and dashboards and inbox.
Questions people ask
How to build internal tools with AI: common questions.
The technology behind itComposable UIPages, packs and 149 card types→How do you build internal tools with AI?
Define the records, their states and the roles first; then have an AI build the screens, by writing code, prompting a low-code builder, or composing tested parts on a platform that already holds your data and permissions. Add AI inside the tool only where it does real work, keep approval on consequential actions, and review security before go-live.
What are internal tools?
The applications employees use to run the business rather than the products customers buy: review queues, admin panels, approval screens, operations dashboards, data-entry forms and back-office consoles.
What are internal AI tools for companies?
Internal tools with AI doing part of the work: reading documents into fields, sorting requests, drafting replies, summarising cases or flagging exceptions — with people approving the actions that matter.
Is it safe to build internal tools with AI coding assistants?
Only with the same review as any code, and more. Veracode found that 45% of AI-generated code samples failed security tests in 2025. Check permissions on the server, escape output, keep secrets out of the code and keep an audit trail.
Should I use low-code or AI coding for internal tools?
Low-code is quicker for a simple app over one database; AI coding suits a tool with unusual logic that you will treat as a product. When you need many tools over shared business data, a platform that composes them from tested parts reuses the data, roles and audit each time.
Can non-developers build internal tools with AI?
Yes, on a platform where the data model, permissions and parts already exist and the AI composes from them, so the business user reviews a plan and the result rather than code. Raw generated code still needs a developer to review it.
What should an internal tool have before it goes live?
Company sign-in, permissions enforced on the server, an audit trail, no secrets in code, escaped model output, versions with rollback, a named owner, and testing on real records by the people who will use it.
Sources
- Retool: The state of internal tools 2022 (report and methodology)retool.com
- Stack Overflow Developer Survey 2025: AIsurvey.stackoverflow.co
- Veracode: 2025 GenAI Code Security Reportveracode.com
- OWASP Top 10 for LLM Applications 2025: LLM06 Excessive Agencygenai.owasp.org
- OWASP Top 10 for LLM Applications 2025: LLM05 Improper Output Handlinggenai.owasp.org
Read next
Generative UI vs composable UIInterfaces a model writes at run time, and interfaces assembled from parts→Vibe coding vs low codeGenerated source code or a platform’s parts: what each gives you to run→Vibe coding security checklist29 checks across five gates, from the first prompt to production→All guidesEvery explainer, by topic→
See it on
your own work.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.