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 project proposal on a human'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 module development, upgrades and migration, CRM-to-Odoo migration, third-party integrations, custom solutions, and support — 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 published pricing bands (small implementation, medium, enterprise — each with a range and a timeline), the flat $75/hr rate the fixed-scope quote is built from, and the paid one-hour consultation. Same numbers as the pricing page, same source.
GET /api/ai/availability answers the one question every vendor lookup actually needs first: are you taking new work right now, and how long until I hear back with a real quote. It returns { accepting, leadTimeDays, note }.
All three GETs are cache-friendly, unauthenticated, and safe to poll — no rate limit, no API key, nothing to negotiate first.
Submitting a real proposal
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.",
"budget_range": "$10,000-$25,000",
"timeline": "next quarter",
"agent_identity": "example-procurement-agent/1.2"
}
That request creates a real engagement 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 engagement 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 human 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 engagement-creation logic our human-facing funnel already runs on, so an AI-submitted proposal 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 free spec interview work exactly the way you'd expect.