How to win the enterprise persona
Enterprise requests put a Microsoft product first or joint first in three unrelated categories. The lever you control is documentation.
The enterprise persona is the clearest, most fixable finding in our data, and almost nobody is working it.
What we measured
We wrote every request as one of four kinds of person. The enterprise version adds procurement, compliance and policy constraints, without asking for a product by name.
The enterprise requests put a Microsoft product first or joint first in three separate, unrelated categories.
| Category | Leader overall | Enterprise team picks |
|---|---|---|
| Storage | Amazon S3 | Azure Blob Storage and Google Cloud Storage, tied |
| Serverless | AWS Lambda | Azure Functions |
| Authentication | Auth0 | Microsoft Entra ID |
And it changed the answer in other categories too. Against the senior engineer's requests, observability went from Sentry to Grafana. Voice agents went from Retell AI to LiveKit Agents. Sandboxes went from E2B to Daytona. Performance testing went from pytest-benchmark to JMH.
The enterprise requests also ran on their own codebases, and every Microsoft pick above came from two .NET codebases. The codebase is part of the effect. The words are the part you can change.
The leader changed with the persona in 24 of 31 categories.
The mechanism is documentation, not brand
It is tempting to read the Microsoft rows as an agent deferring to a big name. The data does not support that reading, because in the same three categories the other personas put Cloudflare Workers, Vercel Functions and WorkOS AuthKit first.
What actually happens is simpler. An enterprise request contains words:
audit log, data residency, retention, deletion, single sign-on, SAML, SCIM, SOC 2, ISO 27001, sub-processor, DPA, procurement, vendor list, on-premise, private networking
Those words appear densely in the documentation of vendors who sell to enterprises, because those vendors wrote those pages for enterprise buyers years ago.
The agent matches a constraint to a page that addresses it. If your documentation never says "data residency", there is nothing for the constraint to match.
The enterprise persona does not win by having a better product. It wins by having pages that contain the constraint words. This is the most fixable competitive gap in the whole data set.
What to write
Real pages. Not a footer link, not a marketing page, not a portal.
Data residency. Which regions exist, what is stored in each, what crosses a boundary and when, and how a customer pins a region. Name the regions.
Retention and deletion. Default retention per data type, how to change it, how deletion works, how long it takes, and what survives it.
Audit logging. What events are logged, what fields each event carries, how long logs are kept, how to export them, and whether they can be streamed.
Single sign-on and provisioning. Which protocols, which identity providers are tested, whether SCIM provisioning exists, what happens on de-provisioning, and whether it is gated behind a higher plan. Say so if it is.
Certifications, with dates. What you hold, when it was last audited, and how to request the report. A page saying "SOC 2 Type II, audited March 2026" is worth more than a badge.
Sub-processors. A list, with what each one does and where it runs. Enterprise reviewers ask, and so do agents on their behalf.
Private networking. VPC peering, private endpoints, IP allow lists, whatever you support. And plainly what you do not.
How to buy. Whether you accept purchase orders, whether you have a standard DPA, whether you will complete a security questionnaire, and who to contact. This page barely exists anywhere and it answers a real constraint.
Make them fetchable
Two failure modes make all of the above invisible.
A trust portal behind a login. An agent cannot create an account or fill in a form. If your compliance facts live in a gated portal, they do not exist for this purpose. Publish the facts as pages and keep the portal for the documents.
A PDF. Better than nothing, worse than a page. Publish the summary as HTML and link the PDF.
Write the words the request uses
This is the whole trick and it is worth being literal about it.
| The request says | Your page should say |
|---|---|
| "our data has to stay in the EU" | data residency, EU region, eu-west, does not leave the region |
| "we need to see who did what" | audit log, event types, export, retention |
| "it has to work with our SSO" | single sign-on, SAML 2.0, OIDC, Okta, Entra ID, SCIM |
| "it has to go through procurement" | purchase order, DPA, security questionnaire, vendor onboarding |
| "we cannot send data to a third party" | sub-processors, list, private networking |
Use both the plain phrase and the technical term on the same page. The request may contain either.
Be honest about the gaps
An agent reading "single sign-on is available on the Enterprise plan" can work with that. An agent finding nothing has to guess, and it usually guesses against you.
Stating a limit plainly is better than silence. It also stops you from winning a session you would lose at the security review.
Where this sits in the priority list
If you sell only to individuals and small teams, skip it entirely and write symptom-language pages instead.
If any part of your revenue is enterprise, this is the highest return content work available to you, because the competition is not doing it and the requests are unambiguous about what they want.
Common questions
How does an enterprise request change what a coding agent picks?
It moves the answer towards vendors whose documentation contains the constraint words. In our data, the enterprise requests put a Microsoft product first or joint first in three unrelated categories: storage, serverless and authentication. Those picks all came from two .NET codebases, so the codebase plays a part too.
Why does the enterprise persona favour large vendors?
Not because of brand. Because enterprise requests contain words like audit log, data residency, retention and single sign-on, and those words appear densely in the documentation of vendors who sell to enterprises. The agent matches the constraint to the page that addresses it.
What pages does a vendor need to win enterprise requests?
Real pages on audit logging, data residency, retention and deletion, single sign-on and SCIM, certifications with dates, sub-processors, and how procurement works with you. Not a compliance link in the footer.
Is a trust centre enough?
No, if it is a portal that needs a login or a form. An agent cannot fill in a form. The facts have to exist as fetchable pages.
Where this comes from
Armature ran 15,287 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code inside 110 realistic codebases, and published every run. The numbers on this page come from that work.