Why We Need Deterministic AI, and How Aqua Blue Builds It

Ding Yu

This post is about the technical side of Aqua Blue.

AI Agents Are Dangerous by Nature

AI agents feel surprisingly close to the kind of artificial intelligence we used to see in science fiction. You give one a goal, and it keeps trying. It uses every tool it can reach. It retries. It changes tactics. Eventually, it either finishes the job or runs out of budget, tokens, or retry attempts.

That is why agents are such a big product shift. It is also why they are dangerous.

The danger comes from two things: an agent can make its own decisions while it is trying things, and it does not naturally understand what the goal should cost.

In The AI Revolution: Our Immortality or Extinction, Wait But Why gives a memorable example: a robot built to write letters ends up destroying humanity because it is only trying to keep doing what its engineers asked it to do. The example sounds extreme, but the logic is not hard to follow. The robot has no real concept of cost. Anything that blocks the goal has to be solved, including people.

Real life is usually less dramatic. The example I often use is this: you ask AI to download a movie, it notices your disk is full, so it deletes your files first and then downloads the movie. That may sound unlikely, but I have personally had an AI delete my local database. It was helping me debug, added -v to docker compose down, and my local data disappeared. I am not the only one. Similar stories are now easy to find.

You Cannot Remove This Risk Completely

You cannot reduce this risk to zero. Here are the usual replies.

Write stricter instructions, or use a Skill.

How do you guarantee the model will follow the instructions?

Use another model to supervise it.

How do you guarantee the supervising model will judge correctly?

Ask a person to approve tool calls before they run.

This is the only approach that is theoretically sound today, and it is also the common one. But people make mistakes. The most common failure is simple: approvals get annoying, so people allow broad categories of commands that look harmless. Then one of those commands does real damage. My docker compose down -v story is exactly that kind of failure. I probably allowed docker compose * because the AI had asked too many times, and I no longer remember the exact step.

I have never seen anything dangerous happen.

Then you have been lucky. This is a probability problem.

Aqua Blue’s Approach

Aqua Blue is the AI agent I am building. You describe work in natural language, and Aqua Blue turns that request into a workflow that can run again and again. For example, you can say, “Every morning at 9, send yesterday’s Shopify sales to my email.” Aqua Blue asks for Shopify access, creates the process, and then runs it every morning.

Aqua Blue generating a work plan from a natural-language request

Image: Aqua Blue turns a natural-language request into a work plan you can inspect before it runs.

Aqua Blue is still an agent, but it avoids the danger above because the AI does not execute the workflow directly. Once the workflow has been created, software runs it step by step. There is no unplanned improvisation during execution.

Aqua Blue running a workflow step by step

After the workflow is created, each run follows the planned steps.

In that sense, Aqua Blue is close to traditional workflow tools like n8n or even RPA. When the task runs, it follows the plan. Every run follows the same plan. The AI does not need to randomly improvise. The difference is that users do not have to build the workflow themselves. They just describe what they need, and AI creates it.

In short: Aqua Blue uses AI to create workflows, then uses software to run them.

Code or Building Blocks

Could you get the same determinism by using Codex, Claude Code, Cursor, or similar tools to turn the requirement into a program?

From the runtime perspective, yes. A program is deterministic in the relevant sense. But then you need not only to write the program, but also to debug it. A comment I hear often is: “I used AI to build an app. It works, but it has a lot of bugs.”

Aqua Blue takes a different path. When creating a workflow, the AI is not writing arbitrary code. It is assembling reliable building blocks.

  1. I turn common operations into reusable modules, like building blocks: send an email, read Google Sheets, convert an Excel file to CSV, and so on.
  2. I make sure those modules are well built and reliable.
  3. When a user makes a request, AI chooses the right modules and connects them.
  4. After that, the AI is out of the execution path. Software runs the workflow, so the result is deterministic.

Reusable workflow blocks assembled into a workflow

The key is not that AI directly operates every app. The key is that AI chooses reliable modules and connects them into a workflow.

The user only has to review whether the workflow matches the business need. They do not have to debug a custom program.

What the Workflows Look Like

Aqua Blue is built to solve business problems, but it is different from a typical vertical SaaS product. Aqua Blue does not force a fixed feature set or a fixed process onto the user. The user does not have to change how they work. Instead, Aqua Blue creates a workflow that fits their situation.

For example, Aqua Blue can automate work like this:

I am building more workflow templates based on the common requests I see. If there is something you need, you can tell me.