← Back to blogPortfolio
ProductNLPBuilders

Building Tailor-Talk from messy user intent

Natural-language scheduling gets hard the moment people stop speaking in clean forms and start speaking like people.

The hard part of scheduling is not calling the calendar API. The hard part is surviving the sentence that comes before it.

Users do not say:

Schedule a 30 minute meeting on Thursday at 2 PM with Alex.

They say:

can you set something up with alex sometime late this week, not too early, maybe after that review

That is the real input. It is incomplete, vague, and full of hidden assumptions.

The mistake I wanted to avoid

I did not want Tailor-Talk to pretend certainty.

A lot of scheduling assistants fail by forcing fuzzy language into structured slots too early. They produce a confident but brittle interpretation, then push bad data downstream.

I wanted the opposite behavior:

  1. extract what is clearly known
  2. identify what is missing
  3. ask only for the minimum clarification
  4. keep the flow conversational

That sounds obvious. It is not. Most of the effort is deciding what not to infer.

What worked

Three things improved the system more than any model tweak.

1. Separate intent extraction from action generation

The agent should not jump from text straight into a tool call. First it should build an internal scheduling state:

  • participants
  • duration
  • temporal hints
  • hard constraints
  • unresolved questions

Only after that do I let it decide whether it can act or needs clarification.

2. Treat ambiguity as a product feature

If the system says "I need one more detail before I can place this," that is not a failure. That is the product behaving honestly.

Users forgive one sharp follow-up question. They do not forgive a wrong meeting.

3. Keep the interface stateful

Scheduling usually spans multiple turns. So the system has to remember what was already established and avoid asking for it again.

The experience gets dramatically better when the assistant feels like it is continuing a thread instead of restarting a form.

The broader lesson

Any product built on language models has to decide where it tolerates uncertainty.

For Tailor-Talk, the answer is simple: tolerate uncertainty in the conversation, not in the calendar write.

That single rule keeps the system honest, keeps the user oriented, and prevents a lot of expensive cleanup later.