The concierge
The concierge is our website agent: it diagnoses your problem, sketches a proposed system, and prepares an enquiry.
It runs the same agent we deploy for clients. Try it here before sharing your contact details.
Back to our workThe system, in front of you
Try the concierge.
Start with a real problem. It shares the same conversation across this page, the chat dock, and the project workspace.
Let’s talk about your work.
Describe the thing your team does by hand.
We’ll sketch a better way to run it.
The running architecture
Our own system · Try it on this page- 01
Your problem
Text or voice
- 02
Understanding
Facts and assumptions
- 03
Next question
A rule chooses
- 04
System sketch
Review and share
- 05
Your decision
Confirm before sending
The problem
Enquiries waited for a call
Understanding a visitor’s needs depended on someone being available. We needed a useful first conversation before booking time.
Different problems got the same sketch
An earlier agent matched keywords and returned a canned diagram. A dental practice received the same pipeline as everyone else.
What we built
01Facts stay separate from assumptions
Nine fields track industry, role, job, trigger, current process, pain, systems, constraints, and outcome. Each is marked stated, inferred, or assumed. A guess cannot overwrite what the visitor said.
02Only questions that change the design
Each field is weighted by how much it affects the proposed system. The agent asks at most three questions, starting with the job. It skips role and sketches when no useful question remains.
03Context for ten industries
Industry context supplies likely workflows as assumptions. The agent skips questions that context already answers and lists those assumptions with the sketch.
04Nine tools, reusable across interfaces
The server declares the tools; the browser runs them and returns results. Another frontend can implement the same contract.
05Decision rules outside the model
A server function chooses the next question. The model phrases it, using a fixed model tier and thinking budget.
Known limitations
Sketches can feel similar
Each diagram comes from one model call, rather than a component catalogue. It responds to the visitor’s problem, but sketches can still resemble each other.
Corrections do not update the stored understanding
A correction prompts a new model response. It does not yet update the structured understanding and rebuild the sketch from that state.
Assumptions look like facts
The system tracks stated and assumed details, but draws their nodes identically. The diagram does not yet show which details remain unconfirmed.
What it changed
- 01
A first conversation without the wait
Visitors can explore their needs and see a proposed system before a call. Sending the enquiry still requires approval.
- 02
The service is available to try
Visitors can inspect a working agent by using it on this page.
- 03
A working fallback
Without an API key, a scripted demo runs the same interface and tool calls. Missing database or email services also have fallback paths.
Questions
- Does it work without an API key?
- Yes. A scripted demo uses the same message protocol and tool calls to demonstrate the full flow.
- What model does it run on?
- A fixed, small model tier, guided by server-side rules and industry context. Harder conversations do not trigger a model upgrade.
- What stops it from sending an unapproved enquiry?
- Sending requires contact details the visitor stated and their agreement to be contacted. Assumed details cannot authorize a send.
- Could a client run this same agent?
- Yes. Another frontend can implement the nine-tool contract. The decision logic has no framework dependencies.
Bring us the processyou would rather not run.
Describe the work you want to automate. Get a starting sketch, then talk it through with us.