Recently someone asked this question to my SupportBot.
The quick answer is No, it is not.
Modifying Dialogflow’s behavior
In some cases, people wish to modify Dialogflow’s behavior. For example, someone would probably try and implement their own custom regex implementation on top of the existing entity recognition. Or perhaps you might want to add some way to identify common business identifiers such as ISBN numbers and bar codes. If it is absolutely essential that your bot building framework should do these internally (versus using a webhook, say), you should consider alternative bot frameworks.
Reasoning about Dialogflow’s behavior
In some cases, people want to see the code so they can understand why it behaves the way it does.
For example, in a recent article I wrote about catching swear words in Dialogflow, there were a couple of confusing exceptions. It would have been very nice to be able to see the source and understand the behavior.
How to get Dialogflow to do what you want
At the end of the day, we are building bots to achieve specific outcomes, and not to achieve complete Dialogflow enlightenment. 🙂
So without the benefit of being able to read the source, do we then give up on Dialogflow because it is too opaque?
I cannot answer that question for your specific use case. In some cases, the only option you may have is to go for a completely open source project such as RASA NLU and BotKit. (Although, to the best of my knowledge, I don’t think they implement contexts. If you are a RASA or BotKit expert, please leave a comment along with some documentation I can read to verify).
Improve your understanding of Dialogflow
What I can say is that Dialogflow is still built on top of some reasonably simple to understand concepts (especially if you are a little familiar with Natural Language Processing).
So you could start by improving your understanding of Dialogflow (my courses can help).
Know your backup options
In case you absolutely need to use a regex for some pattern matching, you could use, for example the @sys.any wildcard to get the whole text and do the pattern matching in your webhook code.
Make your bot more flexible!
I have to add an exclamation point here because you don’t have to follow the guidelines suggested by the Dialogflow team for everything. For example, whenever you think of Fulfillment, you think of webhooks. It doesn’t have to be that way though! You can actually move your fulfillment to outside of Dialogflow if you understand how the system works. For example, you can use this idea to fix one of the most irritating things about Dialogflow – its inability to handle typos.
Another example of making your bot flexible is to use multiple modes of input. Sometimes your bot simply doesn’t understand what the user says. In such a case, try and restrict the number of options the user might have (e.g. go from freeform text input to having the user select from a predefined list of options).
I intend to write a more detailed article about this someday, but by adding some preprocessing logic (before sending the user’s message to Dialogflow) and post-processing logic (after receiving Dialogflow’s response and before relaying it to the user) you can address many shortcomings in Dialogflow’s current implementation. Many times this will help you get around the fact that Dialogflow (as of this writing) isn’t open source.