Togable: what stands between a description in words and a working bot
A bot is described in ordinary words. After that the surrounding engineering does the work: a specification in which behaviour is written as scenarios, a separate container and its own database for each bot, checks of the queries against live data, and a report on what could not be done.
togable.xyz is open, the build starts after sign-up
How a bot gets built
Two steps between the conversation and a working bot: first the behaviour is written down as a document, then it is built and checked against that document.
The person's answers become not a retelling inside a chat but a separate document. Behaviour is written as scenarios, the commands and the data are listed there too, and it is people who edit the specification: the agent reads it before every next change to the bot. That is the source of truth the result is then checked against.
What comes out of a description in words is not one all-in-one file but a bot laid out in modules: categories, keyboards, handlers, the entry point, the database work. After every change the system compiles it itself and runs a smoke test, round after round, until it adds up.
There are no sources in the interface, and that is a decision by the product's authors, not a gap: the code and log tabs were removed deliberately, because they say nothing to the person who ordered the bot, while nobody was answering the question «what can my bot do». The specification took their place.
What comes out
The assembled bot at work, and the report the build ends with.
A bot assembled by this product takes an expense as an ordinary line and answers with a breakdown: amount, category, date, and how much has already been spent this month. The category is guessed from the meaning of the word, and if it guessed wrong, it is moved with a button under the answer. The bot counts the monthly total itself, which is why it accumulates from entry to entry.
The build ends not with the word «done» but with a report that says separately what was checked and what could not be done. Two blockers are named here that code does not get around, and one of them is waiting on a person acting on the platform's side. That is the difference between «the bot is built» and «the bot works».
What sits underneath
- Where a bot lives. Each has its own container and its own database. Bots do not see one another and do not go into shared storage, so someone else's records are out of reach even if one of them has a bug.
- What counts as the source of truth. The specification, not the chat with the agent. Behaviour is written as scenarios, the commands and the data are listed there too, and people edit it: the agent reads the specification before every next change to the bot.
- Where the limits are. The code is written by a machine, and that means it has to be checked rather than trusted. Database queries are checked against live data, and whatever depends on an outside party goes into the report separately and stays with a person.
Where it got hard
Three forks at which the product could have become the thing we did not want it to be. Each one has its cost of getting it wrong.
cost of getting it wrongone bot reaches the records of another, and we are not the ones who find out
Keeping all the bots in one process and one database is simpler and cheaper. Right up to the first bug in code nobody read line by line.
So every bot gets its own container and its own database. That costs more in resources and removes a whole class of errors at once: there is nowhere to reach someone else's data from, even if you wanted to.
cost of getting it wrong«make me a bot for expenses» can be carried out a hundred ways, and afterwards there is nothing to argue about
A request in words is not a brief. It contains neither what counts as the right answer, nor how the bot should behave when it did not understand.
Between the request and the code stands a specification where behaviour is written as scenarios, «when, then». The result is checked against it, and it also stays with the person to edit instead of hiding inside a chat.
cost of getting it wronga person hears «done» and learns the truth from their own users
A report in which everything is fine is more pleasant and less useful. Especially where part of the work runs into an outside party and cannot be finished.
So what did not pass goes into the report under its own heading, together with what exactly is required from the person. What was checked is named as checked right there: the database queries were run against live data, not declared working by eye.
Need to build something that can be checked afterwards?
We will build it so the behaviour is written down before the code, and the report names both what was done and what was not. We show a working prototype before you pay.
Discuss your task