Flutter Personal App Agent: A Hands-On Practice

qiu alan — Tue, 11 Aug 2026 05:10:53 +0000

The agent your personal app needs is a lot simpler than the enterprise playbook. This is the whole chain — requirements, architecture, release — and the reasoning behind every cut.

![Three phases of a personal AI-native app: requirements, architecture, and release]

I've been building a personal reminder assistant in Flutter for a couple of years now. Voice-first, local data, one user. It's been a lot of trial and error, and somewhere along the way a conviction hardened: a personal app agent should not copy the enterprise playbook. This post walks the whole chain — requirements, architecture, release — and writes down why I made each cut.

Requirements: stop importing the enterprise stack

Most of what gets written about agents today takes the enterprise view. Full orchestration framework. A dozen-step lifecycle. Eleven states. Multi-layer tracing, an audit chain, multi-path retrieval. That's the right shape for a SaaS support bot or an internal knowledge base. For my app, importing that stack would have been the first mistake.

A personal app agent lives under different rules. One user, so no multi-tenancy, no permission tiers, no approvals. No accounts, no sign-in — everything lives on the phone. It's not a 24/7 service; every use is an independent session. And it's usually built and maintained by one developer. Nobody is going to keep an elaborate architecture alive alone.

So my first rule became: good enough is better. Enterprise architecture solves "many people, compliance, audit, high concurrency." A personal app solves "one person, one thing, fast." Once I framed it that way, every later decision got easier.

Architecture: a two-level model beats a framework

The enterprise way is to run everything inside one orchestration runtime — parsing, routing, tool calls, output, audit, retries. You get type safety, traceability, and regression guarantees, and you also get real startup weight.

I went with two levels instead.

![The data flow of a personal app agent: one sentence in, through the classifier, the executor, and the tools and data layer, then a result back]

First, a classifier. When the user says one sentence, it decides what kind of request this is — a reminder, a task query, a setting change — and pulls out the key bits: time, task name, repeat rule. Its rules are short, it's cheap, and it's fast. Most simple requests are fully handled here.

Second, an executor. When something genuinely needs more work — a complicated repeat rule, a multi-step request, an ambiguous ask — the request moves up. It carries the full business context and the tool descriptions, and does the actual work.

The two levels talk in structured data, and the classifier's output feeds the executor. I can't put a number on it, but in daily use the cloud-call cost dropped noticeably, because most requests never reach the second level.

Intent recognition: three to five intents are plenty

Enterprise agents define eight, nine, sometimes eleven coarse states, each flow with its own state machine. A personal app doesn't need that machinery. A plain enum — waiting, processing, running a tool, error — covers it.

The same goes for intents. My scenarios are fixed, so I get by with four: create a task, query a task, modify or delete, change a setting. One carefully built classifier handles the overwhelming majority. The fuzzy stuff — "just sort it out for me" — falls through to the executor or comes back as a clarifying question.

Instructions: keep them central and short

The enterprise recommendation is a dedicated instruction system: i18n decoupling, versioning, a preview UI, character budgets. That pays off when a big team maintains prompts. For a solo developer, it's mostly overhead.

I keep everything in one constant area, visible at a glance, interpolated with plain template strings. No template engine, no versioning machinery. Multi-language means a separate copy in the code. And one rule I refuse to break: never trim the sentence the user is currently speaking. You can compress history and slim context all you want, but the words coming in right now stay complete.

Tools: four tools, no negotiation

Enterprise agents register ten or more tools with capability tags and a trust matrix. My whole app runs on four: create a reminder, query tasks, modify or pause or delete, change settings. Requests are serial — one thing at a time. No parallel execution, no trust tiers (every tool is built into the app), no approval flow (the user is the admin). Tool descriptions stay short, because the model is tuned to one scenario and already knows the argument shapes.

Local-first: privacy is a design consequence, not a feature flag

Enterprise agents budget for masking, audit logs, and permission controls because their data crosses servers and touches many roles. A personal app is simpler: data stays on the device. No masking, because nothing leaves. No audit logs, because there's no multi-user operation. No approval flow, because the user owns the data. A local database with basic local encryption is enough — no accounts, no cloud sync. Your data really is yours.

That also trims retrieval down to almost nothing. No multi-path recall, no query rewriting, no result fusion. At this scale, a plain local query is all you need.

Errors: retry, then be honest

Enterprise agents define multi-level recovery: forced retries, stepped context compression, resuming truncated answers, pre-running side-effect-free tools. I tried to care about all of that, and then I cut most of it.

Now it's practical: if a model call times out, retry once or twice, then say something friendly. If a tool fails, say "can't do this right now, try again later." If the output is malformed, ask once more with a stricter format. Every failure falls back to an honest "I don't know how to handle this," and the app never crashes. Pre-running, resuming, forced tool use — a personal app doesn't need any of it.

Observability: a log file is a tracing stack

Enterprise teams ship full tracing so they can replay problems offline and run regressions. I don't need that, but I don't want to be blind either.

I log each model call's input, output, and duration to a local file, keep a trail of task create/edit/delete operations, and record enough on failures to investigate. It's not replay-and-regression, but it finds ninety percent of my bugs, and it cost me zero infrastructure.

Run one path end to end first

Here's the whole design in one line: two levels, three to five intents, centralized instructions, a handful of tools, local-first data, simple errors, lightweight logs.

"Good enough" isn't sloppy. It's deliberate trimming — but only after you understand why the enterprise design is complex in the first place. If you start from an eleven-state framework with multi-layer tracing, a personal app will die at the prototype stage. If you start from "a sentence goes in, the classifier sorts it, the executor does the work, a result comes back," you can have the core path running in days, then grow it as real needs show up.

Google Play: the gates an AI-native app has to pass

Once it runs, release is a second journey. A few things bit me on Google Play that I want to save you from.

Permissions are the most common trap. Ask for only what the app truly uses, and prefer system capabilities over sensitive permissions. My app is voice input plus local reminders, so its permission footprint is small — that respects users and keeps review smooth.

A privacy policy is mandatory, and for an AI-native app it matters more than usual because voice input and intent parsing make people nervous. Mine is short and strong: data stays on the device, the cloud is used once for understanding, nothing is retained.

The data-safety form needs care too. Play asks what the app collects, why, and whether it's encrypted in transit. The key is honesty — declare what the code actually does.

One easy-to-miss item: the Android ecosystem keeps shifting its compatibility requirements for new devices, and you have to adapt your app's install format and target version before you submit, or you risk a rejection near launch. None of this is hard, but it's all real.

Shipping isn't the finish line. For a solo developer, getting the app into real hands is where the loop actually starts. The same is true of the agent itself: get one simple path working, let people use it, then make it better.

I'm writing the full solo-developer loop — product definition to release to operations — at lumi.alanluma.com/blog.

DEV Community: qiu alan