Guided intake

Harbour Insurance is a fictional insurer, and this page is where a customer starts a home claim. The agent is configuration, not code: five prompt fields, one function, two widgets and a script, all defined in demos/guided-intake and applied to the org through the admin MCP. The model is claude-haiku-4-5.

The script runs the conversation

A claim has an order that matters, so a script holds it. It has six phases: welcome and triage, emergency help, incident details, damage and evidence, cover check, and summary. Each phase says what happens on entry, what the model should do, what it may use, and what it collects.

• On entry, a phase runs fixed steps before the model says anything. The welcome shows three capability cards. Later phases offer suggested replies: an "open the form" chip, the cost bands, the contact options.
• Collects are named values, such as incident_type, incident_date, rooms_affected and cost_band. The model records them with record_script_data, and the platform checks each one against the script's declared schema.
• Gates decide when a phase moves on. Most are plain conditions, for example "incident_date, rooms_affected and description are collected". The triage gate has a second kind too: once the incident type and urgency are recorded, a model judges whether the visitor needs help right now. If it says yes, the claim goes through the emergency phase first.
• Narrowing keeps each phase to its own tools. The incident phase offers only the form; the damage phase offers nothing but its replies.

The model never moves the claim itself. It records what it heard, and the platform's gates decide.

The function and the widgets

guided-intake-check-cover is a function: literal sample policy rules (water damage, storm, flood, fire, theft and the rest, each with an excess and a limit) followed by pure steps that find the rule, apply the cost band and write one line of outcome. The cover phase calls it on entry, so the check always happens, and the agent can also call it to answer a question about cover.

guided-intake-incident-form is a validated form. The date must look like a date and the description needs ten characters before it will send. guided-intake-claim-summary is the finished claim file with a Submit claim button. Both are widgets because they are fixed, reusable layouts the model fills in. <mindset-agent> renders them and posts their actions back to the agent.

The page

No run event names a script phase. But inside <mindset-agent>, record_script_data runs in the browser, and its result carries the script run as the platform stored it: the collected data, the current phase and any judge's verdict. The page reads those events to fill in the claim file and move the step indicator. The claim file shows only the fields collected so far, plus the emergency verdict and the cover outcome once they arrive. The emergency step appears on the indicator only when the claim goes through it. The page then applies the script's own condition gates, read from the same JSON, to show where the claim goes next.

View script opens the script as a readable document: every phase with its entry steps, what it collects, what it may use, and its gate in plain words. It is generated from the same file that was applied to the agent, so it can't drift from what runs.

One page tool, lodge_demo_claim, marks the claim as lodged and returns a demo reference. It refuses while the claim file is incomplete. Situational awareness tells the agent whether the claim is lodged. Nothing is sent anywhere.

Under the hood

The pane lists every call: record_script_data as each value lands, the form and summary widgets, the cover function, and the page tool.

Build the same thing

Write the script with Write a script, the cover check with Build a function, and pin behavior tests with Test an agent's behavior. Embed it with the <mindset-agent> element.