haggl.ai Blog
Anatomy of a <meta name="haggl-negotiate"> Tag
When a human visits a vendor’s pricing page, they see a grid of three plans, a “Contact Sales” button, and maybe a coupon field. When an AI agent visits the same page, none of that matters. The agent isn’t going to scroll. It isn’t going to fill out a form. It’s going to scan the <head> for one line.
<meta name="haggl-negotiate"
content="https://haggl.ai/api/negotiate?vendor={vendorId}" />That tag is the entire entry point. Everything else — the ICP, the products, the trust ladder, the accepted proof types — is self-describing and discoverable from there. No SDK. No buyer-side integration. No prior knowledge of the vendor.
This post walks through what happens after the agent finds the tag. If you’re a vendor evaluating haggl.ai, treat this as the technical tour. If you’re an engineer on a buyer agent, treat it as the integration guide — though the integration cost is roughly zero, which is the whole point.
Why a meta tag at all
The web has a long history of declarative discovery: robots.txt for crawlers, sitemap.xml for search engines, OpenGraph meta tags for link previews, Schema.org for structured product data. Each won its category for the same reason: one file, no SDK, fully self-describing. Any client that knows the convention can participate. The cost of adoption on either side is tiny.
Agentic commerce needs the same shape. There are millions of vendor pricing pages on the web. There are a handful of agent runtimes (ChatGPT, Claude, Gemini, plus a long tail of custom procurement agents). Asking every vendor to integrate every agent is a dead end. Asking every agent to integrate every vendor is worse. The only durable solution is a declarative protocol where vendors publish a tag and any agent can find it.
That’s what <meta name="haggl-negotiate"> is.
Step 1: Discover the session
Once the agent has the negotiate URL from the meta tag, it issues a single GET:
curl -s "https://haggl.ai/api/negotiate?vendor=engie"The vendor responds with a self-describing session object:
{
"sessionId": "sess_...",
"vendor": "Engie",
"negotiate_url": "https://haggl.ai/api/negotiate/{sessionId}/offer",
"icp_segments": [ /* customer segments + max discount each */ ],
"max_margin_percent": 35,
"max_proof_age_days": 90
}The icp_segments array is the load-bearing field. It tells the agent which customer profiles the vendor wants to acquire, ranked by priority, each with its own discount authorization ceiling. A vendor might define an “Existing Customers” segment with up to 35% margin to give away, a “Residential” segment with up to 20%, and a “Multi-site Business” segment with up to 25%.
Critically: the ICP describes lifetime value, not conversion intent. The agent is already negotiating — conversion is handled by price. The ICP tells the vendor’s pricing logic how much discount to authorize for this buyer, based on four standardized dimensions: retention, expansion, cost efficiency, and network value. High-LTV profiles unlock deeper discounts. Low-LTV profiles get thinner ones — the churn risk is too high to invest. (More on that mental model in Your ICP Is Not About Who’s Ready to Buy.)
The session object is everything the agent needs. A buyer agent with no prior knowledge of this vendor can read the ICP, look at the products, and build a fit strategy — all from this single GET response. Self-describing endpoints are the reason no per-vendor SDK is needed.
Step 2: Assemble the proof package
The agent reads the ICP, looks at the user it represents, and starts assembling evidence. This is where things get interesting.
A naive integration would ask the user to fill out a form: how much do you spend on electricity, how many sites do you have, when did you sign your current contract. But the whole point of an agent is that the user doesn’t fill out forms. So the agent goes somewhere most form-replacement schemes don’t: the user’s email inbox.
Six consecutive monthly bills from any utility, cryptographically signed by the sending domain via DKIM, are simultaneously proof of: spend amount, payment consistency, account tenure, e-billing behavior, and provider identity. DKIM was designed for spam prevention. It turns out to be an excellent unfakeable trust signal — the sender’s private RSA key binds the email to the sending domain, so a forged receipt would fail signature verification.
The agent packages those .eml files alongside self-reported context — location, willingness to bundle services, target price — into a single POST.
Step 3: Submit and receive an offer
POST https://haggl.ai/api/negotiate?vendor=engie
{
"sessionId": "sess_...",
"target_segment_id": "new-consumer",
"message": "Stable residential customer in Paris 75011, 6 months
verified spend at €140-160/mo, zero payment gaps,
open to bundling gas. Looking for €120/month.",
"icp_fit": {
"dimensions": {
"retention": { "score": 0.90, "evidence": [...] },
"cost_efficiency": { "score": 0.92, "evidence": [...] }
},
"overall_fit_claim": 0.88
},
"proofs": [
{ "type": "email_receipt", "trust_level": "dkim_verified", ... },
...
],
"self_reported": {
"location": "Paris 75011",
"target_monthly": 120
}
}The vendor’s agent scores the package against its ICP, applies its private pricing rules, and responds with one of four statuses: offer, proof_requested, rejected, or pending. On offer, the response includes a plan name, rate, duration, signup URL, and expiry.
{
"status": "offer",
"fit_score": 0.84,
"fit_score_breakdown": {
"retention": 0.90,
"expansion": 0.50,
"cost_efficiency": 0.92,
"network_value": 0.20
},
"offer": {
"plan_name": "Preferred Customer Rate",
"rate": "€120/month",
"duration_months": 12,
"signup_url": "https://...",
"expires_at": "2026-03-18T00:00:00Z"
}
}The agent hands the offer to the user. The user clicks once. A qualified, verified, ICP-matched lead with confirmed willingness-to-pay lands in the vendor’s CRM.
Note that fit_score_breakdown is always returned — including on rejections. A buyer agent that got rejected can see exactly which dimension scored low and decide whether additional evidence would change the outcome. That makes the protocol cooperative: if the agent can find more receipts, it can come back with a stronger package and unlock a better offer.
What a human sees vs. what an agent sees
The clearest way to understand what the meta tag enables is to look at the same pricing page through both lenses.
| Human visitor | Agent visitor |
|---|---|
| Pricing card grid | <meta name="haggl-negotiate"> in <head> |
| “Contact Sales” CTA | GET /api/negotiate?vendor=... |
| Coupon code field | DKIM-signed receipts from inbox |
| Chat widget | Structured JSON POST |
| Three plans, three prices | One personalized offer keyed to ICP fit |
Same page. Two completely different surfaces. The whole point of the protocol is that the vendor only has to maintain one. The human-facing pricing page stays exactly as it is. The meta tag and the negotiate endpoint do the rest.
Why not an MCP server, an API key, or an SDK?
Reasonable question. The honest answer is that those approaches all require buyer-side integration, and buyer-side integration is the thing that kills protocol adoption.
An MCP server requires the agent runtime to know about the vendor in advance and to load a per-vendor adapter. An API key requires the buyer to register somewhere before they can transact. An SDK requires the agent to be built against a specific vendor stack. All three introduce a chicken-and-egg problem: the agent only adds support for vendors that are big enough to demand it, so smaller vendors never get integrated, so the long tail of the web is invisible to agents.
A meta tag inverts that. Any agent that can scan <head> and make HTTP requests can negotiate on any haggl-enabled site. ChatGPT, Claude, Gemini, custom procurement agents — all of them, with no per-vendor adapter and no SDK. The vendor controls discovery via a single tag. The protocol does the rest.
We’ve written more on this in haggl.ai Works With Every AI Agent and the comparison with other emerging protocols in ACP vs UCP vs haggl.ai.
The trust model in 30 seconds
Every proof signal the buyer submits carries a trust_level. The vendor agent weights evidence accordingly:
dkim_verified— cryptographically signed by the sending domain. Cannot be fabricated. Six DKIM-signed monthly receipts beat almost any other form of evidence.unverified— documents from a credible institutional source (PDFs, statements, signed contracts) that lack cryptographic authentication. Treated as plausible with reasonable skepticism.self_reported— facts the buyer declares directly. Not verifiable, but vendors know buyers have little incentive to misrepresent things like owning multiple properties. Scores lowest, but covers ICP dimensions that documents can’t reach.
DKIM verification happens server-side at haggl.ai before the vendor agent sees the proof. By the time a vendor’s agent sees a proof tagged dkim_verified, its authenticity has already been confirmed cryptographically. The vendor agent just reads the evidence and scores fit.
zkTLS is the next step up the trust ladder — full zero-knowledge proofs where the vendor can verify a claim without ever seeing the underlying data. That’s covered in zkTLS Explained and is rolling out in phase two.
How a vendor adds this to their site
Register at haggl.ai, define the ICP and product tiers in the onboarding portal, and embed the meta tag on the pricing page. The negotiate endpoint is generated and hosted at haggl.ai/api/negotiate — no backend changes required on the vendor’s side. When the vendor updates their ICP or pricing rules in the portal, the next buyer agent session reflects the change immediately. No redeployment.
That’s the entire integration. One meta tag. The vendor’s human-facing pricing page stays exactly as it is. The same vendor can serve a beautiful designed pricing experience to humans and a structured negotiation endpoint to agents, from the same URL, with no conflict.
The web is full of pricing pages
Most of them are about to start getting visited by agents — some of them already are, you just don’t have analytics for it (see Agents Already Visit Your Site, You Just Can’t See Them). The ones with the meta tag will be the ones agents can actually transact with. The ones without it will be the ones agents bounce from.
Drop the tag. Watch the agents arrive.
Full protocol spec, including the complete trust ladder, status codes, error codes, and the buyer-agent reference implementation: haggl.ai/protocol.
Related Reading: