# The AI Ship Date Dilemma ## 132 enterprise AI teams on the gap between a working demo and production --- # Introduction At Thread AI, we’re in hundreds of enterprise AI conversations a year. They’re sales, scoping, strategy, and implementation conversations, which means people tell us what they’re exploring, what they’re trying to build, and what’s standing in the way. They’re candid because they came to us with a problem they haven’t solved. Over time, the same question keeps surfacing: What stands between a working demo and something that holds up in production? To answer it, we went back through our own enterprise AI buying conversations from January to August 2026: a corpus that comprised conversations with 132 companies across different industries and stages of AI maturity. While these companies had varied use cases for AI, they fell into three groups: those still scoping early projects and exploring what AI can do, those using AI to run their own operations more efficiently, and those building an AI product for internal teams or external customers. Only 5% of the companies in our corpus have made a dated, external commitment to ship an AI product: a specific date, shared with a customer, board, or publicly, that someone outside the company can hold them to. The other 95% are building against a clock only they can see. This report tracks what's happening inside that 95%—what building looks like when the deadline is internal and no one outside is counting down. Close to half the companies we spoke with weighed building their own production layer, and most of the ones who tried it ended up assembling the layer piece by piece. Reliability concerns surface unprompted in a meaningful share of conversations with teams that are building for live users. Legal and procurement add their own timelines once a team clears its internal hurdles. And the companies that ship anyway, despite never setting an external date, tend to get there through one of a handful of familiar paths. The findings draw on unscripted conversations with people who were actually trying to ship, documented as they happened rather than reconstructed after the fact. A note on this corpus: This report is not a market survey. We are not differentiating between companies that are currently Thread AI customers and companies that are not. All companies surveyed herein were already in conversations with an AI infrastructure vendor, which means the sample skews toward teams already building. That skew is useful. These are the companies closest to the problem, working through it in real time. Every statistic in this report is a share of this corpus, not a claim about the broader market, and the full methodology appears at the end. --- # Chapter 1: The Missing Ship Date ## The distance between internal urgency and an external commitment **What’s a ship date?** A ship date is a committed date for taking a product, feature, or workflow live. It seems every week brings another AI product launch or earnings call crediting nebulous AI for efficiency gains. No matter where you look, there’s always somebody somewhere talking about AI. With all this AI chatter, when we analyzed recent conversations with 132 companies in various industries, we expected to find that most were committing product delivery to some kind of external party such as a board, a customer, or the market. What we found was the exact opposite: Only six of the 132 companies said they had a dated external commitment to ship with AI. That’s 5%. The six companies that made external commitments didn’t get there the same way, and the group is too small to sort into any kind of formal typology. In some cases, a contract or a customer’s own demand fixed the date. In others, a competitor’s launch or an industry moment set the window. In others still, leadership chose to make an internal roadmap promise external before anyone forced the issue. **It means that 95% of companies were working toward a deadline that only existed internally, if it existed at all.** For many of the companies, the absence of a ship date did not mean a lack of urgency. Roughly 42% used deadline language in their buying conversations. They talked about weeks, quarters, and windows constantly, the same way anyone does when a launch feels close. But that language rarely pointed to anything fixed. Since so few companies in the corpus shared external deadlines, the pressure these teams described came from an internal clock that can be reset. A date told to a customer creates a different kind of pressure, the kind that has to be met or explained. *(See the PDF for a visual example.)* > **What’s in a deadline?** It’s important to note our criteria for categorizing deadlines. We counted a date as external only when it was communicated to a customer, a board, or the market with a specific window attached. All other dates, including the expiration of a contract, team, or in-house system, we counted as internal. ## Why it’s hard to commit to a date The gap between internal pressure and external commitment is a function of deciding what’s worth building, what it costs to be wrong, and the work itself. Nearly a fifth (18%) of the companies we spoke to were still deciding what to build, too early for a ship date. For the rest, the work of derisking keeps the date internal. A prototype can look finished long before it’s actually done. The demo can run cleanly in a controlled setting and still be months away from something a company would put its name behind in production. The infrastructure underneath a shippable AI product takes far longer to build than the feature it supports. For enterprise and regulated businesses, that gap is even wider. So the build adjusts. Teams work through tradeoffs: a narrower use case, a manual review step, or even an agent that only handles the easy cases well. Every one of these is a sound engineering decision, often made because the infrastructure these products demand sits well outside what most of these companies are set up to build. What’s less clear is which tradeoffs are fixed and which aren’t. The 126 companies in our corpus without set ship dates were still building, and how they built changed as the work neared production. The next chapter looks at where build strategies start to diverge, and what that divergence says about who’s ready to commit to a date and who is not. --- # Chapter 2: Assembled Versus Built ## How companies approach build vs. buy for AI infrastructure Regardless of industry or use case, the companies in this corpus have foundations for their products or workflows. What they lack often arrives in pieces they need to assemble. Companies initially approach shipping an AI product the way they would approach the trade-offs for shipping any other piece of software: They build it themselves. In our recent analysis of conversations with 132 companies, 65 said they first weighed building the production layer on their own. That’s roughly half of the companies. As everyone building software knows, often no matter how straightforward an internal build begins, eventually complexity catches up. Of the 65 companies that initially weighed building the production layer on their own, 66% (43) ended up with an assembled stack instead, layering multiple vendors, combining bought and built pieces. By the time the 65 companies spoke with us, they still had unresolved components to address. Observability was the most common gap, named by 24 companies, followed by human-in-the-loop approvals (23), audit trails (20), and per-client authorization (14). Since many of these projects are still ongoing, we do not know how every company addressed these gaps. ## What the production layer actually demands Closing those four gaps requires real engineering time, and these components are hard to build. Observability has to see every step the system takes; approvals and audit trails have to sit at every point a decision gets made; per-client auth has to hold at every boundary. Adding them to a system already in motion costs more than building them in from the start. These features also carry a different kind of engineering burden, necessitating answers to questions such as: * What can the agent access? * What did the agent do and why? * Is the agent executing reliably, at scale? The cost most teams underestimated wasn’t building these components. It was keeping them working. A feature ships once; infrastructure is owned indefinitely, and every change to the product is a change that observability, approval flows, and audit trails have to absorb. Companies we spoke to described building their orchestration across multiple platforms before arriving at a hard truth. The problem was not that the solution didn’t work but instead that they couldn’t staff the maintenance. This raises the question the next chapter takes up—whether the results can be trusted by the people who rely on them. Governance and visibility can only tell you what a system did. The harder, more subjective question is the one that real users force: Is the system any good? --- # Chapter 3: Raised But Not Resolved ## The gap between worrying about AI accuracy and measuring it The last chapter looked at how the various companies in our corpus are building. This chapter looks at the extent to which what they build can be trusted, and the extent to which teams are even asking questions about trust. Among the 71 companies who said they were building a product with real users, whether other employees or customers, 42% (30) raised concerns about reliability, accuracy, or output. Notably, these concerns did not emerge in response to a question; they came from teams worried enough to raise the subject on their own. Unprompted anxiety is a narrow thing to count, so we counted it narrowly. Complaints about what models can and can’t do didn’t qualify. Neither did concerns about infrastructure uptime. Worry about regulation we tracked separately. What remained was one specific fear: that product outputs can’t yet be trusted by the people who will depend on them. Although worry was common, methods of checking were not. Of the 71 companies building a product with real users, 33 surfaced an evaluation practice to test how their product performs. Nine of the 71 companies described something formal: a test set with a quantified accuracy target that a launch had to clear. This means a formal practice exists at fewer than 13% of the product-bound corpus. For 27% (19) of the 71 product-bound companies, a regulator, auditor, or named compliance regime is the primary reason they require auditability. For these companies, reliability and accuracy stop being an internal judgment call and become something a third party has to be able to verify. This verification is important, since a regulator or auditor will eventually ask for proof, and “It seemed to work” will never suffice. *(See the PDF for a visual example.)* ## Setting the bar before you need it Companies in this corpus are focused on getting a product out the door, and that focus comes with a tradeoff most are making without naming it: some level of reliability and accuracy risk, accepted quietly, so the launch stays on schedule. Trust is not optional once a product ships. People use an AI product for as long as they believe its answers. For any product that leverages models, perfect accuracy isn’t realistic. What is realistic and necessary is defining what “good” looks like before launch, and having a way to check against it once a product is live, before a regulator or a bad outcome forces the question. That's the difference between a company that can explain what its product did and a company that has to guess. --- # Chapter 4: Pending Review ## How procurement and security review shape time to production Companies build new things all the time, and they all have the right to protect what they’ve built. Sometimes this means guarding IP. Other times it means running security reviews. Still other times it means adhering to a strict compliance policy before letting a new vendor near sensitive systems. Proper risk mitigation is essential, and should be taken seriously. The data bears this out: About 46% (61) of the 132 companies in this corpus said they had a procurement step such as an NDA before talking at all about their products or an intensive security review as a precondition to getting started. This gateway can become a problem when it decides how fast a team can move. ## Potential pitfalls for pacing Procurement, legal review, vendor risk assessment, and security sign-off all run on a pace set years before anyone was trying to ship with AI. A buyer at one large enterprise told us they would warn prospective vendors that approval typically takes two years. That is a particularly long road, considering that the underlying models change every few months and how a competitor’s launch can reset an entire roadmap overnight. Most of the companies in this corpus want to move faster than their own process allows. This tension isn’t new, but the cost of it has changed. A fiscal quarter spent in vendor review is a quarter where nothing ships. That shows up as revenue, customers, and ground ceded to whichever companies moved earlier, a cost many companies have not weighed against what they are building now. The companies that got past this stage still had to build something worth shipping. What that looked like is where this report concludes. --- # Chapter 5: What Shipped Anyway ## Who reached production, and the four paths they took Deadlines exist to facilitate progress. To that point, this report has focused on what can slow or stop that forward motion. In this fifth and final chapter, we turn to what companies in our corpus actually accomplished. For 41 of the 132 companies, we know how far the work went: 32 of them (78%) actually shipped something. Financial services companies account for the largest share of those that shipped, followed by consultancies, agencies, and integrators. Both reflect their size in the corpus, and the fact that regulated industries and firms delivering on behalf of clients need the production layer from the start. Within each industry, though, the picture differs: just 24% of financial services companies had shipped, against 39% of consultancies, agencies, and integrators. Both groups work under external scrutiny, with regulators in one case and clients and their auditors in the other. This raises the stakes when they ship with AI. Consumer packaged goods companies make up about 5% of the corpus but 9% of those that shipped. In terms of company size, large enterprises (10,000+ employees) and enterprises (1,000 - 9,999 employees) made up more than 85% of the shipped group, which is expected given the makeup of the corpus. However, only 22% of large enterprises in the corpus reported having shipped while 34% of enterprises reported the same, suggesting that large enterprises face additional headwinds in shipping with AI. ## Four archetypal companies The companies that shipped fall into one of four general categories: enhancement of a live product, net-new platform product, productized methodology, and internal optimization. Here are dossiers on each. ## 01 · Defend the Moat **Existing product → Agentic capability** **Who this is.** Companies with an existing product people rely on and an established customer base, now trying to add agentic capability. **What's driving them.** Newer entrants are shipping agentic capability and customers have started comparing. Leadership knows the company needs an answer. They also know the enhanced product has to make sense for already paying customers. **What success looks like.** Shipping quickly without rebuilding the product or the infrastructure underneath it, and without putting compliance at risk. **Where it gets harder than expected.** The new capability has to live inside a product customers depend on. Every permission model, every log, every approval path was built for software that does the same thing every time. An agent behaves autonomously and non-deterministically, taking paths nobody chose in advance, and the underlying systems weren't built for that. **Example.** A financial software platform whose customers log in daily to process transactions. The company wants agents handling exception review inside the existing workflow, not in a separate tool. Every action has to be traceable, because the customers using it are audited. ## 02 · Move up the Stack **Existing platform → Net-new agentic product** **Who this is.** Companies with infrastructure, data, or distribution already in place, now building an AI product on top. **What's driving them.** There's demand the current product can't serve. Customers are asking for it, competitors are moving on it, and the company has the data and the relationships to go after it. **What success looks like.** Launching quickly, with engineering time spent on the product logic they know best. **Where it gets harder than expected.** A new product means building multi-tenancy, isolation, approvals, audit, and orchestration from nothing. All of it has to be there on Day One, before a single customer touches it. **Example.** A data platform whose enterprise customers already run analytics on its infrastructure. The company wants to sell them an agentic product that acts on that data rather than just surfacing it. Each customer's data has to stay isolated from the next, and the actions the agent takes have to be reviewable—two capabilities the underlying platform was not built to handle. ## 03 · Productize the Playbook **Firm methodology → Productized agent** **Who this is.** Consultancies, agencies, systems integrators, and services firms whose expertise and people are what clients pay for. Their methodology is refined and repeatable, and they want it available on every engagement, not just the ones they can staff. **What's driving them.** The opportunity to reach clients faster, deliver more in every engagement, and be the firm that's visibly ahead instead of the one catching up. **What success looks like.** Capacity that grows with demand, and a methodology that arrives intact at every engagement. **Where it gets harder than expected.** The methodology lives in decks, playbooks, and the heads of senior people, and encoding it is most of the work. From there it has to adapt to each client, with every client's data kept separate. **Example.** A consultancy whose diligence process is the reason clients hire them. It's a sequence of checks refined across hundreds of deals, run by a handful of senior partners. The firm wants that process available on every engagement, not just the ones those partners can staff. It has to adapt to each client's data, technology stack, and deal type without being rebuilt each time. When a client asks why the tool flagged something, the answer has to hold up in front of their own advisors. ## 04 · Run the Business **Manual process → Agentic workflows** **Who this is.** Enterprises that want agents running alongside their teams, systems, and processes critical to the business. **What's driving them.** The work is growing faster than the team. The aim is more capacity from the people already in place, and time returned for the work that needs judgement. **What success looks like.** Systems that never talked to each other now working together, and the same team handling more work faster, with fewer things falling through. **Where it gets harder than expected.** These processes already have owners, controls, and consequences. An agent working alongside them inherits all of it, which means approvals, traceability, and the ability to explain what happened have to be in place before anything goes live. **Example.** A retailer's merchandising team reconciling supplier data, inventory systems, and pricing tools that were never built to talk to each other. Most of the work is routine until something doesn't match, and those exceptions are where the cost sits. Agents can move the straightforward cases through, but anything unusual still needs a person to look at it. --- # Conclusion The pressure to ship showed up in almost every conversation: a team wanting to move faster, an executive tracking AI in every review, a competitor’s launch that reset the clock. About 42% used deadline language, and only 5% of the companies we spoke with set a dated, external commitment to ship with AI. Most of the rest were pushing against a clock they could stop and start themselves. The same pattern kept appearing: whatever a company set out to build, the work underneath it turned out to be bigger and harder to see than the product itself. It showed up as a production layer assembled piece by piece where a clean build was planned, the outcome for 43 of the 65 companies that first considered building themselves. It showed up as concern about output quality that few teams had a formal way to test: Fewer than half the product-bound companies described any formal evaluation practice, and under 13% had quantified bars a launch had to clear. One of the most common bars showed up as a procurement gate, where 46% of the corpus had a review to clear first—and that one buyer who warned vendors to expect a two-year timeline was not a stand-alone data-point. This may be part of why so few ship dates exist. It's hard to commit to a date when you can't see the bottom of the work. Plenty of companies got there anyway. Of the 41 where we know how far the work went, 32 shipped. These companies here had almost nothing in common. A hotel group building a support workflow, a marketing and ad agency turning years of client engagements into productized agents, and a manufacturer developing an agentic product for its existing customers. Different industries, different starting points, different ideas of what they were even building. The components they were missing were nearly the same. Seeing what the system did, putting a person in the loop where it mattered, proving what happened after the fact, and keeping one customer's data away from another's. These came up across the corpus in two dozen industries. That convergence is important because these companies are not competing on any of it. They are competing on the thing above it—the product, the workflow, the model of their business, and the judgment their customers pay for. None of these companies could see the others. They arrived at the same place anyway. --- # Methodology ## What this is This report is based on an analysis of 400+ separate and individual conversations that Thread AI had with companies about buying and building with enterprise AI. The conversations took place between January 8 and August 31, 2026. The conversations involved 132 identifiable companies. Each conversation was transcribed or documented in accordance with local laws and regulations. ## Who we spoke to Companies in this corpus represented 23 overall industries. Financial services, professional and marketing services firms such as consultancies, agencies, and integrators, and technology comprised 59% of the total. Breaking this data down even further, 51% of the companies in the corpus qualified as large enterprises (10,000+ employees), 29% were enterprises (1,000 - 9,999 employees), 9% were mid-market firms (250 - 999 employees), and the remaining 11% were small- and medium-sized businesses focusing on key vertical technology and industry areas (fewer than 250 employees). Thread AI works predominantly with enterprises, which explains the skew. Companies operating under NDA are included in aggregate statistics but excluded from all narrative material. ## What this isn't This is not a representative survey. Every company in this corpus was already in conversation with an infrastructure vendor, which means the sample skews toward teams that are already building. We treat that skew as the point rather than a limitation, since these are the practitioners closest to the problem. Every statistic in this report is a share of this corpus, and each company is counted once regardless of how many conversations in which the company appears. ## How it was coded Each conversation was coded against a fixed codebook using both a traditional NLP and language-model coding pipeline. Every coded value carries a verbatim supporting quote and a pointer back to its source conversation. A 10% sample of companies was independently recounted by blind coders, producing 6.7% disagreement overall. The five variables responsible for that disagreement had their coding rules tightened and were fully recoded before any statistic in this report was computed. Duplicate recordings of the same meeting were removed, and no statistic in this report is published on a base of fewer than five companies. ## Produced on Lemma The coding for this corpus ran as a workflow on the same infrastructure this report describes.