From Recommended to Actionable: How Luxe Window Works Became Ready for AI Agents
Discovery was the first chapter. The second was a live, protected consultation request an outside agent could find, qualify, submit, and receive an honest answer for — without pretending the job was booked. Luxe Window Works is production proof that this infrastructure can work.
Mark Abplanalp
August 22, 2026
The story is short if you tell it honestly: Luxe became understandable, then verifiable, then recommendable, then actionable, then controlled. Visibility, schema, scheduling, automation, commerce, and governance tools usually stop at one isolated layer. This build connected them for a real service business.
The visibility foundation came first
Luxe did not start with an action endpoint. It started with a business that needed to be understood: who it is, what it installs, where it works, and why a homeowner should take it seriously.
That work produced an owned site, a connected entity graph, service and geography pages, and the discovery evidence already published on Kodecite — real answers from ChatGPT, Google AI Mode, Bing Copilot, and Gemini, captured April 1, 2026. Those screenshots are discovery proof. They are not this story.
Services and geography had to be explicit
A window-treatment business is not “we do everything, everywhere.” Luxe has product categories, service towns, and a real edge between in-area, nearby, and out-of-area.
Until those facts lived in one place, an AI system could recommend Luxe and still invent a visit, a product, or a city the business does not cover. Recommendation without a capability model is how wrong next steps get created.
Policies had to be reconciled before any action
The hard part was not the form. It was deciding what a request is allowed to mean.
An in-home consultation request is a request for human follow-up. It is not a reserved time. It is not a price. It is not project acceptance. Commercial work, third-party repair, price-only questions, and existing-customer issues are different intents. Those distinctions existed in the business before they existed in a contract.
The consultation capability
Luxe now publishes a machine-readable in-home consultation capability. The public contract is version 1.0. Readiness is request-submission-ready. Submission is enabled. Human follow-up is required.
The discovery URL is public on purpose. An outside agent should be able to read what Luxe permits without guessing from marketing copy.
Why booking stayed false
Because Luxe does not let a machine book the calendar. Direct booking, pricing, and checkout are unpublished. Success means the request was delivered for a human to follow up — not that a visit exists.
That is control. Calling the request a booking would have been a more exciting sentence. It would also have been false.
Rate limits and idempotency
Agent-intended requests are rate limited. Thresholds are not published.
Every agent request must include an idempotency key. A replay of the same key and the same request returns the original public result. A different payload with the same key is rejected. That is how you keep a confused agent — or a retry loop — from creating a second job in a real inbox.
Production discovery
The contract is live at:
https://www.luxewindowworks.com/api/capabilities/request-in-home-consultation
Anyone can read it. It states required fields, allowed intents, eligible markets, response statuses, and the rule that a successful request is not an appointment. That is the point of publishing a capability instead of hoping an agent infers one from a contact page.
The authorized test
One authorized production test used a valid in-area request. The system returned HTTP 200 accepted with reason in_service_area. The email reached the Luxe inbox.
The identical duplicate returned the original outcome. It did not send a second email.
The same key with a changed payload returned HTTP 409 idempotency_conflict.
Names, phones, emails, secrets, storage keys, and full request IDs stay out of this article. The public fact is the behavior, not the private payload.
What this proved
- An outside agent can discover the consultation capability at a public URL.
- The contract states what is required, what is optional, what geography is eligible, and what success does not mean.
- One authorized valid request returned HTTP 200 accepted / in_service_area.
- The corresponding email reached the Luxe inbox.
- An identical duplicate returned the original outcome and did not send a second email.
- The same key with a changed payload returned HTTP 409 idempotency_conflict.
- A human still had to follow up. That was the designed next step.
What this did not prove
- No appointment was created.
- No price was given.
- No purchase happened.
- No project was accepted.
- This is not proof that every Kodecite client automatically receives the same endpoint.
- This is not proof that every AI system will find or use the contract.
Transferability
The transferable piece is the sequence: truth, then capability, then control, then one action, then production acceptance. Recommendation is only one stage. The larger goal is safe agent participation. The Luxe contract is specific to in-home window-treatment consultations in a defined geography.
Another business gets a different action, or no action yet. A Foundation Build can stop at truth and discovery. An Agent Capability Build is scoped after the real rules are understood. Kodecite’s own site does not currently publish an autonomous submission endpoint.
If you want the earlier indexing chapter — the owned rebuild, the schema work, the crawl — that remains at How We Indexed 49 New Pages in 48 Hours. That is discovery infrastructure. This is the action layer that came after.
RELATED READING