Can this request be completed safely here, or should a person take over?
Client Desk may answer from approved knowledge and prepare bounded actions. It must never invent evidence, widen its own permissions, or execute a consequential action without explicit confirmation.
Case-study thesis
What the finished product should prove.
This is the behavior to build toward. The implementation receipts below remain the record of what exists today.
The interaction is not the chat box. The interaction is the moment the system decides whether to answer, ask, refuse, confirm, execute, or hand the work to a person.
State model
The interface has to make these states real.
If two states would look identical to the person, the implementation is not finished.
01
Received
The request is visible before the system has claimed it can satisfy it.
02
Grounded
A reply is supported by approved evidence and exposes the source used.
03
Needs clarification
The request is incomplete or ambiguous, so the desk asks only for the missing information.
04
Proposed action
A bounded action is previewed with scope and consequence before anything happens.
05
Waiting for confirmation
The system is blocked until the person gives an unambiguous yes to this specific action.
06
Executed
The action completes once, returns a receipt, and exposes what changed.
07
Escalated
The human operator receives the conversation, evidence used, work already done, and reason for handoff.
08
Refused or failed
Unsafe, unsupported, stale, or failed work stops visibly without pretending completion.
Edge cases
The boring failures are part of the product.
Approved sources disagree with each other
The relevant source is stale or missing
A prompt-injection attempt asks the desk to ignore its policy
The user says yes after the proposed action has changed
A double click or repeated message tries to execute the same action twice
An action fails after confirmation
The client changes direction during handoff
Definition of done
The future case study needs these receipts.
A single recorded flow showing grounded answer, clarification, refusal, confirmation, execution receipt, and contextual handoff
Every grounded claim opens to the approved source that supported it
An action cannot run from a vague acknowledgement such as maybe or sounds good
Repeated confirmation cannot create a duplicate external effect
A failed action preserves the request and offers retry or handoff instead of resetting the conversation
When someone writes, I want the desk to finish the turn from knowledge I have already approved: a cited answer, a refusal where the request is unsafe, or a confirmed sandbox action. What it cannot hold comes to me with the conversation attached.
The engine is deterministic. A model does not own the allowlist.
The job
Finish the turn with the evidence still attached.
I needed a desk that could answer from work I had already approved, refuse what it should not touch, and still bring the rest to me without making the visitor start over.
The loop had to be something a reviewer could complete against fixtures: a cited answer, a safe refusal, a confirmed bounded action, and a contextual handoff. No invented accuracy. No live client systems in this pass.
The starting vertical is HAAM Client Desk itself. The offer terms exist. Observed client volume does not.
The service loop
Cite. Qualify. Confirm. Or bring it to me.
Each turn has to leave a record: what was asked, what source was used, whether an action ran, and why anything left the desk.
01
Answer from the corpus
If the question sits in approved knowledge, the reply cites the source. The desk does not invent a second corpus.
02
Refuse the unsafe turn
Injection, sensitive, and unsupported requests stop here. The refusal is required, not a tone of voice.
03
Confirm a bounded action
prepare_brief, request_meeting, or create_ticket can run after an explicit yes. Unknown actions fail. The desk cannot grant itself new ones.
04
Hand off with context
Commercial, unclear, or out-of-scope work becomes a structured note I can read in the operator view, including the conversation that produced it.
Design decisions
What had to stay true in the interface.
client.haam.co
01
Knowledge
The corpus is the only voice the desk is allowed.
I authored the sources and the policy together. If a fact is not in the approved set, it does not belong in the reply. That keeps the demo honest when a reviewer tries to pull it off-script.
Cited answers from the approved corpus
Source status visible when knowledge is missing or stale
No generated case studies or accuracy percentages
02
Permission
Confirmation sits in front of every action.
The allowlist is server-side. Repeats use an idempotency key so a double click does not create a second meeting. Meeting slots are the two written ones, not a free calendar.
prepare_brief, request_meeting, create_ticket
Unknown tokens such as send_invoice fail as a dependency error
Custom scope and commercial commitments escalate to kris@haam.co
03
Handoff
I should not have to reconstruct the conversation.
The operator view exists so the rest of the work arrives as a record: who wrote, what they asked, what the desk already did, and why it stopped. Retention is thirty days.
Structured handoff plus an operator page
Audit trail for answers, refusals, and actions
Deletion covered in the same test suite
The working stack
What actually runs.
Engine
Deterministic desk
turn() in lib/desk/engine.ts. Policy, corpus, actions, and handoff are local modules with no provider in the loop.
The public host is the same app tree. The visitor demo and the operator view share one store.
Host
client.haam.co
Vercel Next.js. The in-browser engine does not take live client traffic.
In evidence
What a reviewer can check.
01A reviewer can complete cited answer, refusal, confirmed action, and handoff against fixtures
02Three sandbox actions stay behind confirmation and an allowlist
03Unsafe and unknown requests fail in tests instead of improvising
04Offer terms stay labelled as terms, not as observed results
Where it stops
The public host is the working loop on fixtures.
There is no native app in this pass. Multi-tenant SaaS is out. I have not measured production load, and there is no independent accessibility audit in the evidence file.
A real client still needs a contract, a privacy arrangement, and an operator who will own the handoffs.
HAAM’s role
I wrote the boundary, then I built the loop that keeps it.
Offer terms, refusal and escalation, operator view, desk engine, evaluation harness, and local retention. Direct work, 2026.
The product was researched by trying to make it fail safely.
The working questions were concrete: what can be answered from approved knowledge, what must be refused, which actions can run only after confirmation, and what needs a human handoff. A versioned evaluation harness made those boundaries testable instead of leaving them as product copy.
20 eval cases
Adversarial testing
Policy design
Workflow mapping
Help improve this website?
Optional analytics. Google Analytics and Clarity load only if allowed; form, email, and chat content are excluded.
