Collection

Notes

Real decisions from my systems, rewritten for people arriving from outside. Every note exists in both languages.

• Promise what your operation can sustain

  My opinion: the promise of human service is made by default, without anyone checking whether someone exists to keep it — and it costs more than promising nothing.

• What a technical suggestion does not bring with it

  Every architecture recommendation embeds a trade-off, and the trade-off is only settled with numbers from the system of whoever receives the suggestion — numbers the suggester does not have.

• What an agentic pipeline charges to cover the absence

  Agentic systems trade latency and cost for task performance, and the decision is about when that trade makes sense; in a service with nobody on call, the comparison is not the ideal, it is silence.

• What push guarantees, and what it leaves to the human

  The Push API spec solves the technical problem of reaching the device with the app closed; the problem of someone seeing it and acting in time remains entirely on the other side.

• What delegating to an agent does not delegate

  Public guidance for building with models is to start from the simplest solution and only add complexity when needed; whoever delegates the building still owns that criterion.

• The cloud budget is a real constraint, not an excuse

  I need alternatives that fit my cloud resource budget, and that limit is what makes me ask the price before I ask about the architecture.

• The form filled all at once is the hard case

  Dialogflow CX's documentation states that when several values arrive in a single turn, usually only one parameter is set — which explains why the well-behaved visitor is the one who breaks the flow.

• The fallback flow needs the same guarantees as the main one

  Continuing to collect data while nobody is available is a defensible product decision, and it turns against the visitor if the collection asks again for what they already gave.

• The data was there before the question

  The information arrived in the first message of the turn and was asked for again anyway — the problem was not the visitor being unclear.

• The cost a correct hold pushes into the queue

  Every item a control holds for good reason becomes review work, and Little's law says how long that work sits still.

• The button I added after the first turn

  In the latest version there is a talk-to-an-agent button that appears after the first turn and fires several notifications on the platform, push included.

• The notice was right and the experience was bad anyway

  The visitor was told the conversation would continue with an agent once one was present, went on through the defined flow, and the experience was not good because the data had already been sent.

• I know it's slow and I don't know more than that

  I cannot say where the corpus chat's slowness comes from: the choice was the agent's that built it, and what I have is the impression that it is slow and does not look right.

• Honesty about absence is an exit, not an excuse

  The advice to own the failure and offer an escape hatch applies just as well when the limit is availability rather than comprehension — and there the exit has to be a path that does not depend on waiting.

• They escalated as hot and were something else

  The campaign's interactions rose to hot lead on behaviour, not on intent — and the intent was job hunting.

• It warns, it tries to continue, and it misses what already arrived

  The notice that someone from the team will be paged goes out, the collection continues so the lead is not lost, but the form filled in the first message is not captured.

• I delegated the choice and kept the maintenance

  The chat's retrieval architecture was the decision of the agent that built it; I do not know what it was, and it is still mine to maintain and explain.

• Advice from outside is a hypothesis, not a diagnosis

  This is an opinion about method: I think a written remark does not decide architecture, and that what decides it is data from the system itself.

• Business hours are necessary and not sufficient

  Declaring a window settles the expectation; keeping the promise inside it requires someone on call, and a lead response survey found that nearly one in five companies did not respond at all.

• Between not indexing and indexing, there is the textual middle

  The cheap path is not a choice between nothing and a full vector pipeline: classic keyword search combined with embeddings is the recommended arrangement, and its textual half charges nothing per query.

• I gave notice, I kept going, and I offered no exit

  The notice said the conversation would continue once an agent was present; what the visitor got to do in the meantime was answer questions.

• Asking again is a state defect, not a conversation defect

  There is a documented mechanism for data already in the session to fill the form on its own; when re-asking happens, what failed was state propagation, not sentence understanding.

• The three measurements that turn "it's slow" into a diagnosis

  Time to first token, total generation time and output token count separate a chat that is slow from waiting from a chat that is slow from writing.

• The parts of an indexed knowledge base, one by one

  Ingestion, chunking, embedding, storage and search are five separate decisions; treating them as a single package is what makes the project look too big to start.

• Roughly two hours

  That was the time between the request for service and my reply.

• The escape hatch is part of the design, not an admission of defeat

  Usability guidance for chatbots includes offering an explicit path to a human; what it does not resolve is what happens when that path is taken and nobody is on the other side.

• Human review belongs in the design, not at the end of it

  NIST's AI risk management framework treats trustworthiness as a design consideration across the whole lifecycle — which includes sizing whoever reviews what the system holds.

• The preference is not for a human; it is for not being stuck

  What usability research records as well received is the bot owning the failure and offering an exit — which moves the question from "human or AI" to "solved or not solved".

• A one-person operation has to be designed as one

  My opinion: the mistake was not losing those two conversations, it was designing a flow that only works if I am available.

• The baseline is what makes "scale" a sentence with meaning

  Without a prior measurement, scaling has no success criterion: there is no number to say whether the change worked, and the feeling of improvement is the worst judge available.

• The campaign that brought applicants, not clients

  The first campaign, built without SERP data and guided only by simple prompts, filled the chat with interactions that escalated as hot leads and were people looking for a job.

• Protecting the chat without knowing who is asking

  Three ceilings, a manual ban and a single exception, fenced in writing: how this site's chat protects itself from abuse without storing who is asking.

• Fail-open or fail-closed: what is there to protect?

  I run two systems with opposite failure defaults, on purpose. Choosing between halting and carrying on is not dogma: it is a question about what the failure would cost in each direction.

• Guard the corpus, not the reply

  Everything that enters a public chatbot's corpus can come out of its mouth. The confidentiality check that works happens at the door, document by document, not in a filter chasing every reply.

• Language redirects break shared links

  Detecting the browser language and redirecting looks like a courtesy. In practice it swaps the page someone chose to share, and the person who sent the link never finds out.

• Read-only by construction

  The most reliable way to guarantee the site never writes to its CMS was not a rule or a review: it was a fetch type with no room for a write.

• One document per language, not localized fields

  In a bilingual site, the invisible decision is where translations live in the CMS. Localized fields hide what is missing; one document per language turns absence into a verifiable fact.