Production AI trends 2026: what changed in Q4

The plumbing buyers should build on

What changed for buyers this quarter is not a new model. Shared tool connections, cheaper repeated context and discounted batch jobs are now stable enough to design around. These are the production AI trends 2026 projects can rely on.

Almost all of this plumbing was released in 2024, and this page does not claim any of it launched in Q4 2026. The change is that it is now routine infrastructure rather than an experiment, so a project plan can assume it.

Tool connections have settled on MCP

Anthropic open-sourced the Model Context Protocol in November 2024 as a standard way for AI applications to reach external tools and data. OpenAI now documents MCP support in its Agents SDK.

Microsoft documents MCP support in Copilot Studio.

For a buyer, this means an integration written once is less likely to be thrown away when you change model vendor. It does not remove the work of deciding what a tool is allowed to do. That scoping work is the core of our AI integration projects.

A worked example: a ticketing connector exposed as an MCP server might offer "read ticket" and "add comment" but not "close ticket" or "reassign". Switching model vendor later means re-testing prompts, but the connector and its permission list stay as they were. The permission list is the part that took the design effort, so it is the part worth keeping portable.

Repeated context is now cheap if you design for it

Anthropic's prompt caching documentation states that cache reads are billed at 10% of the base input price. Cache writes cost more, so the saving appears only when a long prefix is reused.

Put stable material first (instructions, policy text, reference documents) and the changing user input last.

A prompt built the other way round never hits the cache. That is a design decision, not a setting you can switch on later.

Batch processing discounts work that can wait

Both the OpenAI Batch guide and Anthropic's documentation describe batch interfaces priced at 50% less than synchronous calls. The trade-off is time: results can take up to 24 hours.

That suits overnight document classification, back-office summaries and evaluation runs. It does not suit a customer waiting in a chat window.

A common split is to send the live customer question through the synchronous path and queue everything derived from it (tagging, quality scoring, weekly summaries) for batch. The customer sees no delay, and the derived work is billed at half price.

Measuring cost per task in your own stack

We do not yet have our own quarter-over-quarter cost-per-task series we would stand behind, so every number on this page is a cited public source. You can measure your own stack with one workflow and a spreadsheet.

The measurement you can start today

Pick one workflow and record three things per completed task:

1. Tokens in.
2. Tokens out.
3. Whether a human had to correct the result.

Cost per accepted task is total spend divided by tasks a human accepted without correction, not tasks attempted. A cheap run that gets redone by hand is not cheap, so it should not count as a success.

For example, if 200 tasks cost 40 in total and 160 were accepted without correction, cost per accepted task is 0.25, not the 0.20 you get by dividing by attempts. The gap grows as the correction rate rises.

Fix a task set, run it on a regular schedule, and keep the same set when you change a prompt or model. A number that moves because the tasks changed tells you nothing.

What we will report once we have it

From the next edition we intend to report stack changes with the before and after on the same task set.

Until then, treat any vendor "we cut cost by X%" claim, ours included, as unproven unless it names the task, the volume and the period. A credible claim also says how many runs it covers and who judged a result acceptable.

Pricing and cost-per-task levers

Published price lists change often, so this section lists documented cost levers rather than per-token rates. It is vendor documentation, not Viithiisys pricing, and the trade-off is the part vendors skip.

• Prompt caching
• Documented effect: cache reads at 10% of the base input price (Anthropic docs).
• Trade-off: writes cost more, and you need a stable prefix.
• Batch processing
• Documented effect: 50% lower cost than synchronous calls (OpenAI Batch guide, Anthropic docs).
• Trade-off: results can take up to 24 hours.
• Model tiering
• Documented effect: smaller models are priced lower per token (see the OpenAI and Anthropic price pages).
• Trade-off: you need routing logic and an evaluation set.

An illustration, not a vendor quote: suppose 1,000 requests share a 10,000-token prefix. Uncached, that is 10 million input tokens at full price.

Cached, it is one write plus 999 reads at a tenth of the price, roughly 1 million token-equivalents before the write premium. The saving on the prefix is large, and it vanishes if the prefix changes on every call.

Routing, caching and evaluation sets keep run cost down

A demo that calls the largest model on every request is the usual starting point. It works, and it is also the cost profile that gets the project cancelled at the quarterly review.

The fix is dull: route simple requests to a smaller model, cache the shared prefix, and push anything that can wait to batch. Each of those needs an evaluation set so you know quality did not drop.

This is the problem our Moonship offer is built around: a 30-day, fixed-scope MVP, so the first version is sized for its running cost as well as its demo.

What is still not production-ready

Open-ended multi-step agents are the weakest area. They can complete a task once and fail the same task on the next run, and most teams have no way to see that happen.

Consistency across repeated runs

The tau-bench paper, published in June 2024 by Sierra researchers, tested agents on customer-service tasks with tools and policy rules in two domains, retail and airline.

Its abstract reports that GPT-4o succeeded on fewer than half of the tasks overall, and was inconsistent: pass^8, the chance of passing the same task eight times in a row, was below 25% in retail. Results differ by domain, with retail higher than airline, so read the per-domain tables. Newer models were not covered, so test your own model the same way.

One successful demo says very little. Run each important task many times and report the pass rate across all of them.

Long context is not reliable memory

Researchers showed in "Lost in the Middle" that models use information at the start and end of a long prompt better than information buried in the middle. Newer models have improved, but the safe design assumption has not changed.

Retrieve less and rank it better. A smaller, relevant context beats a large one the model half-reads.

Adoption numbers are noisy

Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027, citing cost, unclear value and weak risk controls. Treat that as a forecast, not a measurement.

Adoption surveys do not all define "production" the same way, and some count pilots alongside live deployments. When you read an AI in production report, check how it defines "production" before using the headline.

What we are watching next quarter

The agentic AI state of play will change fastest in three areas: how well MCP servers are secured, whether evaluation tooling becomes routine, and whether per-task cost stays flat as agents take on longer jobs.

Security of connected tools

Every tool you expose to an agent is something a bad input can try to misuse. Prompt injection, where text inside a document or web page tells the agent to do something else, has no complete fix yet.

Limit each tool to the narrowest permission it needs, and log every call it makes so a bad action can be traced afterwards.

Require a human approval step before any action that:

• sends money
• deletes data
• emails a customer
• changes another user's permissions

Evaluation as a normal part of the pipeline

Teams that ship reliably treat an evaluation set like a test suite: it runs on every prompt change and every model upgrade. Teams that do not have one find out about regressions from customers.

If you are building this now, our MLOps work covers evaluation and monitoring, and the same discipline applies to LLM applications.

Agents attached to real systems

The hard part of an agent is rarely the model. It is the connection to the ERP, CRM or ticketing system, with its odd permissions and slow responses.

That is AI integration work, and it is where agentic AI development projects spend most of their time.

If a workflow connected to one of those systems keeps breaking, our broken workflow assessment is built for it: bring the task and the failures you have seen.

Edition history

This is the first edition, written in November 2026 for Q4, so there are no earlier editions to list. The URL is permanent, and each quarter we add a dated summary here and update the sections above.

How to use this page

• If you are deciding what to build, start with the cost levers and the reliability section.
• If you are deciding whether to build with a partner, our AI development services page describes how scoping works. Scoping happens after a discovery call.
• If you already have a workflow that keeps breaking, the assessment link in the "Agents attached to real systems" section is the place to start. Bring the task you would most like to stop doing by hand.