Patterns

Hand back what isn't sure

The core pattern. Your software acts on answers that clear your bar, and sends the rest to a person, a review queue, or a bigger model. You decide where the line is; HOBO tells you which side each decision falls on.

1. Ask HOBO the question.
2. If its confidence clears your bar, act on the answer.
3. If not, send it on, with HOBO's top two answers attached so the reviewer starts with a short list.

On real tool-call requests, against a model that always answers, this hands back about 11% of requests and makes 116 fewer mistakes in 1,933. Watch it on the home page.

Ask first when a detail is missing

"Book a table" fits your booking tool, but the tool needs a time and a party size. Calling it anyway means guessing; refusing means a bad experience. The third way is to ask.

1. Ask HOBO which tool fits.
2. For that tool's required details, ask HOBO whether the request gives each one.
3. If one isn't given, ask the user for it, by name, then call the tool.

Asking is something your system does by itself, so it doesn't wait on the bar. HOBO asks rarely and on purpose: 41 times in 1,933 real requests, 31 of them where independent labellers agreed a detail was missing.

Long documents, in pieces

HOBO trained on inputs up to about 1,500 tokens. For a longer document, split it into pieces under that, with a little overlap, and ask about each piece:

• Is the claim supported? Supported if any piece supports it above your bar; refuted if any piece refutes it above your bar; both at once goes to a person; otherwise not stated.
• Which span answers? Ask each piece with the candidate spans it contains, and keep the most confident answer that clears your bar.
• Too many tools for one request? Ask about the tools in groups, then once more among each group's pick.

The rule that combines the pieces is yours, so check it on your own examples like any bar: HOBO's confidence is measured per piece, not for the combined answer.

Small decisions, combined in code

One big judgment ("should we refund this order?") is hard to check and hard to trust. Split it into small questions HOBO answers well, each with its own confidence, and let your code combine them:

• Is this a refund request? (intent)
• Does the message give the order number? (a detail given)
• Does the order record support the customer's claim? (claim)

Each answer is checkable on its own, each has its own bar, and the rule that combines them is plain code you can read. If any step is under its bar, the whole case goes to a person.