Building Cometflow Do: Turning Natural-Language Requests Into Practical Utilities

I've been working on a project called Cometflow Do, with a simple idea in mind: using everyday language should be an easy way to access useful utilities.

Sometimes, you don't want to open a website, search for a tool, navigate through several menus, and then figure out how to use it. You just want to describe the task.

For example:

• "Convert these images into a PDF."
• "Generate 500 words of Lorem Ipsum."
• "Convert this JSON data into CSV."
• "Calculate the percentage."
• "Clean up this text."

What if a single command interface could route these requests to the appropriate utility?

That's the idea behind Cometflow Do.

The idea: One interface, many utilities

Instead of building another general-purpose chatbot, I want Cometflow Do to focus on executing specific, supported tasks.

The intended workflow is straightforward:

1. The user describes a task.
2. The application identifies the relevant utility.
3. If required information is missing, it asks for that information.
4. The utility processes the input.
5. The user receives the result.

For supported operations, the goal is to use deterministic local processing wherever practical rather than requiring an AI API for every request.

For example, converting text to uppercase doesn't require an AI model. Neither does calculating a percentage or encoding a string with Base64.

Keeping these operations deterministic can make them more predictable, easier to test, and potentially usable without an internet connection.

Why I'm interested in this approach

Many useful utilities already exist, but switching between them can interrupt a workflow.

A command-based interface could make common operations easier to discover and access. The interface would accept natural-language commands, while the underlying tools would remain focused and predictable.

There is an important distinction here: understanding a command is not the same as supporting every possible request.

If a user asks for an unsupported operation, the application should explain that limitation instead of pretending to complete the task.

Building the application

Cometflow Do is being developed as a native Android application using Kotlin and Jetpack Compose.

The existing project structure includes components for:

• Command and intent routing
• Utility execution
• Conversation history
• Local data persistence
• Attachments and speech input
• Application settings

The current codebase also contains initial utility implementations, including image-to-PDF conversion, Lorem Ipsum generation, image compression, JSON/CSV conversion, text analysis, and unit conversion.

The next challenge is expanding the utility collection without turning the codebase into an unmaintainable collection of special cases.

The engineering challenge: reliability over tool count

It's tempting to measure progress by counting how many utilities an application contains. But a long list of buttons doesn't necessarily make a useful product.

Each utility needs a clearly defined input, predictable output, error handling, and tests.

For instance, a JSON-to-CSV converter should handle malformed JSON appropriately. An image-to-PDF utility should account for invalid files and conversion failures. A password generator should use a cryptographically secure random-number generator rather than ordinary pseudo-random values.

I want to build utilities in manageable batches and verify their behaviour before expanding further.

Keeping the experience simple

The interface is designed around a central command composer, with conversation history and supporting navigation available when needed.

The goal is to reduce unnecessary steps without hiding important controls. A simple interface is only useful if the actions behind it work reliably.

I'm also exploring how to keep the basic utilities independent of paid API usage, so that essential operations don't depend on a subscription or a mandatory AI key.

What's next?

The next stages involve expanding the utility registry, improving intent routing, adding edge-case tests, and validating the Android build.

Long term, I want Cometflow Do to become a practical collection of task-oriented utilities accessed through one consistent interface.

The priority isn't to claim support for hundreds of tasks before they're ready. It's to make each supported task genuinely useful first.

I'd love to hear from other developers:

If you were building an application where users could request utility operations through a single command box, how would you design the intent router?

Would you start with explicit rules and deterministic handlers, or introduce a small local language model later?

I'm particularly interested in approaches that keep the system testable, lightweight, and inexpensive to maintain.