Middleware vs AI Architecture

In short. Bought middleware charges for every connection and makes every channel wait in one queue, translating product and customer IDs its own way at each step. This architecture keeps one record of customers, consent and product IDs in Xano, and lets a Cloudflare edge send to every channel at once — each send checked against the customer's consent first. The result is one set of clean IDs for agents and ads, budget spent only on audiences you may target, and bids weighted by predicted revenue instead of past spend.

The article at a glance

• The problem. One order must reach five places at once — an AI agent, Merchant Center, Google Ads, GA4 and the ERP — under one consent decision. Middleware queues them and maps IDs per connector.
• The architecture. Xano holds the record. A Cloudflare edge sends to each channel, and every send asks permission first. Your ERP, CRM and service bus stay; they receive the same record.
• Easier to run, faster to revenue. AI bindings and low-code orchestration (Xano function stacks) replace connector licences and cluster operations, so a change ships in days, not a project. The new bid values go live on the next audience push.
• The revenue scale. Predicted lifetime value becomes the bid value, and revoked customers drop out of audiences first. At $100M in online revenue, every 1% is $1M — so the stakes run into the millions. That's arithmetic, not a measured result: a holdout test gives the real number.
• The AI. Models run inside the same request, with no extra vendor hop. Claude task runners connect over /mcp under the same permissions. AI finds candidates; clean IDs close the sale.
• The speed rule. Everything runs side by side except the consent check: decide before sending, defer only the bookkeeping.
• Product Lead / BA owns the IDs. Every variant needs a GTIN, or brand + MPN. Never reuse or invent one.
• Trust. A barcode check digit catches typos, not fakes. Channel Publish refuses forged codes today; signed, verifiable links are the next step.
• EU data stays in the EU. Any plugin or CRM on a US server is a transfer that needs a legal basis, a contract and disclosure. Keep the EU record in the EU and send US tools pseudonymous IDs only.
• The cost. Two vendors instead of one, an outage path when the consent check is unreachable, and a Cloud Console handoff for predicted-value scoring.

The sections below expand each point, with the evidence.

Who this is for. A BA or product lead making the case to leadership, an architect choosing where integration runs, a merchant putting QR codes on packaging, and a compliance reviewer asked to sign off on the word verified.

Every system that acts on a product — an agent at checkout, a bid in Google Ads, a pick in a warehouse — acts on an identifier. Clean IDs come before agentic commerce, not after it.

Revenue benefit: build to revenue

Bought middleware is a cost line per connection. An AI binding on the record turns the same data services into bid value: consented buyers, weighted by predicted revenue, sent without blocking.

The revenue path runs through four steps. Each one either exists in code or is named as a gap.

1. Data services land in the record. Orders, catalog and ERP feeds resolve to one identity and one set of product IDs (GID, GTIN/MPN) in Xano.
2. The AI binding works in the request. Workers AI and Vectorize match and enrich in the same worker that holds the permissions check — no third runtime, no model API key.
3. Weighted data sets the value. A BigQuery ML model predicts each consented buyer's future revenue. The score comes back as a per-user weight, and Vertex feature extraction weights the tenant's own content for AEO.
4. The weight becomes the bid. The audience push to Google Data Manager sends predicted lifetime value as conversion_value in place of past spend, so Smart Bidding bids on where a targeted audience is going, not where it has been.

Easier to run, and why the stakes run into the millions

Easier to use. Bought middleware asks for a connector licence per system and, behind it, a cluster someone has to operate. Here, the AI is a binding — one line of configuration — and orchestration is a Xano function stack a BA can read. A new destination or a new rule is a change to one function, not a new contract or a new deployment pipeline.

Faster to revenue. The switch from past spend to predicted value takes effect on the next audience push. Google's bidding then goes through its own learning period before results settle, so "immediate" means the value is live immediately — not that the lift is.

The scale. Bidding changes act on all ad-driven revenue at once, so a small percentage is a large number. The table below shows what a given improvement is worth. It is arithmetic, not a forecast: the percentage is the thing a holdout test has to measure.

How to get the real number: split the audience. One half bids on predicted value, the other on past spend, over the same period and budget. The difference in revenue is the lift, and it is the only figure worth quoting to leadership.

Non-blocking, in plain terms

For the BA and leadership. "Blocking" means one job waits for another before it can move. "Non-blocking" means nothing stands in line that doesn't have to. That matters for revenue, because one order has to reach five places — the agent, Merchant Center, Google Ads, GA4 and the ERP — while the customer is still on the page.

Picture a restaurant. A blocking waiter takes one order, stands at the kitchen until the food is ready, delivers it, then takes the next order. A non-blocking waiter takes the order, hands it to the kitchen, and serves other tables while it cooks. Nobody waits for a dish that isn't theirs.

There is one exception, and it is the rule this design is built on: the waiter still checks the customer's allergy card before the dish leaves the kitchen. In this system, the allergy card is the customer's consent. Everything may run side by side except that check.

The rule: decide before sending, defer only the bookkeeping.

How each technology handles waiting

The same idea appears under different names across the stack. A thread is one waiter.

Who waits for what

Bought middleware usually gets this backwards. Its queue never blocks on anything — including the consent check that should have come first.

Engineering evidence: weights resolved with Promise.all, index.ts:11171; permissions checks bounded with gateEach(…, concurrency = 8) and fail-closed, release-gate.ts; deferred writes via ctx.waitUntil, 18 call sites in index.ts; weights cached in KV with a 45-day TTL, index.ts:6816.

What this section does not claim. No revenue lift is measured here, and none is quoted. Predicted-LTV scoring needs enough purchase history to train on, and BigQuery ML and Vertex need Cloud Console access that the analytics team owns. Without that handoff, the audience push falls back to past spend, and everything else above still works.

1. The challenge and the solution

Fee dependency vs. architectural map, in detail (the diagram at the top of the page). Both sides have fees. They attach in different places, and that decides what a sixth destination, a second environment or an agent costs.

Fee amounts are deliberately left out. They depend on contract and volume, so compare your own quotes against where the fees attach, not against a list price.

The challenge

One Shopify order now has to reach five places at once, under one consent decision:

• an agent or chatbot completing an exact-match checkout or search;
• Google Merchant Center, as an offer;
• Google Ads Smart Bidding, as a conversion or a Customer Match member;
• GA4, as a measured event;
• the ERP — SAP, Dynamics, or a CRM such as Salesforce — and the warehouse system behind it.

Each of those systems names the product and the person differently. Shopify says gid://shopify/ProductVariant/…; Merchant Center says an offer ID; the ERP says a material or item number; the warehouse says a bin and a SKU. A consent decision made in the browser has to arrive at all five before the payload does, not after.

The conventional answer is middleware on a managed cloud VM: one integration process, one queue, a connector per system, each connector translating IDs its own way.

That answer has a legitimate half. A VM is one deployment to reason about. Systems integrators know it, ERP connectors exist off the shelf, and an existing enterprise service bus already runs this way. The objection is not that it is old. It is what this shape does with IDs and consent when five destinations fire at once.

The solution

Xano is the system of record; Cloudflare is the edge that fans out. The record of who the person is, what they consented to, and which identifiers name the product lives in Xano rows. The Cloudflare Worker sends to each destination, and before any payload carrying a person's data leaves, it asks a permissions boundary in Xano — beside the consent rows — whether this subject may go to this destination. That check is per subject, per destination, and recorded.

The ERP, the CRM and the existing service bus are not replaced. They keep their roles and receive a projection of the same record, so they read IDs that were reconciled once instead of translating them again.

AI in the architecture: bindings and functions vs. bought middleware

The same choice repeats for AI. Bought middleware, such as an integration platform with an AI add-on, adds the model as another connector: the record is sent to the vendor's AI service, retrieval runs against the vendor's copy of the catalog, and the agent works through the vendor's runtime. In the built architecture, AI is a binding on the same worker that already holds the permissions check, plus functions over the same record:

• Workers AI ([ai] binding) runs embeddings, translation and chat models inside the request. It needs no API key and adds no third runtime.
• Vectorize (three bound indexes) holds the semantic catalog and the knowledge base.
• Xano functions and worker endpoints are the tools. Agents reach them over /mcp the way any client would, under a mandate, and every call lands on the same ledger.

The legitimate half of buying: a vendor AI layer arrives supported, with an SLA, packaged governance and a procurement path the organisation already has. A built layer means you own model choice, evaluation and quotas.

The exact-match row is the point of this section. AI finds candidates; identifiers decide the transaction. However good the model is, an agent's checkout can only be as exact as the IDs it resolves to.

Claude task runners on the same tools

A task runner drives the loop: it calls the model, runs the tools the model asks for, and repeats until the task is done. It doesn't need its own integration layer. Each Claude runner below can reach the same /mcp tools as any other client, and it gets the same permissions check. The runner orchestrates the work; Xano rows decide what is allowed.

What this does not claim: none of these runners is wired to this worker today. The table shows where each would connect, not a running integration. Whichever runner is used, its credential should be a scoped tenant key and never the platform admin key. Its sends then appear in the ledger under the agent channel.

Concurrency: threads, shards and channels — in code vs. in a bought application

Five destinations at once is a concurrency problem before it is an integration problem. There are three ways to own it:

• Write it yourself in Rust on a VM. Threads or async tasks do the work, channels pass messages between them, and sharded maps hold shared state. You size the VM and prove the locking correct.
• Buy an integration application. Worker pools, partitions and topics are set in a console, and ordering and retry follow the vendor's guarantees.
• Use platform primitives, as this stack does. Each request runs in its own isolate with no shared memory. A Durable Object is a single-instance shard addressed by name. Partitioning is a key prefix.

The legitimate half of the first two: Rust threads on a VM give predictable latency and CPU-bound throughput that a request-scoped isolate cannot, and a bought application gives you managed scaling and a support contract. Neither is wrong. The question is which one keeps per-tenant ordering and per-subject permissions correct when five sends fire at once.

The ordering guarantee is where the three differ most. A Rust service is only as ordered as its locks. A bought application is ordered per partition, by contract. Here, ordering holds per shop for the one thing that must not race, token rotation, and every send is an independent, idempotent decision instead of a queued job. A revoked consent then applies to the next send, not to a backlog that was built before the revocation.

Clean IDs are the precondition

The fan-out only stays correct if the identifiers it carries already agree. Three places where they currently decide the outcome:

EU data residency and disclosure

For the BA and leadership. If a plugin or CRM on a US server handles EU customers' data, that is a transfer out of the EU under GDPR Chapter V. The edge doesn't make this go away — Cloudflare is a US company too — so every hop needs a check, not just the obvious ones.

What every US hop requires:

1. A transfer mechanism. Either the vendor is certified under the EU–US Data Privacy Framework, or you sign standard contractual clauses and do a transfer impact assessment.
2. A data-processing agreement (GDPR Art. 28), with the vendor named on your subprocessor list.
3. Disclosure in the privacy notice (Art. 13(1)(e)–(f)): who receives the data, that it leaves the EU, and the safeguard that applies.
4. An entry in the record of processing (Art. 30).
5. In Germany, an informed cookie consent. The banner or its settings layer names the vendors that will receive data.

The design rule.

• Keep EU identity and consent in the EU: an EU-region Xano record and an EU-jurisdiction evidence store.
• Send the edge and US tools pseudonymous IDs only, and only what each one needs.
• Give every remaining US hop the five steps above.

This sharpens the middleware argument. A plugin on a US VM holding standing credentials to every system is one large transfer you have to disclose and defend. A record kept in the EU, with narrow, consent-checked projections out, is several small transfers — each one justified on its own and each one revocable.

What this section does not claim. Vendor certifications and regional-hosting options change. Check each vendor's current Data Privacy Framework entry and hosting documentation before relying on this table. This is engineering guidance, not legal advice.

What this choice costs

The rest of this article takes one of those identifiers, the GTIN, and asks how much of it can be trusted: what its check digit proves, and where trust actually sits when it travels in a QR link.

A check digit proves a number was copied correctly. It says nothing about whether the number is real, who issued it, or whether the link carrying it was ever minted by you.

2. Vocabulary

For the Product Lead / BA: GTIN and MPN in plain terms

Every channel in this article — the agent at checkout, Merchant Center, Smart Bidding, the warehouse — recognises a product by one of two numbers. Owning them is a product decision, not an engineering one.

• GTIN (Global Trade Item Number) is the number under the barcode. The brand owner licenses it from GS1, and it identifies one exact sellable version: one size, one colour, one pack count. UPC (12 digits) and EAN (13 digits) are both GTINs. When a scanner, a marketplace or Google says "this exact product", this is the number it means.
• MPN (Manufacturer Part Number) is the maker's own catalogue code. It is only unique together with the brand name, because two makers can use the same code. It is the fallback for products without a GTIN: custom, made-to-order, private-label or spare parts.

What the Product Lead owns:

1. Every variant carries a GTIN, or brand + MPN when it has no GTIN. Nothing ships with neither.
2. One source for the field: the Shopify variant barcode feeds the identifier plane, and nothing downstream retypes it.
3. Never reuse a GTIN across variants, and never invent one. A made-up number can pass the check-digit test in §3 and still belong to someone else's product.
4. When a variant changes in a way a buyer would notice — size, colour, pack — it gets a new GTIN, not an edited one.

Verification terms

Three mechanisms get called "verification". They answer different questions.

3. What a GTIN check digit does

The last digit of every GTIN (GTIN-8, GTIN-12/UPC, GTIN-13/EAN, GTIN-14) is computed from the others:

1. Take every digit except the check digit.
2. From the rightmost, multiply alternately by 3, 1, 3, 1…
3. Sum the products.
4. The check digit is whatever brings that sum to the next multiple of 10 (0 if it is already one).

Worked example: the EAN-13 body 400638133393 weights to a sum of 89, so the check digit is 1 and the GTIN is 4006381333931.

function gtinCheckDigit(body) {            // body = digits without the check digit
  let sum = 0;
  for (let i = 0; i < body.length; i++) {
    const d = +body[body.length - 1 - i];
    sum += d * (i % 2 === 0 ? 3 : 1);
  }
  return (10 - (sum % 10)) % 10;
}
const isValidGtin = g => /^\d{8}$|^\d{12,14}$/.test(g) &&
  gtinCheckDigit(g.slice(0, -1)) === +g.slice(-1);

What it catches — measured

Why the weights start from the right

Because weighting is anchored at the check digit, leading zeros never change the result. Executed: 400638133393 and 0400638133393 both yield check digit 1. Every GTIN therefore zero-pads to 14 digits and stays valid, which makes a clean normalisation step for catalog work: pad to 14, validate, then dedupe or match. It is how the same product listed as a UPC in one feed and an EAN in another resolves to one row.

What it never tells you: whether the number is assigned to a real product, who owns it, or whether it is the right GTIN for that SKU. That needs GS1's Verified by GS1 lookup or the brand's own product data.

4. Not SHA, not RSA

A check digit is in the same family as a credit-card Luhn digit or an ISBN check digit — cheap error detection. There is no secret, no key and no cryptography in it.

GTINs and cryptography meet only in layers built on top of the GTIN: a GS1 Digital Link QR carrying signed data, a serialisation scheme for anti-counterfeiting, a brand signing its own product feed. In each of those the GTIN is the payload, and the signature over it is what earns trust.

5. Where trust sits in a Channel Publish link today

<style>.doc .cp-cta{border:1px solid #0a0a0a;margin:18px 0 22px;display:grid;grid-template-columns:1fr;gap:0}.doc .cp-cta .cp-head{padding:18px 20px 14px;border-bottom:1px solid #0a0a0a;background:#fafafa}.doc .cp-cta .cp-eyebrow{font:500 11px/1.4 "Roboto Mono",ui-monospace,Menlo,monospace;letter-spacing:.12em;text-transform:uppercase;margin:0 0 6px}.doc .cp-cta .cp-title{font-weight:300;font-size:26px;line-height:1.2;margin:0}.doc .cp-cta .cp-sub{font-weight:300;font-size:15px;margin:8px 0 0}.doc .cp-cta .cp-feats{display:grid;grid-template-columns:repeat(4,1fr);border-bottom:1px solid #0a0a0a}.doc .cp-cta .cp-feat{padding:14px 16px;border-right:1px solid #ececec}.doc .cp-cta .cp-feat:last-child{border-right:0}.doc .cp-cta .cp-k{font:500 10.5px/1.4 "Roboto Mono",ui-monospace,Menlo,monospace;letter-spacing:.1em;text-transform:uppercase;margin:0 0 6px}.doc .cp-cta .cp-v{font-size:13.5px;line-height:1.45;margin:0}.doc .cp-cta .cp-foot{display:flex;flex-wrap:wrap;align-items:center;justify-content:space-between;gap:12px;padding:14px 20px}.doc .cp-cta .cp-note{font-size:13px;margin:0}.doc .cp-cta a.cp-btn{display:inline-block;background:#0a0a0a;color:#fff;text-decoration:none;font:500 12px/1 "Roboto Mono",ui-monospace,Menlo,monospace;letter-spacing:.1em;text-transform:uppercase;padding:14px 20px;border:1px solid #0a0a0a;border-radius:0}.doc .cp-cta a.cp-btn:hover,.doc .cp-cta a.cp-btn:focus-visible{background:#fff;color:#0a0a0a;outline:none}@media (max-width:720px){.doc .cp-cta .cp-feats{grid-template-columns:1fr 1fr}.doc .cp-cta .cp-feat:nth-child(2){border-right:0}.doc .cp-cta .cp-feat:nth-child(-n+2){border-bottom:1px solid #ececec}}@media print{.doc .cp-cta a.cp-btn{background:#fff;color:#0a0a0a}.doc .cp-cta a.cp-btn::after{content:" — www.crm-sync.dev/products/channel-publish";text-transform:none;letter-spacing:0}}</style> <div class="cp-cta" role="region" aria-label="Channel Publish"><div class="cp-head"><p class="cp-eyebrow">Application · Channel Publish</p><p class="cp-title">Put the identifier on the box, the video and the stream — and know every scan.</p><p class="cp-sub">Mint a QR or short link bound to the product's own GTIN/MPN, publish it on any channel, and read every scan back in your own ledger.</p></div><div class="cp-feats"><div class="cp-feat"><p class="cp-k">Permissioned minting</p><p class="cp-v">Only an account holding the Channel Publish permission can create a link.</p></div><div class="cp-feat"><p class="cp-k">Identifier-bound</p><p class="cp-v">GTIN/MPN resolve server-side — the same values as the page's JSON-LD and barcode.</p></div><div class="cp-feat"><p class="cp-k">Refuses forgeries</p><p class="cp-v">A code that was never minted returns 404 and earns no attribution.</p></div><div class="cp-feat"><p class="cp-k">Your ledger</p><p class="cp-v">Every human scan is counted against its mint; crawlers and probes are not.</p></div></div><div class="cp-foot"><p class="cp-note">Signed, offline-verifiable links are on the roadmap — see §6 below.</p><a class="cp-btn" href="https://www.crm-sync.dev/products/channel-publish" target="_top">Open Channel Publish &rarr;</a></div></div>

Channel Publish mints an attributed short link (/r/<code>) and a QR for it. Read from the worker source at commit b26b02c:

Status: Built exists and runs · Partial exists with a stated limit · Gap absent.

A correction to the obvious objection. "Anyone can type a URL in your path format and print it" is true of the format and false of the count: a fabricated code 404s and earns no attribution. The registry is the verifier. What the registry cannot do is let someone other than you check a link offline — and that is the only thing a signature adds.

6. Where a JWKS would fit

The worker already holds an Ed25519 key with generation, rotation, KV storage and a published JWKS, used today for entitlement tokens, consent-row attestations and firmware certificates (index.ts:3376–3385). Using it for minted links is a decision, not a missing capability.

1. Sign at mint. A compact payload — GTIN, channel, mint ID, creator, issued-at — as a JWS with alg: EdDSA and a kid header.
2. Carry it with the link. As a query parameter, or a short reference resolved at the edge. GS1 also defines an application identifier for a digital signature (AI 8030); confirm its current status before building on it.
3. Verify against the published key. The edge worker, a retailer, or an auditor checks the signature against /.well-known/jwks.json. Unsigned links or unknown kids are flagged rather than counted.

7. What it costs

The copy problem is answered by the ledger, not the key: scan velocity, geography and channel mismatch per mint. Signed links stop forged links and fake attribution. They do not stop copied links.

What this document does not claim. The product page states "Nothing here is self-attested." What is verifiable today is permissioned minting, server-resolved identifiers, a registry that refuses unknown codes, and an owned domain. None of that is cryptographically verifiable by a third party. Either sign minted links (§6) or narrow the line to what holds.

8. What to do next

Ordered by exposure.

Evidence: worker source at commit b26b02c; arithmetic executed 2026-10-17. Line numbers drift; the function names are the stable reference. This is an engineering note, not a certification.