Binge-eating Bot - Devlog

For the last week or so I’ve been working on a chatbot. This’ll be my space to work through my process, “out loud.”

Writing === thinking, afterall!

Fair warning: this won’t be very fun to read.

If you’re a coding novice maybe you’ll learn something.

If you’re an experienced developer, you probably won’t.

Here we go.


Binge-eating is a problematic behavior that many people struggle to control.

Certain cognitive-behavioral therapy (CBT)-based interventions seem to help.

But not everyone has access to a therapist. And not everyone has the will-power to follow through on CBT exercises on their own.

Enter: (placeholder name? real name? who knows).

When the urge to binge strikes, users can chat with (through a webapp, or through SMS), and the app will walk users through one of four CBT-derived therapeutic exercises.

Tech stack


- React


- NodeJS / Express
- DialogFlow
- Twilio (for SMS-interface)
- Postgres SQL db

Progress so far

As of today, I have the DialogFlow (DF) interventions scripted and ready. Front-end interactions are looking pretty good!

ugly-chatting See? Beautiful!

I have yet to implement the DF fulfillment routes that will save user’s information to the DB. That comes later.

In the meantime, I tried to port my DF agent over to Twilio. Ran into some issues.

I had hoped that there would be an easy-peasy, LEGO-style instant-snap-together integration.

But in my case, it looks like it’s not possible.

There are two possible ways to integrate the two apps together. They each produced weird UI issues when I tried to SMS with my bot.

1 - Google DF –> Docker / CLI witchcraft –> Twilio Autopilot.

No multi-messages

docker-building So slick. If only it worked.

The Google Cloud SDK CLI is, of course, very well put together. But in my case it didn’t exactly work out.

When I used it to export my DF agent, Twilio could not / would not send multiple text-responses.

(It’s possible that this is an SMS throttling issue — US-based numbers can only send one message per second)

My dialogs were very dependent on multiple text-responses, because my app has to explain some complex stuff to the user.

This meant that some important messaging got missed.

AND, it screwed up which cues my app would be listening for.


2 - Twilio Autopilot –> web-based UI import of Google DF.

Missing contexts

twilio import Beautiful! If only it worked!

Twilio’s CLI is also really well put together.

But when Twilio’s autopilot imports a DF agent, it omits one crucial feature: contexts.

Contexts are what frame the responses that the DF agent is looking for.

Let’s say your DF agent asks the user:

“Would you like to hear more about AirBird brand fannypacks? (Yes / No)”

…and the users answers yes or no. So far so good.

But then later in the conversation, the DF agent asks:

“Would you like to add an AirBird brand fannypack to cart? (Yes / No)”

The user will answer yes or no. But how does the DF agent know WHICH question the user is answering?


Without contexts to frame the conversation, any chatbot dialog falls apart.

Twilio has its own way to manage conversation flow. But when it imports from a DF agent, DF’s own contexts don’t get translated.

So of course, that totally broke my bot.

What’s next

The solution to this — the only solution, as far as I can tell — is to build both sides separately.

Build / implement the DF agent.

Then build / implement the Twilio Autopilot bot.

Time-consuming, for sure.

But the good news is that, even with my failed import into Twilio’s autopilot, Twilio still gives me a big heap of JSON files to start with.

I can take those, tweak em to add the contexts / multiple responses I need, and then deploy them.

Before I do that, though, I want to get the DF side to completion.

That means: fully fleshed out routes. Seamless communication with the front-end, AND the backend DB.

I’ll post updates as they come.