The difficult moment in a business assistant is often the handoff. A customer asks for a person while a generated answer is still running, a worker retries an old message, or a staff member responds from an inbox at the same time. Without an explicit ownership model, both sides can speak over each other.
The Labverse WhatsApp AI Agent case study describes the business context. Reviewing its Python implementation reveals a more useful engineering story than response-speed claims: durable inbound events, controlled retrieval, conversation state, and a final dispatch check. The patterns below combine that source review with practical design guidance; they do not claim a fresh live delivery audit.
Model conversation ownership as state
Use explicit states for automated service, a requested handoff, and staff ownership. A takeover operation should change shared state, record the staff actor, and invalidate outdated automated work. Resuming automation should be deliberate, rather than inferred from a quiet inbox or the passage of time.
Labverse Agent's source includes takeover and resume paths, plus tests that distinguish authorized staff from unauthenticated callers. Its conversation guidance describes a single localized handoff acknowledgement and pauses automated replies after a human request. It also avoids claiming that a staff member is immediately available. That wording is a product decision with operational consequences: an acknowledgement is not a staffing commitment.
Store the event before asking the model
Validate the inbound request, persist the accepted event, and deduplicate using a provider message identifier scoped to the correct channel. A webhook acknowledgement should mean that the system has durably accepted the event, rather than that a model has already generated a reply. Separate the fast ingestion path from slower retrieval and generation.
The repository's ingress logic stores provider identifiers and deduplication information before scheduling follow-up work. A queue can deliver work again, so deduplication also belongs at the business operation boundary. Process a repeated inbound notification as the same event; do not create a fresh lead, handoff, or acknowledgement just because the transport repeated it.
Commit the next action with the conversation change
A database write followed by a separate queue publication can fail between those steps. A transactional outbox stores the intended job alongside the application change, and a worker publishes or processes it afterward. AWS's outbox guidance explains the dual-write problem and the need to handle duplicate delivery.
For a handoff, the durable operation can include the ownership change, audit event, and notification intent. If email notification later fails, the staff inbox should still show the request. Distinguish the saved request from the notification's delivery status so a temporary mail failure does not silently erase the customer's attempt to reach a person.
Check ownership again immediately before dispatch
An answer can be valid when generation begins and outdated when sending begins. Labverse Agent's sender checks current conversation state, an automation epoch, newer inbound messages, and channel availability before claiming dispatch. The epoch helps identify work created before a takeover or resume transition.
This illustrative pseudocode shows the local boundary; the actual implementation also needs durable jobs and provider outcome tracking:
begin transaction
conversation = lock_conversation(message.conversation_id)
if message.epoch != conversation.epoch:
cancel_message(message)
elif assistant_send_allowed(conversation, message):
record_dispatch_attempt(message)
commit
PostgreSQL row locking can coordinate competing database operations. It does not make an external messaging request part of that database transaction.
That distinction matters during takeover. A locally queued reply can be suppressed after ownership changes, but a request already dispatched to the provider may still arrive. Present the remaining uncertainty honestly. A staff interface should make recent automated attempts visible so the person taking over has context.
Keep knowledge and commercial authority separate
A retrieval system can answer from approved business information without being allowed to invent prices, deadlines, or contract terms. Labverse Agent's scope policy restricts executable outputs and treats attachment contents as untrusted. A document describing a quotation process does not authorize the assistant to approve a discount or change an agreement.
Use structured outputs for bounded intents, then validate those intents in application code. When approved evidence is missing, ask a focused question or request staff review. Avoid filling a gap with a plausible-sounding answer. Evaluate questions with ambiguous requirements and outdated documents, not only questions whose wording matches a knowledge-base heading.
Respect messaging rules at the point of sending
The current WhatsApp Business Messaging Policy, checked on October 16, 2026, allows replies without a message template within the 24-hour customer service window and requires approved templates outside it. It also requires clear escalation paths for automated responses and respect for opt-out requests. Build those checks into dispatch rather than relying only on the generation prompt.
Staff messages need those checks too. Human ownership does not extend a provider service window or reverse an opt-out. Store the timestamp of the relevant customer message, represent template eligibility explicitly, and show the staff member why a send is unavailable. Reassess the policy when changing the assistant's business purpose or messaging behavior.
Treat unknown delivery as a first-class outcome
A network timeout can occur after the provider accepts a request. Labverse Agent's sender distinguishes rejected requests from uncertain outcomes, records attempts, and has reconciliation behavior. Repeating an uncertain send immediately could duplicate a message; marking it failed immediately could mislead staff.
Keep pending, accepted, delivered, failed, and unknown outcomes distinct where the provider supports them. Monitor the age of unresolved work, not merely the number of queue entries. Use synthetic fixtures to exercise retries and provider events without introducing fake customer conversations into production.
Takeaway
A dependable handoff is a coordinated ownership transition across ingestion, generation, staff actions, and dispatch. Durable records and final send checks reduce avoidable races, while clear status language makes remaining uncertainty manageable. Test customer requests for a person, worker restarts, delayed callbacks, and takeover during generation before judging the assistant ready for daily support.
