DEV Community: Dmytro Shevchenko

Using MCP for a support handoff

Dmytro Shevchenko — Sat, 24 Oct 2026 10:38:11 +0000

Before I pick up a question about an order, I'd want to see what we've told the customer so far. I wouldn't want to ask the customer for something they've already sent. The message in front of me might be their second or third attempt to get an answer. I'd want the assistant to read back a little, too.

I work on DobroDesk, where an AI client can use MCP (Model Context Protocol) to call support tools. With that client connected to the workspace, I could ask: "Find the open conversation about order 8142, read the messages and suggest someone to take over." I've made up the order for this example.

The latest message might say "Any news?" I'd need to go back further to understand that. The timeline can flag that older messages may exist outside the recent window it returns. It also flags text that's been shortened. I can get more of an individual message by ID.

An order number would help me find the right conversation. I'd look through the open ones in the Orders Inbox with search_conversations. Search only gives me metadata, so this isn't yet the assistant reading what the customer said. I'd have to allow message reading separately, even if I already had the ID of the message I wanted.

I might have a colleague in mind, but I'd still check the choices returned by list_assignment_targets. Those are people who can receive this conversation in its current Inbox. I might need the next page before I found the person I had in mind, so I'd use the cursor from that result. I could compare their availability and capacity there. They don't tell me whether Lena has dealt with the order before. That's something I would have to establish myself.

Before any of this is written, I would check the conversation and who I'm giving it to. In this example that's Lena. In this proposed client flow, the assistant would have to wait for my confirmation before calling assign_conversation.

I might lose the response after the assignment has been made. I'd keep the original request and its idempotencyKey. That's the request I'd send again. Getting a timeout wouldn't be a reason to make a new key and start another assignment. If the first request finished and left a saved result, I get that result back. Otherwise, I can't yet tell Lena that the handoff is done.

I'd be connecting the assistant as one teammate, not as the whole company. The assistant can only do what that teammate's role and the OAuth grant allow. DobroDesk also lets the owner limit the member, the application and that member's use of the application. All of them have to allow the action. The teammate doesn't get a new Brand or Inbox just by connecting an assistant.

I'd leave customer details and internal notes out of this job. I'd have to give it permission to read each of those separately. I don't have to allow either just to let the assistant read the messages in this conversation. Every time it calls a tool, DobroDesk checks what that teammate and the application are allowed to do.

If I revoke this teammate's access to the application, its current grants stop working. They could connect it again later, though, if the policies still allow that. To prevent that as well, I'd block reconnect for the same teammate and application. I don't have to block everybody else's connection to deal with this one.

I wouldn't use the reconnect switch on its own to cut off access. A grant that already exists can still work. I'd revoke those grants as well, for this teammate and application. If I allow them to reconnect later, they'll need to give consent again. The policies still have to allow it then.

AI helped with the writing and revisions here. This order and these colleagues are fictional, and this is a proposed workflow.

Keeping drafts and pending messages in a mobile support SDK

Dmytro Shevchenko — Wed, 14 Oct 2026 06:22:15 +0000

The order number I need might be on another screen. If I'm halfway through a support message, I'd like to go and find it, then come back to what I was writing. I wouldn't expect the draft to disappear because I pressed Back. I'd still be signed in, after all.

Leaving the chat

With DobroDesk, I can hide the view or unmount it and keep the signed session, draft and pending outbox. Hide also releases keyboard focus. I'd still need to type on the screen I'm going to, so the hidden chat has to let go of the keyboard. The customer can carry on with what they came to do.

The draft I want to come back to is mine. If somebody else signs in on the phone, I'd expect it to be gone. I wouldn't want them to open chat and find my message waiting to go out. That's why the host has to clear this state on signout and before it gives the SDK a different customer's identity.

When the response doesn't come back

I could have one message on the server and no message ID on my phone. If I try again, I'd still want it to be the same message. I might only have lost the response to the first attempt. I'd keep the request key from that first attempt. A new one could add another copy of my message.

I might have started with "Where is my order?" and be writing "Thanks, I found it" by the time the retry runs. I wouldn't want it to send the second text in place of the first. DobroDesk saves the first request before sending it, with its body, original timestamp and request key. That's what the outbox gives back to a retry.

So I retry with the saved values. For 24 hours after acceptance, the server can replay the stored response for a retry with the same saved values. A different body with that key gets a conflict. A day later, the message is still part of the conversation. It's the stored response that has expired.

The client unit test fails a send, restores the session in a new client and flushes the same outbox. It compares the two serialized request bodies. They're equal. An item saved for another account isn't flushed. Both clients use the same in-memory store, though.

Returning after the app quits

Keeping a request while a screen is closed tells me very little about what happens when the app quits. I need it to be there after the process has ended. Native integrations provide durable storage for that. If I use the headless client, I have to provide the store myself. I would test quitting and relaunching the app.

I'm coming back to the same conversation as the same customer. The token I had before might have expired by now, so I'd get a valid one before retrying. I'd leave the saved request as it was while renewing that access. The app needs to be active for the retry.

I'd look at the actual conversation, too. Getting the same request back out of storage wouldn't tell me if the server added it twice. I'd let it accept the message and then drop the response. After quitting and reopening the app, I'd retry that saved request within 24 hours. I should find one copy of the message in the conversation.

Why we build DobroDesk on Cloudflare Workers

Dmytro Shevchenko — Tue, 13 Oct 2026 13:02:37 +0000

DobroDesk puts email, website chat and in-app support in shared inboxes. A teammate can read the history, see the customer details and take over from AI when needed.

We build it on Cloudflare. Here is how that works when a customer asks for a booking and then needs help from the team.

A booking request in chat

A customer asks to book a consultation. With a booking provider connected and the action configured, DobroDesk can collect the service, date and time, check availability and show a proposed slot. The customer confirms before the booking is completed.

Sometimes the request changes halfway through. The customer may need a different service, or the provider may fail to return an answer. A teammate can then take over with the details already collected in the conversation.

That handoff matters. The customer should not have to explain the request again, and the teammate needs to know what was tried and what still needs attention.

Where the messages go

A booking request has more than a few chat messages. There is a customer, a conversation history and the result of the action. We keep that support data in the workspace's Durable Object, using SQLite.

D1 holds shared account and routing information. R2 stores files, including email attachments. This keeps the conversation data together without putting large files in the same database.

Some work continues after a message arrives. An email needs parsing, a reply needs sending and a failed delivery may need another attempt. We use Cloudflare Queues for those jobs. A customer can send a message while the service handles the next steps in the background.

Retries need care too. Receiving a provider event twice should not create two conversations, and retrying a reply should not send it twice. Those are the kinds of cases we check when changing the flow.

AI and the team share the conversation

AI can prepare a reply for review or answer routine questions automatically when the workspace enables that mode. It uses the knowledge and rules the team has configured.

Sensitive or uncertain requests go to a person. The booking action follows the same approach: it can complete the configured steps after confirmation, while a teammate handles the cases that need a decision.

For the support team, the useful part is seeing the messages, customer details and action results together. They can continue the conversation from that point.

Updating the product while chats are open

A customer may leave a chat open while we release an update. We keep versioned widget files and support the previous running version so an active conversation can continue. We also check restored sessions and conversation history during releases.

The Mobile SDK brings native support screens to iOS and Android, with packages for Flutter, React Native, Capacitor and NativeScript. Version 0.2.0 is published. Teams can add support to their app and handle the incoming conversations in DobroDesk.

We have also been improving conversation loading and switching in the inbox. We focus on everyday steps, such as opening a conversation and moving to the next one.

You can try the interactive demo. The SDK guides cover installation and configuration when you are ready to add support to an app.