Three signals that AI development is shifting gears
You can feel the industry shifting from “better chatbots” to “software that does things.” One signal is the rise of agentic patterns: tools, memory, and multi-step workflows are moving from demos into real product roadmaps, because teams want automation, not just answers. A second signal is discomfort with the current tuning stack—especially RLHF—as companies push for faster iteration, more predictable behavior, and training methods that scale without endless human preference labeling. The third is hardware and form-factor pressure: on-device inference and AI-first devices are being treated as product advantages, even though they add constraints like battery, thermals, and higher upfront build cost.
AI agents: when chat turns into software that acts
Consider the difference between asking a model for “the best flight options” and having it actually search, compare, book, and file the receipt where your team expects it. That shift—from language output to taking actions through tools and APIs—is what people mean by AI agents. The chat window is just the interface; the real product is a workflow that can read context, call services, update records, and keep going across multiple steps.
In practice, agents look less like a single prompt and more like a small piece of software: a planner that breaks work into tasks, a runner that executes them, and some form of memory so it doesn’t restart from scratch every time. The appeal is obvious for repetitive knowledge work, but it also changes how you evaluate AI: you care less about eloquent answers and more about whether the system completes the job safely, consistently, and with a clear trail of what it did.
The hard parts of agents: reliability, cost, and control
The first time an agent makes a small mistake, it feels like a normal model error. The tenth time it silently updates the wrong CRM record, books the wrong meeting, or emails the wrong person, it becomes an operational risk. Reliability is harder for agents because each tool call compounds uncertainty: a slightly off interpretation at step one turns into a confident but incorrect action at step five. Teams end up adding guardrails—schema checks, “dry run” modes, approval steps, and audit logs—which makes the system safer but also slower and more complex to build.
Agents spend tokens planning, re-reading context, retrying failed calls, and verifying results, and they often need more expensive models to reduce errors. Control is the other constraint: you need clear permissions, boundaries on what data can be accessed, and a way to explain “why it did that” when something goes wrong, especially in regulated or customer-facing workflows.
Why RLHF is being questioned in the first place
When a model is only answering questions, RLHF can feel like a clean finishing step: collect human preferences, tune for “helpful and harmless,” ship. Agents make the trade-offs harder to ignore. You don’t just want outputs that read well; you want behavior that is stable across long workflows, consistent with policies, and predictable under pressure. RLHF can improve tone and reduce obvious failure modes, but it can also push models toward safer-sounding guesses, inconsistency across edge cases, and “preference over truth” when the reward signal is fuzzy.
It’s also a throughput problem. Preference data is expensive, slow to refresh, and hard to target to the exact failures you’re seeing in production. When product teams want weekly iteration on tool use, formatting, and refusal boundaries, a human-label-heavy loop can become the bottleneck—especially as models, tools, and policies keep changing.
RLHF alternatives: what changes for quality and iteration speed
A familiar pattern in product teams is realizing the “bad behavior” you care about isn’t general politeness—it’s a specific workflow failure: the model picked the wrong tool, missed a constraint, or refused at the wrong time. That’s why you’re seeing alternatives that look less like broad preference tuning and more like targeted training and testing loops: supervised fine-tuning on curated traces, synthetic data that stresses tool use, and evaluation-driven iteration where failing cases automatically become new training examples.
Quality shifts from sounding aligned to behaving reliably. You can train for structured outputs, correct API usage, and policy compliance in concrete scenarios, then measure it with repeatable suites instead of re-litigating preferences. Iteration can speed up because you can generate and filter data quickly, but the constraint is real: synthetic data can amplify blind spots, and building good evals is work. Teams end up paying less in labeling and more in engineering, monitoring, and red-teaming.
AI devices: why moving models to the edge changes everything
Watch what happens when the AI feature still works in a subway tunnel, in a hospital wing with spotty Wi‑Fi, or on a factory floor where data can’t leave the premises. Moving inference onto the device changes the user experience from “ask the cloud” to “use a tool that’s just there,” with lower latency, fewer network failures, and a different privacy posture because more context can stay local. It also shifts what’s feasible: always-on listening, quick personalization, and tighter integrations with sensors, files, and OS-level permissions start to matter more than perfect general knowledge.
The trade is that edge AI is constrained by battery, thermals, memory, and chip availability, and the cost moves around rather than disappearing. You pay in model compression, careful scheduling, and more complicated debugging across hardware variants. Many products will land in a hybrid mode: small local models for responsiveness and sensitive context, with cloud models reserved for heavier reasoning and long-running tasks.
Where the trends meet: agentic apps on personal hardware
A familiar moment is when a “smart” assistant stops feeling like a website and starts feeling like a teammate sitting on your laptop: it watches for the documents you’re working in, drafts the follow-up, updates the ticket, and nudges you when a deadline is about to slip. That’s what happens when agentic workflows meet personal hardware. Local inference makes the agent faster and more dependable in the messy parts of real work—spotty connectivity, sensitive files, and constant context switching—because it can keep more state nearby and act without round-tripping to the cloud.
It also changes the control surface. Instead of one big model deciding everything, you can split responsibilities: a small on-device model handles intent, routing, and privacy-sensitive context, while a cloud model is called only for heavier reasoning. The practical constraint is that this only works if you invest in permissions, audit trails, and careful model updates; otherwise you get a fast agent that’s confidently wrong, just closer to your data.
How to place bets in the next 12–24 months
The practical bet is not “agents” in general, but narrow, high-frequency workflows where errors are easy to detect and undo: meeting follow-ups, invoice intake, ticket triage, contract redlines. Look for products that ship with evals, audit logs, and permissioning as core features, not add-ons, because that’s where reliability and control actually come from.
On the training side, favor teams that can turn production failures into new tests and targeted data quickly; iteration speed will beat one-time alignment wins. On the hardware side, assume hybrid: local models for responsiveness and sensitive context, cloud for heavy lifting. Budget for engineering and monitoring costs that replace “just call the API.”
