LetspingLetsPing

Autonomous customer service bot on a production database

You can let a support bot touch a production database only if every write goes through a governed gateway: the bot proposes a change, LetsPing freezes the request, a human approves or edits it, and your backend applies the change under audit. This article walks through the architecture: what the bot is allowed to read, how it proposes writes, how humans stay in the loop, and how LetsPing gives you an audit trail strong enough for disputes and compliance.

1. Separate read and write paths

Let the agent read from production via a read-only API or replica so it can answer questions and reason about accounts. Keep all writes behind a dedicated gateway that only your backend can call.

The support bot never talks to the database directly. It talks to LetsPing; LetsPing talks to your backend; your backend talks to the database.

2. Have the bot propose, not execute, changes

When the bot wants to issue a refund, cancel a subscription, or update contact details, it calls lp.ask() with a structured payload that describes the desired change.

const decision = await lp.ask({
  service:  "support-agent",
  action:   "update_customer_record",
  priority: "high",
  payload:  { customer_id: "c_123", operation: "refund", amount: 1200, currency: "usd" }
});

Humans see this payload exactly as the agent produced it, can correct mistakes, and only then does the backend apply the mutation.

3. Apply approved changes via a narrow backend API

Your backend exposes a small set of functions such as applySupportAction(decision). It enforces business rules, rate limits, and further validation before it ever touches the database.

This keeps the blast radius small even if prompts or models drift: the only thing the agent can do is send structured proposals through LetsPing.

4. Audit and dispute handling

Every approved or rejected change is recorded with timestamp, actor id, and payload diff. If a customer claims the bot did something wrong, you can show exactly which operator approved which payload and what was changed.

For higher-stakes scenarios, combine this with Accepting Agents as Customers so downstream systems can also verify actions cryptographically.