DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
Stop upgrading your LLM. Start fixing your data.



Subscribe • Previous Issues
Integration Is the New Moat: Moving Beyond the LLM
The AI Agent Conference in New York was one of the better events I’ve attended to get a read on what’s actually happening with enterprise AI. The formal sessions were great, but the hallway conversations was where I got the inside scoop. The consistent message: deploying AI agents is much harder than most organizations expect, and the reasons are rarely the ones they anticipate. What follows is my attempt to distill what I heard into a practical view of why enterprise agents are so hard to deploy.
Reading on a regular basis? Consider becoming a paid supporter 🙏

The first barrier is integration. In one enterprise after another, agents run into older CRMs, finance systems, document stores, and homegrown tools that were never designed for autonomous software. What looks like a wiring problem usually isn’t. A logistics company built a capable agent that fell apart the moment it had to touch their order management system, a decade-old platform never designed to be queried by software making autonomous decisions. The agent wasn’t broken. The process it was dropped into was. The worst failures are often the ones that stay hidden. A financial services firm ran an agent successfully in its test environment for months, only to discover during a quarterly audit that production CRM records had silently stopped updating. No error, no alert, just bad data accumulating for three months. Teams that treat integration as a technical handoff rather than a workflow redesign problem consistently get stuck at the same wall.
The data situation compounds this at every layer. Enterprise knowledge doesn’t live in clean, queryable databases. It lives in Confluence pages nobody maintains, Slack threads from two years ago, and the heads of three people who’ve been at the company long before the current CTO arrived. One study found that more than a quarter of agent deployment failures trace directly to critical knowledge that was never captured anywhere a system could reach. When agents fail on company-specific terminology, like non-standard product codes or internal procurement shorthand, the instinct is to upgrade to a more powerful model. That instinct is almost always wrong. The fix is domain-specific examples and better knowledge capture, not a bigger model. And underneath all of it, security cannot be an afterthought. Agents need governed, scoped access to data, with proper permissions and audit trails built in from the start. Without that foundation, even a well-integrated, well-trained agent is a liability waiting to surface.

Agents Don’t Fix Broken Processes, They Find Them
But even when integration is solid and data is in order, most deployments hit a third wall that almost nobody budgets for: the organization itself. Agents do not arrive as neutral software upgrades. They ask people to change how work is routed, approved, measured, and owned. In a hospital system, that might mean deciding whether an agent can prepare a prior authorization packet before a clinician reviews it. In an industrial manufacturer, it might mean exposing the informal workaround a plant manager has used for years because the official process is too slow. In an insurance operation, it might mean discovering that no one can explain who is accountable when an agent recommends a coverage decision that later gets challenged. These are not edge cases. They are the work.
This is why early agent projects often fail in a way that is politically expensive. A weak first deployment does not just miss a KPI. It convinces managers, operators, and risk teams that the whole category is immature or unsafe. The harder second attempt, the one that would involve process audits, clearer ownership, better evaluations, and serious change management, may never get funded. In practice, deploying agents means changing the organization while the organization is still running. That is slower and messier than a demo, but it is also where the real implementation work begins.

Compounding all of this is a talent problem with no clean solution. Deploying agents at scale requires people who understand process design, LLM behavior, systems integration, and organizational change, all at once. That combination is genuinely rare, and companies that hire for one or two of those skills and assume the rest will follow are setting themselves up for the same failure pattern, just with different symptoms.
Agents Are Implemented, Not Installed
The real implementation work isn’t getting an agent to run correctly in isolation. It’s getting the agent to run correctly inside a live organization, where the work is distributed across roles, the accountability is murky, and the processes were designed around human judgment calls that nobody ever wrote down. What looks like an AI project is usually a process redesign project with an AI component attached. The companies that figure this out early tend to scope their first deployments around a specific, broken workflow rather than a whole function or department. Not “automate the sales team,” but “automate the part of lead qualification that requires pulling the same three fields from two systems and writing the same email 200 times a week.” That narrower target is less exciting to demo but far more likely to survive contact with the organization. Enterprise agents are not installed. They are stood up, governed, monitored, and gradually expanded.

The implementation gap has also created a staffing model that most organizations haven’t fully absorbed yet. The most effective deployments involve a dedicated operational owner for each agent in production, someone who sits at the intersection of the business workflow and the technical system, and who can tell the difference between an agent that’s working and an agent that’s producing plausible-looking output that nobody has actually verified. Some vendors have formalized this with embedded specialists, technical product managers or forward-deployed engineers whose job is to live inside the customer’s workflow until the deployment actually holds. Without that kind of ownership, agents in production become side projects maintained by whoever built the prototype, and the research bears this out: organizations that skip dedicated ownership are dramatically more likely to face failures that require rolling the whole thing back. The talent profile this requires doesn’t map cleanly onto any existing job title, which is part of why so many companies are either building it from scratch or outsourcing it to implementation specialists who’ve learned these lessons on someone else’s dime.
Integration Is the New Moat
The next durable advantage in enterprise agents will not come from picking a cleverer model. It will come from making agents usable inside messy, specific, high-stakes workflows. A legal team does not need a model that can sound like general counsel in the abstract. It needs a system that can find the right contract, apply the company’s negotiation playbook, respect approval thresholds, and leave a clean audit trail. A customer support operation does not gain much by giving every human agent a better copilot. It gains real leverage by redesigning the service so routine cases resolve end to end, with people handling the work that requires judgment, empathy, or escalation. 

A manufacturer running fragmented ERP, procurement, and plant systems will not close the competitive gap by waiting for larger models. It will close the gap by modernizing the connective tissue of the business. The raw intelligence of foundation models is becoming a commodity faster than most people expected. What remains scarce is the integration depth, the governed data access, the workflow redesign, and the operational ownership that make agents actually hold in production.
That gap is also a market. Vendors, integrators, and internal transformation teams that can do the unglamorous work, connecting legacy systems, capturing institutional knowledge, building evaluation frameworks, managing the organizational change, are sitting in front of a real and durable opportunity. The distance between what foundation models can theoretically do and what enterprises can actually deploy is not closing on its own. The companies that treat integration, governance, and workflow redesign as the product rather than the plumbing will be the ones that turn agents from demos into operating leverage.

The Three Pillars Behind DeepSeek’s $51.5B Premium



Source link

Why your AI bills are going up (even as tokens get cheaper) 📉💸



Subscribe • Previous Issues
The End of the AI Experiment: Surviving the CFO’s New ROI Demands
Why This Has Become an Executive Issue
Why is AI spend no longer just an IT budget problem? AI has crossed a threshold where aggregate spend across every department requires capital allocation discipline, not just software procurement review. Every function now has a case for AI investment, and someone has to decide which requests deserve ongoing funding. That decision has landed with the CFO, which means technology leaders who frame AI proposals as feature requests will lose funding to peers who can demonstrate measurable business outcomes.
What do “tokenomics” and “tokenmaxxing” actually mean in practice? Tokenomics is simply the practical economics of AI usage: how prompts, automated workflows, and background agents translate into real spending, and whether that spending is producing value. Tokenmaxxing is the emerging habit of pushing more work through AI because tokens feel cheap, or because high-consumption workflows appear more productive. The instinct can be rational, but it creates a governance problem because organizations need a way to distinguish productive consumption from wasteful consumption, and most have not built that capability yet.

Reading on a regular basis? Consider becoming a paid supporter 🙏

Why are AI bills climbing even though token prices keep falling? Lower unit prices are encouraging more consumption, not less. As tokens get cheaper, teams build more ambitious systems: more automated, more context-heavy, always-on agents running continuously in the background. The marginal cost of any single query feels negligible, so consumption expands to fill whatever budget exists. Organizations focused purely on negotiating lower unit prices while ignoring how their systems are designed will find their total bills climbing regardless.
Why is CFO scrutiny intensifying right now? The broad experimentation phase is ending. Many organizations have deployed AI in some form, but far fewer believe those deployments have produced tangible value. Once that gap becomes visible, finance teams stop treating AI as a learning exercise and start demanding evidence for continued investment. The funding logic shifts from supporting a large portfolio of loosely defined experiments to concentrating resources on fewer workflows with a clear payback case.
What Leaders Should Actually Govern
What is the right unit of control: seats, teams, vendors, or workflows? The most useful unit of governance is the individual application or workflow, not the software seat or department budget. AI costs are generated by usage patterns, not by who holds a license. A single automated workflow can quietly consume more tokens than dozens of human users combined. Budgeting at the workflow level makes it possible to see which use cases are scaling, which are overrunning, and which should be redesigned or shut down.
When do spending caps help, and when do they backfire? Caps help when they prevent undisciplined growth in low-value usage, particularly when nobody can explain where the spending is coming from. They backfire when they suppress the most productive work. If your highest-consuming teams are also your highest-performing ones, a blanket ceiling is a tax on performance dressed up as financial discipline. The right sequence is to instrument outcomes first, then decide where controls belong.

What should leaders actually ask when a vendor proposes outcome-based pricing? Outcome-based pricing sounds appealing because it appears to align vendor incentives with business results. That alignment is not automatic. It depends entirely on how the outcome is defined, how success is verified, and what happens when the system produces something that technically triggers a charge but does not create real value. Leaders should ask who defines what counts as a valid outcome, how disputes are handled, and whether the vendor has any incentive to maximize billable events in ways that diverge from the customer’s actual objective. 
Why do different AI pricing models need different governance approaches? Not all AI spend behaves the same way. Subscription pricing buys predictability but can conceal waste inside a flat fee. Usage-based pricing makes activity visible but creates volatile invoices. Outcome-based pricing sounds more business-friendly, but it can obscure the operational work required to verify whether the billed result was correct, complete, and valuable. The shift toward seats-plus-consumption adds another complication: buyers may renew a familiar per-seat contract while also taking on usage charges, credits, agent actions, or outcome fees that behave very differently. Leaders need governance that matches how value is claimed, how cost is incurred, and how performance can fail. Otherwise, they risk optimizing the old pricing model while their real exposure has already moved somewhere else.
The seat is no longer the product. Increasingly, it is just the wrapper around prepaid consumption.
Visibility: The Prerequisite for Everything Else
What is the single most important governance gap right now? Attribution. Most organizations cannot answer the basic question of which team, workflow, or agent is consuming how many tokens, and what business outcome that consumption supports. Without that visibility, every other governance mechanism, whether caps, chargebacks, or ROI thresholds, operates on incomplete information. Solving attribution is the prerequisite for everything else.
What does good visibility infrastructure actually look like? It means purpose-built dashboards that surface per-workflow and per-agent consumption in near real time, not month-end invoices that arrive with no ability to trace costs back to specific decisions or teams. Salesforce expanded its internal Engineering 360 dashboards to track AI usage at the workflow and team level, showing how companies often need custom visibility tools when standard reporting does not give leaders a clear view of token consumption, agent activity, and adoption patterns. This is an area where early investment in custom observability pays off rather than waiting for the vendor ecosystem to catch up.

How does token consumption become a productivity signal rather than just a cost metric? High token consumption and high-quality output often correlate. Before setting any controls, connect token spend to actual business outcomes: deals closed, issues resolved, code shipped, churn prevented. Once you have that picture, invest more in the high-correlation workflows and scrutinize the rest. Organizations that skip this step and go straight to spending ceilings risk penalizing their most productive teams first.
Practical Governance Mechanisms That Work
What is the most actionable governance step we can take right now? Set per-application token budgets with automated alerting thresholds, and require cost-impact assessments for any new AI feature before it ships. Build that review into sprint planning rather than treating it as a finance team afterthought. This embeds financial discipline into the development process rather than bolting it on after costs have already run up.
What are FinOps practices and why do they matter for AI? FinOps is the discipline of bringing financial accountability to technology spend through collaboration between engineering, finance, and business teams. Applied to AI, it means forecasting token demand before projects launch, setting ROI approval gates for competing use cases, and implementing chargebacks so business units bear the actual cost of their own consumption. The chargeback mechanism in particular creates real incentives for teams to ask whether their usage is justified.
If your highest-consuming teams are also your highest-performing ones, a blanket spending cap is just a tax on performance dressed up as financial discipline.
How should infrastructure choices factor into AI cost governance? Stop treating all AI workloads as equivalent from a cost perspective. Public cloud is the right choice for experimentation and burst capacity where flexibility justifies the premium. Predictable, high-volume inference workloads are better suited to private or on-premises infrastructure where fixed costs outperform consumption pricing over time. Defaulting everything to public cloud absorbs a premium that compounds significantly as workloads scale.
Procurement and Organizational Risk
Our vendor contracts are still per-seat. Is that a problem? Yes. Per-seat pricing no longer maps cleanly to how AI systems generate costs. In many AI-heavy products, the seat is becoming a wrapper around a base level of included usage rather than a reliable proxy for total cost. Every prompt, automated workflow, and background agent can burn tokens regardless of how many people are licensed, creating invoice volatility that per-seat budgeting cannot predict. Push for hybrid models that combine a predictable baseline fee with usage-based pricing above agreed thresholds, with explicit price caps, volume commitments, reporting rights, and overage terms built in.
What changes when a seat becomes a consumption bundle? The license still matters because it controls access, but it no longer tells you enough about cost. Two teams with the same number of seats can generate very different bills if one uses AI for occasional drafting and the other runs context-heavy agents across customer support, software development, or security workflows. Procurement teams therefore need to negotiate included usage, overage rates, usage reporting, and contractual limits on unexpected consumption. The buying question shifts from “how many people need access?” to “how much machine work are we authorizing?”
What is the governance maturity gap for agentic AI? Agentic AI refers to systems that take sequences of actions autonomously rather than responding to a single prompt. That matters economically because an agent is not naturally a seat-based user. It performs tasks, calls tools, consumes tokens, and may keep working after the human has stepped away. Research suggests only about one in five organizations planning to deploy agentic AI has a mature governance model in place. Without clear accountability structures and performance metrics, organizations accumulate what practitioners call “content debt,” meaning AI-generated outputs requiring human remediation that erode the ROI case for further investment. Building governance before you scale is significantly cheaper than retrofitting it after problems surface.

How should we frame AI cost governance to get board-level attention? Frame it as a competitive risk, not a budget management problem. Unmanaged AI consumption erodes margins in a way that compounds over time, and organizations that govern their AI economics well will have a structural cost advantage over those that do not. Tokens are becoming a real operational input, and treating them with the same rigor applied to energy procurement or capital expenditure is not optional for organizations that intend to scale AI seriously

🎗️Cerebras IPO🎗️
Cerebras is going public this week, a milestone for an AI infrastructure company I have followed since its early days. I first met CEO Andrew Feldman in early 2018, before Cerebras had released its first processors and when the company was still focused mainly on AI training. After its first-generation chip came out, one of the first talks the team gave was at a conference I co-chaired in 2019. What makes this IPO especially interesting now is Cerebras’s growing focus on inference, the work of running trained AI models to produce answers, code, images, or other outputs. That shift matters as more enterprises move AI into production and as reasoning models use more compute while generating responses, not just during training. For those of us who build, buy, or use AI applications, another strong, speed-focused alternative to Nvidia is welcome news.

Great to hear about @CerebrasSystems new Wafer Scale hardware technology from their CEO Andrew Feldman #OReillyAI pic.twitter.com/O4HFyHXBkl
— Ben Lorica 罗瑞卡 (@bigdata) September 11, 2019





Source link

Your AI agent looks capable. But can it actually finish the job?



Subscribe • Previous Issues
Why Your AI Agents Fail in Production (And How to Actually Test Them)
In a previous post, I argued that deploying autonomous AI agents reliably is not primarily a model problem. It is an environment problem. The gap between a capable foundation model and a production-ready system is bridged by harness engineering: the discipline of building structured workflows, validation loops, and governance mechanisms around the model rather than inside it. The central argument was that organizations that treat the surrounding environment as the primary engineering target outperform those that chase better models, and that this principle applies across every domain where agents handle complex, consequential work.
That argument raises an immediate practical question: how do you actually know whether an agent is ready for that work? Most existing evaluations still measure narrow, low-friction tasks in controlled or synthetic environments. They can tell you whether a model produces a plausible answer or completes a neat subtask, but they reveal far less about whether an agent can stay coherent across a long workflow, adapt when something breaks, and finish a job that actually runs. Many benchmarks were simple enough that top models were already approaching perfect scores, leaving no meaningful signal about which systems could handle real work and which could not.

Value this newsletter? Consider becoming a paid supporter 🙏

What production usually demands is sustained execution under friction: long chains of interdependent actions, genuine error recovery, and deep domain knowledge applied to messy, open-ended objectives. That is a fundamentally different test than anything most benchmarks were designed to measure. The commercial stakes behind closing that gap are no longer abstract. Terminal-based coding agents alone are already generating billions in revenue, which means accurate measurement of what these systems can and cannot do in realistic conditions has moved from research interest to commercial necessity for anyone building, deploying, or investing in AI agent products.
Measuring the Agent, Not the Demo
Some of the most capable autonomous agents in production today are still concentrated in coding and software engineering. That makes sense. The terminal is one of the few environments where success criteria are clear and feedback arrives immediately. An agent cannot hide behind a fluent answer when a build fails, a dependency breaks, or a command returns the wrong output. It has to keep working until the job is done.
Terminal Bench was built around that reality. It places agents inside real terminal environments loaded with the files, packages, and system configurations needed for the task. Each problem includes an instruction, a verification script, and a reference solution. What gets measured is not whether the agent followed a preferred sequence of steps, but whether it reached a machine-checkable result. There is no partial credit for looking competent. The output either works or it does not.

The significance is not just that Terminal Bench is harder. It is harder in ways that matter. Previous benchmarks often measured narrow command-line skills, relied on synthetic environments, or used tasks so short that they revealed little about sustained execution. Terminal Bench instead asks whether an agent can manage long sequences of dependent actions, recover from real error messages, and apply domain knowledge to open-ended work. Its rigor also comes from the curation. Every task in Terminal Bench is manually reviewed to reduce broken tests, underspecified instructions, and loopholes that let agents game the evaluation. The early results show why that level of manual verification matters. Frontier agents still fail more than a third of the tasks, and smaller models perform much worse. For anyone building, deploying, or investing in agents, that makes Terminal Bench less a leaderboard curiosity than a practical instrument for separating systems that look capable from systems that can actually finish difficult work.
Evaluation is no longer a report card at the end of a cycle. It belongs directly inside the development stack.
The Emerging Infrastructure for Real Agent Evaluation
Terminal Bench has not developed in isolation. A small but important set of related efforts is now building on the same premise that agent evaluation should look more like real technical work and less like a polished demo. LongCLI-Bench pushes this further by focusing on longer command line tasks and by adding step-level scoring, so an agent is penalized not only for failing to finish the job but also for breaking something that previously worked. That is a meaningful advance for anyone building production agents, because regression is often the real failure mode. DevOps-Gym pushes the boundary further into real-world software operations, evaluating agents on their ability to configure builds, monitor systems, and resolve live issues instead of just completing isolated terminal prompts.
(enlarge)
The ecosystem is also expanding into the infrastructure needed to train and compare terminal agents at scale. TermiGen addresses one of the clearest bottlenecks exposed by Terminal Bench, namely the cost of hand-building realistic environments and trajectories for training and evaluation. Terminus and Terminus 2 provide reference implementations for how a terminal agent can interact with a live shell over many steps, which makes them useful both as engineering baselines and as cleaner testbeds for comparing models. And the appearance of fine-tuned terminal-focused systems such as Reptile, LiteCoder-Terminal, and TerminalAgent suggests that terminal competence is now being treated as a distinct capability worth training for directly. Taken together, these developments make Terminal Bench look less like a standalone benchmark and more like the anchor for a broader effort to measure and improve agents that have to do real work under real constraints.
What Comes Next, and What It Means Outside the Terminal
The near-term roadmap for Terminal Bench is really about keeping the benchmark informative. As agents improve, benchmarks only stay useful if they keep stretching the best systems, which means adding harder tasks, expanding domain coverage, and refreshing the suite before leaderboard movement stops meaning anything. Just as important, the Terminal Bench team is making an explicit argument that manual verification is not optional. Their experience showed that confirming task correctness, closing loopholes, and fully specifying success conditions takes substantial human effort, and that cost rises with task complexity.
The infrastructure supporting Terminal-Bench has become more valuable than the benchmark itself. Harbor serves as the expanded framework that allows developers to go beyond basic testing, giving them the tools to optimize AI prompts, run trial-and-error learning, and perform automated quality checks on their agents. That is a meaningful shift. Evaluation is no longer a report card at the end of a development cycle. It is moving into the development stack, not sitting outside it. The ecosystem growing around Terminal Bench is what that shift looks like in practice.
The real leverage comes from the surrounding system, not just the model.
For companies building agents outside coding, this is probably the clearest near-term lesson. The winning approach is unlikely to be full autonomy across messy, high-stakes workflows. It is more likely to be structured human-agent collaboration inside tightly engineered environments. That fits the larger argument in my previous post. The real leverage comes from the surrounding system, not just the model. Terminal Bench sharpens that claim by showing that even in a domain where feedback is fast and success is machine-checkable, reliable autonomous performance remains limited. In domains where mistakes are subtler and more consequential, companies will need even more harness, more evaluation, and more deliberate handoffs between automated execution and human judgment.

Quantum Computing Supply Chains
(enlarge)

The Laws of Thought: The Quest for a Mathematical Theory of the Mind. AI is starting to shape the economy, the job market, and national security. That’s why I think more people should understand the concepts in this highly readable book.
Mutiny: The Rise and Revolt of the College-Educated Working Class. This book struck me as a preview of something bigger. The college grads making lattes and running Apple Store demos are already living the gap between what their degrees promised and what the economy delivers. With AI moving into knowledge work, that gap may widen for many more people.
London Falling. One of my favorite writers delivers again here. I came away feeling like London is not just the setting but almost a character in its own right, with all its glamour, fraud, and seedy underbelly baked into the story.



Source link