4
8 Comments

We learned that an AI customer agent shouldn't try to answer everything

Hey Indie Hackers! 👋

After launching MySampark, we've been thinking a lot about one question:

What should an AI customer agent actually do?

At first, the obvious answer seems to be: answer every customer message.

But the more we looked at real business conversations, the more we realised that's not really the goal.

Businesses get a lot of repetitive questions:

“What's the price?”
“Is this available?”
“Do you deliver?”
“How long does delivery take?”
“What are your opening hours?”

These questions don't necessarily need a person sitting there waiting to answer every few minutes.

But then you get a completely different type of conversation:

“I received the wrong product. What should I do?”

“I have a problem with my order.”

“Can I speak to someone?”

That's where we think the human still matters.

So with MySampark, we're working toward a simple principle:

🤖 AI handles the routine.
👤 Humans handle what needs a human.

The AI Agent can respond to customer conversations using the business's information, while the team can step in when a conversation needs personal attention.

We're also trying to avoid the old-school approach of only responding when someone types an exact keyword.

A customer shouldn't have to say exactly “price” for the system to understand that they're asking about the price.

We're still improving this and learning from real conversations.

For founders building AI products:

What's one thing you've learned about where AI should stop and a human should take over?

I'd genuinely love to hear how others are approaching this.

— Hemangi
MySampark

posted toAvatar for product My Sampark
My Sampark
  1. 1
    The tricky bit is that 'routine vs human' isn’t fixed by task type alone. The same customer conversation can be routine until there’s a refund... an ambiguity... an unusual promise or reputational risk etc. The useful system handles the ordinary case but recognises when the context has changed enough that responsibility needs to come back to a person...
  2. 1
    I tend to find it easier to define the boundary by what the agent is allowed to see and do, rather than by whether a question is “easy” or “difficult.” For example, imagine a bookstore. If the official website already shows shelf location, stock status, price, and opening hours, I’d consider all of that safely inside the agent’s boundary. If the business also allows access to a reservation system, then the agent can go one step further and guide the customer to reserve the book. If it is allowed to see incoming-stock data, then it can say something like: “This title is currently out of stock, but the next shipment is expected around Tuesday.” I think of it a bit like a dog park. The Human builds the fence. Inside the fence, the AI is free to move. So the AI only really has to decide one thing: Is this inside the fence, or outside it? Inside: answer or act within the allowed scope. Outside: hand it back to the Human. That feels much cleaner to me than asking the AI to repeatedly decide: “Is this question simple enough?” “Is this safe enough?” “Does this need a person?” Define the information and action boundary first, then let the AI move freely inside it.
    1. 1
      I completely agree. The “dog park” analogy is a brilliant and highly practical way to frame it. When we rely on an AI to constantly evaluate whether a task is "too difficult" or "too risky," we introduce a lot of subjectivity and room for error. However, when we define the boundary strictly by access (what data it can read, what tools/APIs it can trigger), we shift from subjective judgment to deterministic rules. If the agent doesn't have the API to process a refund or check backend inventory, it simply can't do it—so the fallback to a human is immediate and natural. If a business later decides to empower the agent to do more, they don't have to spend hours prompt-engineering the AI to be "smarter"; they just expand the fence by granting it a new tool (like the reservation system you mentioned). It makes the architecture much cleaner, keeps the AI's behavior predictable, and ensures a much safer experience for both the business and the end customer. Define the capabilities, and the guardrails take care of themselves." Thanks for taking the time to expand on this — really valuable perspective for us as we continue building MySampark. I especially like the point about expanding the “fence” by giving the agent access to new tools when the business is ready. 🙌
      1. 1
        Yes — that’s very close to how I think about it. 😄 I especially like your way of describing expansion: when the business is ready, it deliberately gives the agent access to a new tool or information source, and the fence gets larger. One distinction I try to keep is that “visible or accessible” and “has authority to use” are not automatically the same thing. Where possible, I prefer to put only the information relevant to that job inside the working area, and make the usable scope and modification authority explicit. And when a request falls outside the fence, I don’t really want to punch an exception hole in the boundary for the AI. I’d rather give the Human a proper exit — for example: “For this, please contact us here.” → URL → Email → Phone That way the fence can stay simple, and when the business wants to expand it, the Human expands it deliberately rather than the model deciding that the boundary has moved.
        1. 1
          Spot on! The distinction between 'visibility' and 'authority' is crucial, yet often overlooked when building agents. Applying the principle of least privilege is the only sustainable way to scale these systems. I really love your approach of providing a 'graceful exit' instead of punching holes in the fence. Too often, developers try to prompt-engineer their way out of edge cases. Routing out-of-scope requests to a human fallback not only keeps the system architecture clean, but it also prevents the model from hallucinating outside its intended scope. At the end of the day, we need deterministic boundaries around non-deterministic models. Expansion should always be a deliberate architectural choice made by a human, never an accidental model behavior. Great perspective
          1. 1
            Exactly. 😄 I really like the way you put that: expansion should be a deliberate architectural choice, not something that happens accidentally because the model decided the boundary had moved. Glad the idea was useful, and I’m curious to see how you apply it in MySampark.
  3. 1
    The interesting part is that the boundary probably shouldn't just be 'routine vs difficult'. A task can be technically easy for the AI but still need a human because the consequence is high, the information is uncertain, or the customer is asking for something the business hasn't actually authorised. So I've started thinking about handoff less as 'the AI got stuck' and more as 'this has crossed a judgement or authority boundary'... That also makes human involvement feel like a well-designed system rather than a failure of autonomy.
    1. 1
      Thanks for this perspective — really insightful. I like the way you frame handoff as a success of the system’s governance rather than a failure of AI autonomy. The idea of defining clear authority boundaries is especially interesting for social media management, where the impact of a reply or post can be significant. It’s definitely something we’re thinking about as we continue developing MySampark.