5 things I got wrong about building an AI agent tool
I've been building KuberAgent for a few months now. Looking back, most of my early time went into solving problems that didn't actually matter. Sharing this in case it saves someone else the same detour.
- I thought more autonomy = more value.
My first instinct was to make the agent do as much as possible without asking questions. Turns out users don't want a black box that runs off and does 10 things they want something that does 2 things well and tells them what it's doing. I was optimizing for the wrong axis entirely.
- I underestimated how much people fear being embarrassed by automation.
Nobody wants to be the person who let an AI agent send a bad email, mess up a client deliverable, or post something wrong publicly. That fear is bigger than most feature gaps. I didn't design for it until users told me directly.
- I built for the "power user" first.
I kept adding configuration options — custom prompts, advanced settings, toggles for every behavior. Made sense to me as the builder. But most users just wanted a default that worked well out of the box. The config options I was proud of, almost nobody touched.
- I assumed onboarding was a UI problem.
I redesigned the onboarding flow twice, thinking better screens would fix drop-off. The actual issue was that people didn't understand what the agent could and couldn't do before they started. A one-line expectation-setting sentence fixed more than either redesign did.
- I waited too long to talk to users.
Classic mistake, I know it's said constantly, but I still did it anyway. I spent weeks building based on what I assumed people wanted. The first real conversation I had reshaped my roadmap more than a month of solo building did.
None of these were fun to realize. But each one saved me from building further in the wrong direction.
If you're building something agent-based right now has trust/fear of automation come up for your users too, or is that specific to my case?
The fear of embarrassment is real and I think its inversely correlated with how visible the action is. Internal data processing, nobody cares. External actions like emails, posts, or client deliverables, suddenly the bar moves way higher. We found that showing what the agent plans to do before it does it, plus making it easy to edit or cancel, dropped resistance significantly. The autonomy paradox seems to be that giving users control upfront lets you earn the trust to remove it later. Have you seen any difference between how solo builders vs teams react to agent autonomy?
The embarrassment fear maps to irreversible action. Give every external action a preview or diff, explicit approval, an audit log, and rollback where possible. Then measure the edit and rejection rate on proposals. A low rate earned over time is evidence to loosen autonomy; a toggle labeled autonomous is not.
Point 4 is the one that'll save other people the most time, "onboarding is a UI problem" is such a common misdiagnosis, when usually it's an expectations problem that no amount of redesign fixes, exactly as you found.
Did you get to measure drop-off before and after adding that expectation-setting line, or was it more qualitative signals like support tickets that told you it worked?
Honestly, more qualitative than a clean before/after. I didn't have proper funnel tracking set up at the time , so I can't give you a hard drop-off percentage.
That actually tracks with the "waited too long to talk to users" point, same instinct, just applied to metrics instead of users: build the thing, worry about measuring it later.
If you want a lightweight starting point rather than nothing, dropping 3-4 basic events into PostHog or Mixpanel's free tier usually takes under an hour and gives you enough to spot drop-off patterns going forward, even without historical data.