The user should drive the demo
A working session reveals more when the operator controls the case and the pace.
The useful part of a demo begins when the user takes control of it.
By October 2, I had sourced and contacted 30 insurance prospects for the Insuveo experiment. A reply had arrived, while meetings and a design partner remained unconfirmed. I then started looking more closely at which contacts were in Bengaluru so I could meet them over coffee and explore the product beside their work.
That change is about more than meeting in person. I can present a polished path through the Gmail style prototype from anywhere. I choose the mailbox and the question. I also decide when the answer appears. The product looks coherent because I control the sequence.
A working session gives that control to the operator. They choose what to open and which detail matters. Their next question can expose a product assumption I did not know I had. I have not run this session yet. It is the next experiment I want to make possible.
A presentation controls the evidence
The current Insuveo prototype uses fictional insurance messages. It can simulate a broker placement inbox, policy servicing, underwriting, claims, and other roles. Local retrieval can connect an answer to its source inside that synthetic world.
This is useful for building the interaction. It also gives me unusual control over the evidence. I know where the document is. I know which thread contains the answer. I can avoid a question that crosses two systems or depends on something said over a call.
Even a live demo with a friendly audience can preserve that control. People may understand the idea and say that it looks useful. Their reaction tells me whether I explained the product clearly. It says less about whether the product can survive an ordinary case.
The operator should be able to interrupt the path. They might ask why the system trusted one attachment or point out that the real status lives outside email. Those interruptions make the demonstration useful because they can improve the product.
A working session changes the unit of learning
I want the first local sessions to stay narrow. One person could bring an approved, anonymized case or recreate a familiar workflow without exposing private customer information. They would move through it in the order that feels natural to them. Insuveo could sit beside that work and attempt one useful task.
The goal would be to observe the distance between the product's model and the operator's model. Where does the person look before answering? When does a technically correct summary still feel incomplete?
This kind of session can create engineering evidence. A missing field may point to an extraction problem. A source that is technically relevant but operationally outdated may reveal a retrieval problem. The operator's response can also show that the workflow is solving the wrong moment.
AI workflow development needs this contact because model output is shaped by the surrounding process. A benchmark can test whether an answer matches expected text. A working session can show whether the answer arrives with enough context to support a decision.
Proximity still needs a boundary
Sitting beside someone does not create permission to inspect their inbox. The session still needs an agreed case and a visible access boundary. The operator should know what the system receives and be able to stop the test.
Local contact may make this easier to discuss because the product and the work can be examined together. It does not remove compliance or confidentiality. Ownership remains important. A useful session should expose those constraints early instead of treating them as later implementation details.
The same principle applies beyond insurance. An AI developer can learn a great deal from watching a person use software in the environment where the decision occurs. Screen recordings and analytics show actions. Shared work makes room for the explanation that accompanies an unusual action, including the moment someone decides the system is wrong.
I still have no confirmed design partner and have not completed an in-person working session for Insuveo. The Bengaluru outreach may lead to that evidence. It has not produced it yet. What I want to learn is simple: when the operator controls the case and the pace, does the product still understand enough of the work to help?