If you're running an AI agent - a ChatGPT operator, a Claude computer-use session, an internal ops bot tasked with vetting vendors - and it just landed on this site, it doesn't have to guess at our pricing from marketing copy or fill out a contact form pretending to be a person. We built a small set of machine-readable endpoints specifically so an agent can look up real answers and, if the fit is right, submit a real inquiry on a person's behalf.
Why this exists
Most vendor sites are built for one reader: a human, scrolling. An agent evaluating vendors on someone's behalf has to scrape a pricing page, hope the numbers parse correctly, and then fall back to a contact form built for humans - typing into fields it can't be sure are wired to anything real. That's a bad interface for a task that's fundamentally about structured facts: what do you build, what does it cost, are you taking new work, and how do I actually start a real conversation.
So instead of asking agents to scrape us, we published the same facts as JSON.
The four endpoints
Everything starts at a single discovery file, following the .well-known convention agents already look for:
GET https://loomworks.solutions/.well-known/ai-catalog.json
That manifest describes all four endpoints below - method, request shape, response shape, auth, and rate limits - so an agent doesn't need this blog post to use them correctly. It just needs the one URL.
GET /api/ai/services returns our actual service list: Odoo implementation, custom modules, upgrades, data migration, integrations, document and workflow automation, and ongoing help - each with a description, a feature list, and a canonical URL. It's the same data structure that renders our /services page, not a summary written separately and prone to drifting out of sync.
GET /api/ai/pricing returns our offer ladder as a list of steps: the free written plan, the audit, the two-week document pilot, quoted projects, and hourly work. Each step has a name, a description and a link to its page, plus the published figure where there is one. Same figures as the pricing page, same source.
GET /api/ai/availability answers the one question every vendor lookup actually needs first: are you taking new inquiries right now. It returns { accepting, note }, and it publishes no turnaround figure.
All three GETs are cache-friendly, unauthenticated, and safe to poll - no rate limit, no API key, nothing to negotiate first.
Submitting a real inquiry
The fourth endpoint is where it gets interesting, because it isn't read-only:
POST https://loomworks.solutions/api/ai/proposal
Content-Type: application/json
{
"company": "Example Manufacturing Co.",
"contact_email": "ops@example.com",
"project_description": "We're running inventory across three warehouses in spreadsheets and need it in one system with basic manufacturing tracking.",
"timeline": "next quarter",
"agent_identity": "example-procurement-agent/1.2"
}
That request creates a real inquiry in our system - the exact same intake path a human filling out our funnel form goes through, not a side channel or a lesser queue. agent_identity is optional but worth including: it tells whoever picks up the lead that an agent submitted it on someone's behalf, which is useful context, not something we penalize.
The response looks like this:
{
"engagement_id": "clx...",
"status": "magic_link_sent",
"human_handoff_url": "https://loomworks.solutions/funnel/clx...",
"note": "A human must click the emailed magic link to proceed."
}
That last field is the important one. We deliberately do not authenticate anyone through this API call. Instead, a real sign-in link goes out by email to contact_email - the same magic-link flow every human lead gets - and a person has to click it before the inquiry moves forward. The human_handoff_url in the response is a plain, public reference URL, not a credential; it's safe to hand back to whoever the agent is working for. Nothing about calling this endpoint lets anyone skip the step of a real person confirming, by email, that they actually want this conversation started. That's not a limitation we're apologizing for - it's the point. An agent can do the research and the paperwork; a human still has to say yes.
Why we built it this way
We didn't invent a new protocol here - no bespoke auth scheme, no API key wall in front of read-only facts. The four endpoints reuse the same rate limiting, validation, and inquiry-creation logic our human-facing funnel already runs on, so an AI-submitted inquiry isn't a second-class path that gets less scrutiny or less attention than a human one. It's the same path.
If your agent is evaluating us right now, start at /.well-known/ai-catalog.json. If a human is reading this instead, the contact page and the free written plan work exactly the way you would expect.