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
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 service loop
Cite. Qualify. Confirm. Or bring it to me.
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
Decisions.
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.
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.
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.
The working stack
Built with.
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
Evidence.
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.
