What Gartner Gets Right (and Misses) About GenAI in 2026

Last month a founder forwarded me a 40-page GenAI strategy deck from a top-tier analyst firm. Solid frameworks, sensible maturity model, the usual quadrants. Then he asked the question that mattered: "Okay, but what do we actually build first, and how much will it cost?" The deck didn't answer that. It couldn't. That gap, between the boardroom playbook and what ships to production on a Tuesday, is what this post is about.

I've spent the last few years building autonomous content systems, RAG pipelines, and serverless AI integrations for founders and SaaS teams. I read the analyst reports too. Some of it is genuinely useful. Some of it will burn six months of runway if you take it literally.

Where the analyst playbook is actually right

Credit where it's due. The big-picture consulting frameworks get several things correct, and I've watched teams suffer for ignoring them.

Use-case portfolios beat one-off pilots. The advice to map GenAI opportunities across a portfolio (quick wins, differentiators, transformational bets) is correct. I've seen too many teams fall in love with one flashy demo and neglect the boring automation that would have paid for the whole program. When I scope work, I insist on at least three candidate use cases scored on value, feasibility, and data readiness before we pick one to build.

Data readiness is the real blocker. Every serious framework hammers this and they're right. In practice, 60 to 70 percent of the effort on a RAG or agent project is data plumbing: ingestion, chunking strategy, metadata, permissions, refresh cadence. If your CRM notes are inconsistent, your agent will be inconsistent. No prompt engineering saves you from that.

Governance is not optional. Model cards, evaluation harnesses, human-in-the-loop checkpoints, red-team testing. Boring, essential, and the thing that separates a demo from a system a CFO will sign off on. Gartner-style guidance here is directionally correct.

Total cost of ownership dwarfs license cost. The analyst decks are right that people underestimate TCO. Where they're wrong is in how they estimate it, which I'll get to.

Where it misses: scoping that survives contact with reality

Most consulting-style scoping documents I've reviewed have the same defect: they scope the project, not the system. They'll define phases, deliverables, and a steering committee. What they don't define is the concrete unit of work that will exist in production on day 90.

Here's what I actually scope, in this order, in the first 30 days:

1. One end-to-end user journey, from trigger to output to feedback loop. Not "customer support automation." Something like: "When a Zendesk ticket tagged billing arrives, an agent drafts a reply using the last 12 months of that customer's invoices and our refund policy, then routes to a human for approval, and logs the outcome for evaluation."
2. The evaluation set. Fifty to two hundred real examples with expected outputs, graded by someone who knows the domain. If you can't produce this, you can't ship. Full stop.
3. The failure modes you will accept and the ones you won't. Hallucinated policy citation? Never. Slightly awkward tone? Fine, humans edit.
4. The kill switch and the fallback. What happens when the model provider has an outage or a price change? What happens when quality drops below the threshold?

Analyst decks tend to skip 2, 3, and 4 entirely. Those are the items that determine whether the project ships.

Agent architecture: what the frameworks get wrong

The 2026 consulting narrative is heavy on "agentic workflows" and "multi-agent orchestration." Some of that is real. Most of the architectures I see proposed in RFPs are over-engineered by a factor of two or three.

Here's my actual heuristic after building a multi-agent SEO and content system that's been running in production for months:

Start with the simplest thing that could possibly work.

I only reach for multi-agent when there's a genuine reason: different context windows, different models for cost reasons, or a hard separation of concerns (a "researcher" that shouldn't see the "publisher's" credentials). Otherwise, one well-designed agent with good tools beats a swarm of chatty specialists.

The failure mode I see repeatedly in consulting-designed architectures is agents talking to agents talking to agents, each adding latency and cost, with no clear owner of the final output quality. In my content system, I have exactly three agents with contracts between them defined as JSON schemas. When something breaks, I know which agent to blame in under a minute.

A quick note on frameworks

LangChain, LangGraph, CrewAI, AutoGen, the newer TypeScript-native options. My honest take: pick one, learn it deeply, and stop shopping. For most production systems I ship, the abstraction I actually need is thinner than what these frameworks provide. I often end up writing a 200-line orchestrator on top of the raw provider SDK because it's easier to debug at 2 AM than a framework I half-understand.

If you're doing genuinely complex graph-based agent flows, LangGraph earns its complexity. For 80 percent of business use cases, you don't need it.

Cost control: the numbers analyst decks won't give you

The consulting frameworks will tell you to "monitor token consumption" and "implement caching." True but useless. Here's what I actually track and what I've learned about real costs.

The real cost drivers in a production LLM system:

1. Context stuffing. Every RAG system I've inherited was retrieving too much. Top-20 chunks when top-5 would work. I've cut costs by 40 to 60 percent on inherited systems just by tuning retrieval and reranking.
2. Retries and loops. An agent that retries three times on a malformed output costs 4x per successful call. Structured outputs (JSON schema enforcement) cut this dramatically.
3. Evaluation runs. People forget that running your eval suite on every prompt change costs money too. On a 200-example eval set with a mid-tier model, one full run can cost more than a day of production traffic if you're not careful.
4. Model choice per task. Not every step needs the flagship model. In my content system, drafting uses a strong model, but classification, extraction, and routing use smaller, cheaper models. This alone typically cuts spend by half.

For a mid-complexity B2B SaaS use case (say, 10,000 agent runs per month with retrieval, 2-3 tool calls each), I usually see monthly inference costs land somewhere between $200 and $2,000 depending on model choice and how disciplined the context management is. The consulting-designed version of the same system often lands 3-5x higher because nobody enforced token budgets at design time.

A simple pattern I use to enforce cost discipline:

# Every agent call has a token budget, hard-enforced
class AgentBudget:
    def __init__(self, max_input_tokens, max_output_tokens, max_tool_calls):
        self.max_input = max_input_tokens
        self.max_output = max_output_tokens
        self.max_tools = max_tool_calls
        self.used_input = 0
        self.used_output = 0
        self.tool_calls = 0

    def check(self):
        if self.used_input > self.max_input:
            raise BudgetExceeded("input")
        if self.tool_calls > self.max_tools:
            raise BudgetExceeded("tools")

Trivial code, huge impact. Every agent I ship has a budget. When it exceeds, it fails loudly and we investigate. This is the kind of engineering discipline that no framework or consulting deck will impose on you. You have to bake it in from day one.

The evaluation gap

Here's the biggest gap between the analyst view and the implementation view: evaluation.

Most consulting proposals I've reviewed treat evaluation as a Phase 3 concern. "Once we've built the MVP, we'll design the evaluation framework." Wrong order. Evaluation is the design.

The way I actually work:

1. Week 1: Collect real examples. Get the domain expert to label expected outputs for 50 of them.
2. Week 2: Build a naive baseline (single prompt, no retrieval, cheap model). Run it against the eval set. Record scores.
3. Week 3: Improve one variable at a time. Retrieval? Better prompt? Bigger model? Measure each against the same eval set.
4. Ongoing: Every prompt change, model swap, or retrieval tweak runs through the eval before it merges.

Without this loop, you're doing vibes-based engineering. You'll ship, it'll seem to work, and six weeks later you'll realize the quality drifted and nobody noticed. I've been called in to fix exactly this scenario more than once.

Analyst frameworks talk about "responsible AI metrics" and "governance dashboards." What you actually need first is a boring CSV of inputs, expected outputs, actual outputs, and a pass/fail column, run on every change. Everything else is downstream of that.

A checklist for evaluating GenAI consulting proposals

If a consultant or agency sends you a GenAI implementation proposal, run it through these questions before you sign:

• [ ] Does it name a specific end-to-end use case, not a capability? "Automate ticket triage for billing issues" not "Deploy AI in customer service."
• [ ] Does it include an evaluation plan with a labeled dataset before development starts? If evaluation is Phase 3, walk away.
• [ ] Does it specify token budgets and cost per transaction as a design constraint? Or just "cloud infrastructure costs TBD"?
• [ ] Does it explain the fallback when the model provider is down, changes pricing, or deprecates a model?
• [ ] Does it justify the agent architecture in terms of concrete requirements, not because "multi-agent is the 2026 pattern"?
• [ ] Does it name the smallest model that could plausibly do the job, and justify going bigger only where needed?
• [ ] Does it include a human-in-the-loop checkpoint for anything customer-facing in the first six months?
• [ ] Does it have an exit criteria for the PoC, meaning: "we ship to production if X, we kill it if Y"?
• [ ] Does the team have code you can look at from a similar production system? Not case studies, actual code review.
• [ ] Is there a plan for data refresh and drift monitoring, or is retrieval a one-shot ingestion?

If a proposal fails more than three of these, it's a strategy document dressed up as an implementation plan. That's fine if strategy is what you're buying. It's expensive if you thought you were getting a working system.

What I'd do

If I were a founder or a head of engineering staring at a Gartner-style GenAI report and wondering what to actually do on Monday:

1. Pick one use case where the value is obvious and the data is decent. Not the coolest one, the most tractable one.
2. Build an evaluation set before you write a line of prompt code. Fifty examples minimum, from a real domain expert.
3. Ship a naive baseline in two weeks. Measure it. This tells you how much room there is to improve.
4. Only add complexity (agents, tools, multi-step) where the eval score demands it. Not because the architecture diagram looks cooler with more boxes.
5. Instrument cost per transaction from day one. Set budgets. Enforce them in code.
6. Design the human-in-the-loop and the kill switch before you design the happy path.

The analyst decks are useful for board conversations and for aligning stakeholders on the shape of the opportunity. They are not implementation plans. The gap between "we should invest in GenAI" and "we shipped a system that saves 40 hours a month and costs $600 in inference" is filled by engineering discipline, not frameworks.

If you're staring at a GenAI proposal and something feels off, or you've built a PoC that won't cross the line into production, I'm happy to take a look. You can reach me at lazar-milicevic.com/#contact, or read more field notes on the blog. The best conversations I have start with a specific problem and a real dataset, not a strategy deck.