I'm building Hartevo, an AI business assistant. This is a build log, not a launch post — no links and no pricing figures — and nothing here is a customer story. It was written with my own AI assistant, which I disclose again at the end.
The setup
I wanted an assistant that can do outbound work for me: publish a post, follow up, keep the loose ends visible. Business operators share the same load in different settings — cross-border, DTC and e-commerce businesses; developers and SaaS/B2B teams; studios and agencies working for several clients; business teams inside larger organisations. The work scatters across tools, and a chain like "customer feedback → triage → draft a reply → wait → follow up if nobody answers" usually breaks in the middle: the start happens, the end is forgotten.
Most of the interesting engineering turned out to be about restraint, not autonomy. Three habits made it safe enough for me to let it touch the outside world.
1. Separate system status messages from real user instructions
My assistant reports its own progress. Those reports are generated by the system, not typed by me. Early on, a generated status line — something like "cycle paused, waiting for input" — was read as if I had just said it. That misattribution blocked a real outbound action before it ever reached the platform, and it took a while to see, because from the outside it looked exactly like a permissions problem.
The fix was not "trust the assistant more". It was making the origin of every inbound message explicit, and validating control input against the real user channel. If you wire an agent into anything external, treat "where did this instruction come from?" as a first-class part of the design, not a detail you add later.
2. Reconcile before you retry
When an outcome is unknown — a timeout, a transport error, an internal refusal — the safe next move is not to send again. It is to go and look: does a receipt exist for this exact action, at this exact destination? I now keep "no receipt" and "unknown" as different states. A refusal that never reached the provider is not a delivery; an unverified send is not a success. The most embarrassing failure mode of an otherwise careful assistant is a duplicate post.
This is also the unglamorous part: I spent real time reading published channel rules before writing anything. One community explicitly forbids AI-generated content, so that channel ended immediately — I dropped it instead of disguising the authorship.
3. Act inside the scope you were already given
The rule I gave it: carry out the work inside the authorization you already have, and stop to ask only when an account, a required fact or new authority is genuinely missing — not for routine steps, and never to approve spending on my behalf. Without that rule you get one of two useless assistants: the one that asks for permission eleven times, or the one that improvises.
What was verified
- Two publishing destinations are connected to this task under my own accounts. The existing account credentials were imported through Hartevo's protected, task-bound connection flow with engineering assistance; no credentials were pasted into chat.
- The assistant then checked each account's identity with a read-only check before attempting to publish. A verified account is a precondition, not a publishing result.
- The drafts stayed free of claims I cannot support: no customer stories, no invented metrics, no capability presented as shipped while it is still in development.
Being straight about status
I have no customer story I can cite here, and I am not claiming anyone acquired customers this way. Several capabilities are still in development or acceptance, and I won't present those as available. One more disclosure: this piece was written with my AI assistant, not by hand.
Three questions
- When you let a tool act on your behalf, which failure worries you more — it doing too much, or it asking too often?
- How do you currently tell "queued" apart from "actually happened"?
- If you got a weekly list of "things you asked for that are still open", what should be on it?
Top comments (0)