Machine-First Architecture rests on four pillars: Identity (machines can resolve who you are), Structure (machines can parse what you publish), Content (machines can extract the facts that matter), and Interaction (machines can complete actions on the user's behalf). Every site needs all four.
But in any given industry, one pillar is where the gap is widest — the place where the conventional pattern most visibly fails the machine reader. The five verticals below each name the pillar where their dominant gap sits, show the conventional pattern, show what a machine-first version of that pillar looks like in practice, and tie to a real data point. The framework is constant. Which pillar lights up depends on what you build.
E-commerce
Marketing copy describes the jacket. It does not let a machine compare the jacket.
The acute gap in e-commerce is structural. The technical specs that matter to a buyer's agent — temperature rating, waterproofing, materials, fit — sit in marketing prose or PDF spec sheets, not in the page's data model. Schema.org has covered this case for years. Most product pages still do not use it.
Conventional product page
A marketing paragraph leads: "Crafted in the Italian Alps, built to handle anything winter throws at you." The technical specs sit below in a free-text "Details" tab. The temperature rating exists in the supplier's PDF, somewhere. None of it is captured as a queryable field, and none of it answers the question a shopper actually asks.
Machine-first product page
The product is modelled as data first. Every spec a buyer might filter on is captured as a structured attribute, exposed to the page as Schema.org `Product` with `additionalProperty`, and rendered into the human view as a readable spec table. The marketing paragraph still exists. It just is not where the queryable information lives.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Alpine Hardshell Jacket",
"offers": {
"@type": "Offer",
"price": "549.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
},
"additionalProperty": [
{ "@type": "PropertyValue", "name": "Waterproof rating",
"value": 28000, "unitCode": "MMT" },
{ "@type": "PropertyValue", "name": "Breathability",
"value": 25000, "unitText": "g/m²/24h" },
{ "@type": "PropertyValue", "name": "Temperature rating (low)",
"value": -10, "unitCode": "CEL" },
{ "@type": "PropertyValue", "name": "Material",
"value": "3-layer Gore-Tex Pro" }
]
}Schema.org `Product` with `additionalProperty`. UN/CEFACT codes (`MMT` for millimetres, `CEL` for degrees Celsius) make the units machine-comparable.
B2B SaaS
"Contact Sales" is a content decision before it is a markup problem.
The acute gap in B2B SaaS is not markup. It is disclosure. Pricing, security posture, SLA terms, and integration coverage either exist on the page in machine-extractable form, or they do not. No JSON-LD vocabulary fixes a page that has chosen not to publish the facts in the first place.
Conventional pricing page
Three tiers labelled Starter, Growth, and Enterprise. Starter and Growth list monthly prices. Enterprise says "Contact Sales." Half the feature matrix sits behind a gated demo. SOC 2 certification is mentioned in a blog post from 2024. A buyer's agent that lands on this page has nothing to compare.
Machine-first pricing page
Pricing for every tier (including Enterprise — at minimum a starting figure), the complete feature matrix, integration list, SLA terms, security certifications, and supported regions all published on the page as structured content. The architectural move is the decision to disclose. Schema.org `SoftwareApplication` with `Offer` makes that disclosure machine-readable.
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Acme Analytics",
"applicationCategory": "BusinessApplication",
"offers": [
{ "@type": "Offer", "name": "Starter",
"price": "0", "priceCurrency": "USD" },
{ "@type": "Offer", "name": "Growth",
"price": "499", "priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"billingDuration": "P1M",
"unitText": "per seat / month"
} },
{ "@type": "Offer", "name": "Enterprise",
"price": "2499", "priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"billingDuration": "P1M",
"unitText": "starting, per seat / month"
} }
],
"featureList": ["Real-time dashboards", "API access",
"SSO/SAML", "SOC 2 Type II", "99.9% uptime SLA"],
"termsOfService": "https://example.com/legal/terms"
}All three tiers carry a price — Enterprise as a starting figure rather than a "Contact Sales" placeholder. The markup is real Schema.org. The architectural move is publishing the numbers in the first place.
Healthcare
The data already exists in FHIR. The web layer just discards it.
Healthcare is the cleanest illustration of the Structure pillar in the wrong direction. The data is already structured at the source — FHIR resources for `Practitioner`, `Schedule`, `Coverage`. The template layer transforms that structure into HTML and throws the rest away. Machine-first means the public web surface speaks the same language as the internal data model.
Conventional provider directory
A hospital site queries an internal FHIR server, transforms `Practitioner` and `Schedule` resources into a paginated HTML directory with photos and bios, and hides the structured payload behind a "Call to Schedule" button. A patient's agent reaches the page and finds prose where structure used to be.
Machine-first provider directory
The same FHIR data round-tripped to the public page. Schema.org `Physician` JSON-LD on every provider page with specialty, hospital affiliation, and available services as machine-readable fields. The FHIR resource itself optionally exposed at a sibling JSON URL for agents that prefer the source format.
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "Dr. Maria Chen",
"medicalSpecialty": "Endocrinology",
"hospitalAffiliation": {
"@type": "Hospital",
"name": "North Kansas City Hospital"
},
"availableService": [
{ "@type": "MedicalProcedure", "name": "Diabetes management" },
{ "@type": "MedicalProcedure", "name": "Thyroid disorders" }
],
"telephone": "+1-816-555-0142",
"url": "https://example.com/providers/maria-chen"
}Schema.org `Physician` is a real medical-vocabulary type. The JSON-LD on the page mirrors the FHIR `Practitioner` already living in the EHR — the bridge that the HTML template currently severs.
Real estate
One property, five URLs, no shared identity. Machines have to guess.
Real estate is where the Identity pillar fails first. A single property exists as separate listings on the MLS, Zillow, Redfin, the brokerage site, and the listing agent's personal site. There is no canonical entity, no shared identifier, no `sameAs` graph linking them. An agent assembling a shortlist deduplicates by best guess. The broker who publishes the property's identity layer keeps the source-of-truth role.
Conventional listing flow
A buyer's agent surfaces five listings that turn out to be the same property under five different identities. Each portal renders the MLS feed slightly differently. Square footage rounds inconsistently. Photos are reordered. The MLS ID appears on three of the five and gets formatted differently on each. The agent presents a shortlist that quietly contains duplicates.
Machine-first listing
The property has a canonical entity record on the listing agent's site — a stable URL, multiple identifiers (MLS, parcel, open property ID) declared explicitly, and `sameAs` links pointing to every external listing. The property exists once for machines, even when it is marketed through five surfaces.
{
"@context": "https://schema.org",
"@type": "RealEstateListing",
"url": "https://broker.example.com/listings/123-elm-st",
"datePosted": "2026-04-01",
"mainEntity": {
"@type": "SingleFamilyResidence",
"name": "123 Elm Street, Austin, TX",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Elm Street",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78704"
},
"numberOfRooms": 3,
"numberOfBathroomsTotal": 2,
"floorSize": {
"@type": "QuantitativeValue",
"value": 1850, "unitCode": "FTK"
},
"identifier": [
{ "@type": "PropertyValue",
"propertyID": "MLS", "value": "ATX-2026-15847" },
{ "@type": "PropertyValue",
"propertyID": "Parcel", "value": "0102030405" }
],
"sameAs": [
"https://www.zillow.com/homedetails/...",
"https://www.redfin.com/TX/Austin/...",
"https://www.realtor.com/realestateandhomes-detail/..."
]
},
"offers": {
"@type": "Offer",
"price": 689000, "priceCurrency": "USD"
}
}`identifier` carries the MLS and parcel IDs as named values. `sameAs` declares every external listing of this property. An agent reading any of the linked URLs can resolve back to the same entity.
Financial services
Reading the rate is solved. Applying on the user's behalf is the gap.
In financial services, the read layer is mostly addressable — published rates, structured product pages, Open Banking surfaces. The architectural frontier is Interaction: an agent acting on the user's behalf needs scoped authorisation, a transactable endpoint, and a structured response describing what the institution just promised. That stack is the entire point of the Interaction pillar.
Conventional rate-and-apply flow
A consumer's agent reads published rate matrices on five bank sites, then stops. Applying requires a multi-step form, checkbox terms acceptance, and a credit pull triggered by a human click. There is no agent-scoped authorisation, no machine-readable application response, no structured artifact for the agent to compare against the other four banks.
Machine-first rate-and-apply flow
The rate page exposes Schema.org `MortgageLoan` (or `LoanOrCredit`) with APR, term, and fees as machine-readable fields. Behind it sits an apply endpoint that accepts an agent-scoped OAuth token bound to a tokenised borrower profile and returns a structured response describing the offer. The agent reads the rate, applies under scoped consent, and compares offers as artifacts of the same shape.
{
"@context": "https://schema.org",
"@type": "MortgageLoan",
"name": "30-year fixed-rate mortgage",
"amount": {
"@type": "MonetaryAmount",
"value": 480000, "currency": "USD"
},
"loanTerm": {
"@type": "QuantitativeValue",
"value": 30, "unitCode": "ANN"
},
"interestRate": 6.125,
"annualPercentageRate": 6.291,
"loanType": "Fixed",
"provider": {
"@type": "BankOrCreditUnion",
"name": "Example Federal Credit Union"
}
}This is the read layer — Schema.org `MortgageLoan` with rate, APR, and term as machine-readable fields. The Interaction layer (agent-scoped OAuth and a transactable apply endpoint that returns a comparable response) is what turns it from "readable" into "actionable."