We build 5 AI products. All of them follow one rule: the agent shows you before it acts

Vishnu JP — Wed, 21 Oct 2026 12:30:00 +0000

How a small team designs AI agents that do real work (code, marketing, phone calls, video, AR) while people keep the final say.

We're iBoson Innovations, a small product company. We started in augmented reality, and today we build five AI products:

Phoenix.vu: an AI coding agent that works alongside Xcode
Lyks.ai: AI product videos for Shopify stores
AI Agent Studio (aiagents.dev): no-code agents that answer calls and act in business apps
Blooming.sh: 40+ AI agents for marketing, sales and support
NoxVision.ai: real-time 3D object recognition for AR apps

This is our first post on DEV, so instead of a feature tour, I want to talk about the one design rule all five products share. We think it's the most important decision in any agent product.

Agents fail differently from chatbots

There's a lot of scepticism about AI agents here right now, and much of it is fair.

When a chatbot is wrong, you get a wrong answer. You read it, frown, and ignore it. When an agent is wrong, something changes: code gets rewritten, an email goes to a client, a ticket gets closed, a call ends with the wrong booking. The cost of a mistake moves from "I wasted 30 seconds" to "now I have to find out what it did and undo it".

That's why "fully autonomous" was never our goal.

Our rule: show, then act

Every iBoson product follows the same loop:

The agent does the work and produces a concrete proposal: a diff, a draft, a script, an action.
A person reviews and approves it.
Only then is it applied, and it can be undone.

Here's how that looks across the five products:

Product	What the agent does	What you review before it counts
Phoenix.vu	Writes Swift/SwiftUI, runs the build, fixes errors	A diff for every change, plus file snapshots before each write
Blooming.sh	Drafts posts, emails, sequences and support replies	An approval step per client brand before anything is published or sent
AI Agent Studio	Answers calls, queries data, acts in 100+ apps	Approval steps on the actions you choose, plus handover rules for calls
Lyks.ai	Writes a script from your product listing and generates a video	The script, which you can edit before anything is rendered
NoxVision.ai	Detects real objects through the phone camera	Your app decides what happens on detection; models stay private to your account

NoxVision is the odd one out. It's a perception SDK, not an agent that takes actions. But the same idea applies: it tells your app what it sees, and your code decides what to do with that.

Four things we learned building it

1. Make the proposal the unit of work

"The agent did some stuff" is impossible to review. A diff, a draft, or a numbered list of actions is easy to review. We design every agent around producing something with a clear before and after.

2. Make undo cheap

If undo is expensive, people stop trusting approvals, because one bad click costs too much. Phoenix snapshots each file before it writes to it, so you can roll back without relying on Git. Blooming keeps drafts separate from what's published.

3. Show the cost of every action

Agents can burn money quietly. Phoenix and Lyks both use pay-as-you-go credits instead of subscriptions, and Phoenix shows the exact cost after each request. Seeing "this fix cost 4 credits" changes how people use an agent. It also keeps us honest about whether each step was worth it.

4. Don't ask for approval on everything

Approval fatigue is real. If you ask someone to approve every tiny step, they start clicking "yes" without reading, which is worse than no approval at all. So the rule is about risk, not every step:

Read-only work runs freely: searching documents, answering questions from a read-only database connection, reading build logs.
Changes need approval: writing code, publishing content, sending messages, updating records.
Users choose the line: in AI Agent Studio you decide which actions need a human.

Something we got wrong

We built Phoenix into a gap: an Xcode-native coding agent, just as a well-liked tool in that space shut down. Then Xcode 26.3 shipped its own built-in agents from Anthropic and OpenAI. A big part of our pitch became something Xcode does by default.

We learned to position against what's coming, not just against what's missing today. We now tell developers who already pay for Claude or ChatGPT to try Apple's agents first. Phoenix is for people who want pay-per-task pricing and a diff-first workflow. Being fair about that has made the rest of what we say more believable.

What we'll write about here

One practical post a week, rotating through our products:

Reviewing AI-made fixes in Xcode, so a green build isn't hiding a bad change
Giving an AI agent database access safely
AR object recognition without training an ML model
AI video for e-commerce: what works and what doesn't
Running marketing with multiple agents without losing a brand's voice

We'll share code, trade-offs and mistakes, and say when another tool is the better choice.

Over to you

Where do you draw the line? Which actions would you let an AI agent take without asking you first, and which should always need a human? Tell us in the comments. We're using the answers to tune our defaults.

DEV Community: Vishnu JP