Apollo’s AI Payoff Warning: Where Your Handoffs Still Cost

By Lazar Milicevic · Published October 27, 2026 · 8 min read

Your AI assistant writes a perfect reply to a quote request. Then you still check the price, copy the contact into your CRM, attach the right document, and remember to follow up. The drafting got faster. The job did not get finished. Apollo's latest note gives that gap a macro-economic headline, and it deserves a careful reading before you decide what to automate.

What Apollo actually claimed (and what it didn't)

Apollo's chief economist Torsten Slok published "No Signs of AI Payoff Outside the Tech Sector" in the firm's Daily Spark series on October 24, 2026. The claim is about large public companies: revenue per worker and profit margins are rising for the Mag 7 but flat for the S&P 493, which is the S&P 500 minus Alphabet, Amazon, Apple, Meta, Microsoft, Nvidia and Tesla. He also reports no sign of AI lifting productivity growth, using the San Francisco Fed's utilization-adjusted total factor productivity series.

Two limits matter before you quote this to anyone:

• It is not about small businesses. The note covers large S&P 500 companies. It says nothing direct about a five-person agency or a solo consultant.
• It shows correlation in time, not cause. Independent analysis points out that flat S&P 493 lines don't prove AI has no effect at company level. The note's claim that mainstream firms are "pulling back" on token spending also isn't backed by a specific data series in the note itself.

The most useful detail for builders is about concentration. According to Ramp data cited in the note (as reported by PPC Land), the top 10% of firms account for 99.5% of model-serving and inference spend, and 95.6% of direct payments to OpenAI and Anthropic. Slok's reading is that AI spending is concentrated in a small part of the economy, so the macro effect stays limited. He also argues that business intelligence is mostly judgment (accountability, trust, unwritten rules), which AI doesn't have.

Read that as: the economy-wide question and your-business question are separate. A broad headline can't tell you whether your quote workflow got cheaper. A working quote workflow can't tell you whether the S&P 493 is more profitable. For a founder deciding where to spend $50 or $500 a month, only the second question has an answer you can measure.

Adoption is real; completion is the open question

The Census Bureau's Business Trends and Outlook Survey (BTOS) is the best official source for how many US firms use AI. According to the Federal Reserve's April 3, 2026 FEDS Note, about 18 percent of firms had adopted AI as of year-end 2025. The Census data for November 2025 to January 2026 shows 18% of firms using AI in a business function (32% employment-weighted), and among adopters, 57% use it in three or fewer business functions. Sales and Marketing is the most common function, at 52%.

One caveat from the Fed note: in November 2025 Census broadened the question from AI use in "producing goods or services" to use "in any of its business functions." Figures before and after that date aren't directly comparable.

Here's what the numbers suggest, with the inference labeled as mine: most adopters have AI in a few places, and the most common place is the front of the pipeline, where text gets drafted. That is exactly where the handoff problem lives. A drafted email is an output. A checked CRM record, an attached quote, and a follow-up on the calendar are an outcome.

MIT's Project NANDA report ("The GenAI Divide," July 2025) found 95% of enterprise GenAI pilots delivered no measurable P&L impact. Treat that number carefully. Sources disagree on method details, and it measures "no measurable P&L impact," not outright failure. A secondary summary of the report says the clearest returns showed up in back-office work, while sales and marketing pilots absorbed an estimated 50-70% of budgets. That pattern fits what I see building for small teams: the money is often spent where AI looks impressive and earned where work is boring and repetitive.

Trace one email to a finished job

Let's make this concrete. A customer emails asking for a quote. Here is the finish line I'd write down before building anything:

The request becomes a checked CRM record and a prepared quote. Anything missing or unusual is assigned to a person with a note on what's missing.

Notice what's not in that sentence: "AI writes a nice reply." The reply is a side effect. The deliverable is the record and the document.

Here's how the pieces divide up. The LLM does the part it's good at, extracting structure from messy text. Everything after that is ordinary code with rules you control:

from dataclasses import dataclass

@dataclass
class QuoteRequest:
    contact_email: str
    service: str | None
    quantity: int | None
    notes: str

def extract_request(email_body: str, sender: str) -> QuoteRequest:
    # LLM call: return strict JSON matching QuoteRequest.
    # The model extracts; it does NOT price or promise anything.
    ...

APPROVED_PRICES = {  # your list, maintained by you, not the model
    "logo_design": 400,
    "website_audit": 250,
}

def process(req: QuoteRequest, crm, docs):
    # 1. Validation: required fields, duplicates
    missing = [f for f in ("service", "quantity") if getattr(req, f) is None]
    if missing:
        return crm.sessions_spawn(
            owner="human",
            reason=f"Missing: {', '.join(missing)}",
            contact=req.contact_email,
        )

    if req.service not in APPROVED_PRICES:
        return crm.sessions_spawn(owner="human", reason="Service not in price list")

    existing = crm.find_contact(req.contact_email)  # duplicate check
    contact = existing or crm.create_contact(req.contact_email)

    # 2. Price comes from your list, never from the model
    total = APPROVED_PRICES[req.service] * req.quantity

    # 3. Prepare, don't send
    draft = docs.render_quote(contact, req.service, req.quantity, total)
    crm.attach(contact, draft, status="quote_prepared_pending_review")

Three design choices in that sketch are doing the real work:

• The model extracts; your price list prices. The system never invents a discount or states a number that isn't in APPROVED_PRICES.
• Validation gates the happy path. Required fields and duplicate checks decide whether a record proceeds. Incomplete requests become a human task with a reason attached, not a guess.
• Prepared, not sent. The workflow creates the record and the document. Sending a binding offer stays a human decision until you've seen enough runs to trust it. A manual entry mistake can become a billing dispute or an audit problem, so the approval step earns its keep.

This also lines up with Anthropic's "Building effective agents" guidance: find the simplest solution possible and add complexity only when needed. Workflows give you predictability for well-defined tasks. Agents buy flexibility at the price of higher cost and the potential for compounding errors, which is why Anthropic recommends extensive sandboxed testing with guardrails. A quote request is a well-defined task. A fixed workflow with one LLM extraction step is usually enough.

Anthropic's customer-support example is also a good model for what to measure: tools pull customer data, actions like refunds or ticket updates are handled programmatically, and success is measured through user-defined resolutions. Resolutions, not drafts.

Replay ten, then count honestly

You don't need a pilot program to find out whether a handoff is worth automating. You need a spreadsheet and ten past examples.

1. Write the finish line for one recurring request, in one sentence, like the one above.
2. Pull ten real past cases. Include routine ones and awkward ones: missing details, an existing customer, an attachment that contradicts the email body.
3. Replay them through the proposed workflow (a test inbox and a sandbox CRM are enough).
4. Record three things per case: minutes of human work today, whether the final record is correct, and how much cleanup was needed.

Ten is a starting batch, not proof of reliability. If a failure shows up in two of ten, you've learned something cheap. If all ten pass, run another batch with nastier inputs before you trust it.

Then do the math, and count the checking time too. If the task is only faster because you stopped verifying important details, you haven't demonstrated a saving. Here's the shape of the calculation, with deliberately round example numbers (illustrative, not results):

Example only:
  Manual handling:            12 min per request
  With workflow + review:      4 min per request
  Minutes saved per request:   8
  Weekly volume:              25 requests
  Weekly time recovered:     200 min (about 3.3 hours)

Subtract: software cost, time maintaining the workflow,
          time spent on exceptions the workflow bounces to you.

If the net is still positive after those subtractions, you have a case. Also name the benefit accurately. Recovered time is not a payroll saving unless spending actually falls. It might instead mean faster replies or more capacity for client work. Those are valuable, but call them what they are.

Pick the first handoff by cost of delay and cost of error

Not every handoff deserves automation first. Use two questions to rank them:

• How often does it happen, and how long does it take by hand? High frequency and a clear finish line win.
• What does a mistake cost? A wrong tag on an internal note is cheap. A wrong amount on an invoice is not.

That ranking tends to put these near the top for small teams: logging inbound requests into a CRM, preparing (not sending) quotes from an approved price list, and creating follow-up tasks. It tends to put fully autonomous outbound messages or anything touching payments near the bottom until the validation layer has a track record. This also matches the MIT-summary pattern above: back-office handoffs are where measurable returns showed up.

One more point from the Apollo note worth keeping: Slok argues mainstream corporate America doesn't need the latest model and is unwilling to pay for it. For handoff work, I agree in practice. Extraction into a fixed schema rarely needs a frontier model. It needs a clean schema, validation, and logging. Spend your effort there, not on model shopping.

Where bizflowai.io fits in

I'm a senior engineer who builds practical AI automation for solopreneurs and small teams, and bizflowai.io is where that work lives. The pattern I follow for handoff systems is always the same: define the finish line, keep prices and rules in your data rather than in a prompt, log every run, and measure completed jobs against the minutes of human work they replace.

My take on Apollo's headline: it should raise the standard of evidence for your own AI spending, not scare you off it. Buying AI access is easy to confuse with improving operations. The expensive part often sits between tools, where someone copies, checks, and chases. When you can show the completed job, the exceptions, and the cost to keep it running, you have something concrete to build on. Until then, you have a nicer-looking draft.

Want more like this?

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn: Lazar Milićević, senior engineer.

Visit bizflowai.io for services, case studies, and AI consulting.