Building an AI agent that always asks first

Syncflow takes a goal, uses AI to break it into small steps we call crumbs, and gives them to you one at a time. Autopilot is the beta feature that lets AI and agents do some of those steps for you.

Where the idea came from

I've always been driven to do things carefully, especially when someone else will see or use them. But big tasks hide small steps we skip because they look obvious, and sometimes those are exactly the ones that matter. I noticed it when I changed my car's brakes: finding the right parts was only half the job. The other half was the background stuff, like torque specs and how to unlock the electronic parking brake.

So I asked myself: what if Syncflow could research and handle those steps for me, inside the plan I already have? That's Autopilot. AI and agents doing the steps you allow, without prompting an LLM and copy-pasting answers.

Why it always asks first

If the AI could do everything on its own, it would be the end of the world as we know it. AI can have a lot of knowledge, but the context and the constraints we give it are the main safeguard against really bad outcomes: security breaches, leaking personal information, or breaking business conditions that we as humans agreed on for reasons that depend on human relationships and agreements.

So Autopilot was designed around three rules:

• Autonomy is a ladder with a ceiling, and the user decides how high each rule can go.
• Rules can only make limits stricter, never looser.
• Trust is earned in stages: simulate, then preview, then shadow, then act.

The Action Ladder

With ChatGPT, you prompt, you read the answer, and then you do the work yourself. Syncflow already has a nice UI to mark a step as done, and it updates the next steps if you comment. That part is solved.

But imagine you're the owner of a tire repair shop, or someone in marketing with no coding knowledge, and you're planning several tasks. You'd want everything marked as digital or coding work to just get done for you. That's where the ladder comes in. Every action Autopilot can take sits on one level:

1. Research it. Reads around the step and writes tips, resources and common traps. Nothing changes; you review the notes.
2. Plan it. Breaks the step into smaller steps you can edit or delete.
3. Draft it. Produces the actual thing as a draft (the email, the outline, the checklist) and attaches it. You finish it and mark it done.
4. Work with me. Proposes the next small move as a thread on the step and waits for you each time. This one needs a paid plan.
5. Complete, then ask me. Does the whole step and stops. The step waits for you to approve, reject or edit it.
6. Complete and decide. It's on the ladder, but switched off for every plan and every setting.

The default ceiling is level 5. Nothing is marked as done by Autopilot without a person approving it.

Every step is classified first (how long it takes, what kind of work it is, whether it needs a human), and rules use that classification to decide what to do. The classification still needs to get more accurate, and that's one of the reasons Autopilot is in beta. But it's already functional.

Guardrails

Seven guardrails apply to every rule, no matter what the rule says:

• An autonomy ceiling, capped by the account's plan. A rule can lower it, never raise it.
• A daily budget of 20 actions, where every step gets one action before any step gets a second one, plus a separate daily token limit to protect the user's AI provider bill.
• Off-limits work. Physical, financial, health and personal steps are never completed automatically.
• Hands off work in progress. If you started a step, Autopilot doesn't touch it, and queued work is cancelled the moment you start, finish or skip it.
• Quiet hours. Work waits until your active hours, so nothing runs overnight without anyone watching.
• A limit on approvals. When too many results are waiting for you, Autopilot pauses and reminds you instead of piling up more.
• Auto-parking. Three failures in a row and a rule stops trying until the problem is fixed.

And two kill switches: users can pause everything from the app, and I can stop Autopilot for everyone without a deploy.

The direction I'm most excited about is making these decisions depend on the user's expertise. If we build good memory and accurate relations between each user's data (trends, time to complete, skipped tasks, their profile, their prompts), we can understand each user really well. Then Autopilot can save people many hours on exactly the things they're not experts in, by researching or completing those tasks for them.

Earning trust before acting

A new rule never goes straight to real work:

1. Test run. Simulates two weeks against your real tasks or a sample project, with the same rules and guardrails as the real thing. It never calls your AI provider and never changes a task.
2. Try it on one crumb. One real action with your key, shown as a preview and applied to nothing.
3. Shadow mode. Three real days where Autopilot only writes down what it would have done.
4. Live, inside every guardrail above.

When a result is ready, approving it works exactly like finishing a step by hand: the step moves on screen right away, the phone vibrates, the last step of a plan gets confetti, and if the server call fails, everything rolls back with a message.

Syncflow as the orchestra conductor

If you already have your own agent environment, like Claude Code, why not use it? Syncflow doesn't compete on the quality of the models or on prompting. Syncflow orchestrates. It's like an orchestra conductor: it knows how music works, but it's not focused on one instrument. The instruments are the user's own agents, connected through MCP.

Setting it up is one command:

claude mcp add syncflow \
  -e SYNCFLOW_API_KEY=… \
  -e SYNCFLOW_EXECUTOR=1 \
  -- npx -y @syncflowme/mcp-server

It's a pull model. Your agent says it's alive, claims work, does it and sends the result back. Nothing is ever pushed into your machine, and SYNCFLOW_EXECUTOR=1 is an explicit opt-in: without it you still get the Syncflow tools, but nothing picks up work. And "Claude Code is online" becomes something a rule can use: coding work goes to your laptop while you're at your desk, and something else happens when you're not.

Building it with parallel agents

It was amazing. I defined the architecture, the functional requirements and the UI constraints, and I focused on the feature, the data and the infrastructure. The agents took care of component encapsulation, clean code, single-responsibility components, and writing tests from the natural-language specs I gave them. I built it in seven batches, each one split across agents working in their own git worktrees.

Honestly, this is where I got proficient in what's called Harness Engineering: creating feedback loops in my local agent environment, so every change, from another agent or from me, gets checked and reviewed in cycles, and they give me feedback and their plan. Around 30% of the time the plan was exactly what I was aiming for. The rest of the time it needed a small tweak, or I had to redefine things the AI had assumed.

Two lessons from that way of working:

• "Done" isn't the same as merged. One agent reported a 1,368-line branch as integrated, but it was never merged. Only the check I run before cleaning up worktrees caught it.
• Parallel agents have a real cost. Four agents used up a session's usage limit in about an hour, so now agents commit after every verified piece of work.

What went wrong

It worked everywhere except where users are. The app only forwards API calls to the backend for paths listed in a routing map that is fixed at build time, and automations were never added to it. For about two weeks the feature couldn't be reached from the browser, while every server-side check passed. Since it was in beta, I found out through a couple of emails and the logs. Fixing it wasn't the slow part: a lot of things needed approval and re-authentication because some access tokens had expired.

The published package was behind the repo. npm still had the first version of the MCP server, without the executor tools. Anyone running npx got the old version and never showed up as an executor. What users install is the product, not what's in your repo.

Types that only existed inside the monorepo. A type exported from a submodule of a shared package worked fine inside the workspace and disappeared from the published build. That cost one wasted release.

The lesson for me: test the full path, from the browser and from what users actually install, not just each part on its own.

Where it stands

Autopilot is in beta. Right now it's used by a selected group of colleagues and people around me, and they give me a lot of feedback. Most of it already went into the next updates, mostly in the frontend. For Syncflow as a whole, as of October 2026: 1,200+ users, 21 of them paying, and 68 active in the last three days.

The next big step is better task classification, so Autopilot knows more accurately which steps it can really take off people's hands.

For me, Autopilot is out of beta when it automates my own daily work across my different profiles: personal, professional and technical (I'm a car and mechanics enthusiast, it comes from my family). And when the background jobs, the backend API that works with the MCP server and the frontend run together like gears, without stopping or limiting each other.