Redfearn Group Insights

Agentic AI Is Not a Strategy

2026-07-06T00:00:00Z

Every roadmap I look at this year has an agent in it somewhere. Agents are useful. But "we're going agentic" isn't a strategy. It's a technology choice wearing a strategy's clothes, and most organizations skip the question that actually matters: what happens when the agent is wrong and nobody's watching?

Every model is wrong sometimes. That's priced in. What isn't priced in, most places, is a human in the loop to catch it before it touches a customer, a compliance filing, or a production system. If you don't have a specific, boring, already-built answer for that, you don't have an agentic AI strategy. You have a demo that worked in a meeting where nobody asked hard questions.

Autonomy is a dial

I keep seeing autonomy treated as binary: a human approves every action, or the agent runs free. Neither extreme is where the value is. The value sits at the specific point on the dial where the agent handles what it's reliably good at and hands off the rest, through a handoff mechanism that actually works. Not a Slack message someone might miss.

That dial position moves for every workflow. A support ticket triage agent and one that touches financial records need different settings. Wrap the same governance around both and you'll over-constrain the low-risk one and under-constrain the high-risk one.

Governance is the unlock

I've led AI and LLM research inside a defense contracting environment, where a bad output isn't a bug report, it's a compliance problem with federal implications. The lesson wasn't about the model. It was that governance has to get designed alongside the system, in parallel, from day one. Otherwise it becomes a separate project that never catches up to what engineering already shipped.

If your team has to go beg permission from your AI governance function, you built it wrong. It should be infrastructure the team barely notices, because it was already satisfied by the time anyone asked.

Ship the agent. Ship the answer to "what happens when it's wrong" first.

VR Had One Job: Make People Forget They're Wearing It

2026-07-13T00:00:00Z

I've tried every serious headset since the early Rift kits, and I can tell you exactly where each generation improves: resolution, weight, field of view, passthrough quality. What hasn't meaningfully improved in a decade is the question that actually decides adoption: why put this on today, for this task, instead of just doing the task?

Hardware people keep solving hardware problems. The wall was never hardware.

Comfortable isn't the same as invisible

A headset can be light enough to forget you're wearing it and still fail, because the friction isn't physical. It's contextual. Stop what you're doing, find the device, put it on, wait for it to boot, enter a separate mode of existence. Compare that to the phone already in your hand, or the monitor already in front of you. Zero setup cost.

Until entry cost drops close to zero, VR keeps winning the demo and losing the daily habit. Doubling the pixel density doesn't touch the fact that putting the thing on is a decision, not a reflex.

Where it actually works today

The use cases with real, durable VR adoption share one property: the task needs spatial presence a flat screen genuinely can't provide. Industrial training on equipment too expensive or dangerous to practice on directly. Remote collaboration on physical, three-dimensional designs. Certain therapy and rehab, where the immersion is the mechanism, not the marketing.

General productivity, casual entertainment, social spaces competing with a phone: none of those made the list. They get reinvented every hardware cycle and keep failing to stick, because the friction problem never got addressed. Just decorated with better specs.

If you're building for VR right now, don't ask how to make it more immersive. Ask whether the task needs a headset at all, or whether you're solving a problem a phone already solves at zero setup cost. Most roadmaps haven't asked that honestly. It shows in the retention numbers.

The Compliance Team Is Not Your Enemy

2026-07-20T00:00:00Z

Every engineering org I've walked into has the same joke about compliance: nothing ships until they sign off, so build first and hope. I get where the joke comes from. It's also the most expensive habit in enterprise software, and it's avoidable.

The habit exists because compliance review happens at the end: after the architecture is set, after the data flows are built, after the team is emotionally committed to a design compliance is now supposed to bless or kill. Of course that feels adversarial. You structured it as a final exam instead of a design constraint.

Move the conversation to week one

The fix isn't more compliance meetings. Same number of meetings, moved earlier, framed differently. "Here's what we built, please approve it" becomes "here's the problem we're solving, what does a design that satisfies you look like." That single change turns compliance from a gate into a co-designer. Co-designers don't block things they helped build.

I'm running this play right now: architecting an institutional AI platform where governance requirements, RBAC, data hierarchy, conversation design, get spec'd into the architecture before the build phase starts. Get governance into the foundation while changing it is still cheap. Retrofitting it after launch means every change is a migration.

The tell that you're doing it wrong

If your compliance or legal function only hears about a project when engineering needs a sign-off, you've built an adversarial process by default. Doesn't matter how good the people are on either side. Structure decides the relationship more than personality does.

The org that treats governance as infrastructure ships faster than the org that treats it as a gate. Every time. I've built it both ways. Only one of them scales.

Every Company Is Suddenly an AI Company. Most Aren't.

2026-07-27T00:00:00Z

Open any earnings call transcript this year and count how many times "AI" comes up. Then go look at what actually shipped. The gap between those two numbers is the most reliable signal in tech right now, and almost nobody measures it.

I've spent over a decade building the real thing, so this isn't cynicism. I can tell within about five minutes of a product demo whether I'm looking at an AI-native system or a chatbot bolted onto a decade-old architecture. The tell is never the model.

The tell is never the model

Every vendor has access to roughly the same frontier models. The differentiator was never who licensed GPT or Claude first. It's whether the surrounding system, the data pipeline, the feedback loops, the guardrails, the team's actual workflow, was built to take advantage of what the model can do, or just wrapped around it as a feature.

You can spot the wrapped version fast. The AI feature lives in a sidebar. It doesn't touch the core workflow. Support tickets about it get routed to a separate team that didn't build the rest of the product. Ask what happens when the model is confidently wrong and you get a shrug, because nobody designed for that case. They designed for the demo.

The AI-native version looks different structurally, not just cosmetically. The model's output feeds back into the product's core loop. There's a real answer for confidence thresholds and human review triggers. Someone can tell you the failure rate, because someone is tracking it.

Why the gap keeps growing

Boards want an AI story now. Building the real thing takes longer than building the slide. That mismatch pressures teams to ship the appearance of capability before the capability exists. I don't blame the product teams stuck in that pressure. I blame executives who treat "we have an AI feature" as equivalent to "we rebuilt our systems around what AI enables." Those are wildly different amounts of work, with wildly different risk profiles.

The companies that matter in five years are spending this window on the unglamorous part: data quality, evaluation infrastructure, governance that doesn't collapse the first time legal asks a hard question. That work doesn't show up on a slide. It shows up in whether the system still works when the easy cases run out.

What to actually check

Evaluating a company's AI story, as an investor, a candidate, or a customer? Skip the demo. Ask three questions. What happens when the model is wrong. Who owns that failure mode. How long has the team been measuring it, not talking about it, measuring it.

Most AI stories fall apart on the second question. The ones that don't are worth your attention. Everyone else finds out the hard way: in production, in front of customers, with a board asking why the slide didn't match reality.