DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
TECH & AI
What happens when your agent can touch money
jackminion 0



Subscribe • Previous Issues
Your CLI Was Built for Humans, Not Agents
There’s a friendly debate among developers about how to give AI agents reliable ways to use external tools, data, and services so they can do useful work beyond generating text. One side favors CLIs, or Command-Line Interfaces, where agents run text commands against tools like git, aws, jq, duckdb and internal scripts. The other side favors MCP, or Model Context Protocol, which gives agents a structured way to discover tools, authenticate, and call services through defined schemas. This may seem confined to coding agent, but the tradeoffs apply equally to anyone deploying agents in operations, finance, customer success, or any workflow where agents need to touch real systems. Once an agent starts taking action, its interface with the outside world is no longer just a technical detail. It becomes a critical decision point for security, cost, and governance, regardless of whether that agent is writing code or managing customer data.
If you read often, consider becoming a paid supporter 🙏
 
CLI: Fast, Familiar, and Sharp-Edged
The strongest case for CLI is that it is familiar, flexible,  and cheap. First, AI models have been trained on enormous quantities of shell scripts, developer documentation, and terminal content, which means they already understand tools like git, docker, and kubectl, without any special configuration, and that familiarity translates directly into reliability and lower error rates. Second, CLI output is composable: an agent can pipe the output of one command directly into another to filter, aggregate, or reshape data before it enters the model’s working memory. Finally, the token efficiency advantage is real and measurable. Loading a single MCP server’s full tool schema can consume tens of thousands of tokens before any useful work begins, whereas CLI tools require zero upfront context cost and agents can discover a tool’s capabilities on demand using its built-in –help flag.  The catch is that CLI access can be too powerful. Giving an agent raw shell access without sandboxing, credential isolation, and approval gates makes it incredibly difficult to prevent unauthorized changes to files and networks.

The MCP Case for Agents
MCP’s advocates have a direct response to the CLI-first view: CLI doesn’t account for how most AI is actually consumed in the world. The majority of people interacting with AI agents do so through browser-based chat interfaces or mobile apps where running shell commands is simply not an option, and many business tools have no CLI equivalent at all. For those contexts, MCP fills a genuine gap: it gives agents a self-describing interface where the agent discovers which tools are available and how to use them upon connecting, without needing to guess command syntax or parse documentation. Unlike CLI, MCP includes built-in OAuth authentication, per-user permissions, and audit trails that satisfy enterprise security requirements.

The main criticism is overhead. Poor MCP implementations can load huge tool schemas before useful work begins, burning tokens, adding latency, and leaving less room for reasoning. MCP can also introduce server failures, authentication friction, and harder debugging. The practical lesson is that MCP needs good interface design: smaller task-level tools, progressive disclosure, schema filtering, and gateways that show agents only what they need.
Your CLI Was Built for Humans, Not Agents
An agent can learn command syntax. The harder problem is that most CLIs were designed for humans, not software agents operating under time, token, and safety constraints. We easily overlook these flaws because humans are great at filling in the blanks. We can guess missing steps from bad manuals, decode vague error messages, and realize on our own when a tool requires us to log in before showing its options. An agent pays a concrete cost for every one of those gaps: repeated discovery loops, wasted tokens, fragile text parsing, and unnecessary interruptions asking the user what to do next. The CLI didn’t change. The user did.

The practical response is to treat CLI agent-readiness as something you can measure and improve, not just assume. An open-source project called CLIARE (CLI Agent Readiness Evaluation) does exactly this. It probes the actual installed binary, not your documentation, records what happens, and produces a scored report across six dimensions: whether commands are findable and navigable, whether valid invocations can be constructed, whether commands complete without hanging, whether bad inputs fail with clear errors, whether machine-readable output modes are available and actually work, and whether read-only probes stay read-only. The result is a scorecard you can run, track across releases, and share with the teams building agents on top of your tooling. That shifts interface quality from a guessing game into a measurable metric.
This matters well beyond coding agents. Companies can expose real operational authority through CLIs: deployments, finance workflows, database jobs, cloud control planes, support scripts, analytics pipelines, and internal platforms. If agents are going to touch those surfaces, the relevant question is not just “does a CLI exist?” It is “can the agent understand and use it without guessing?”  AI teams exposing CLIs to agents should try CLIARE, or at least borrow its core idea: make the command surface measurable, versioned, parseable, and explicit about preconditions, outputs, side effects, and risk.

Match the Interface to the Risk
I would not treat this as a religious choice between CLI and MCP. The better question is what kind of authority the agent is being given, and on whose behalf it is acting. Use CLI when the workflow is local, composable, inspectable, and already lives close to the terminal: code, tests, logs, files, data inspection, build systems, mature vendor tools, and internal scripts. But if agents will use that CLI repeatedly, use CLIARE to measure the surface before relying on it.
Use MCP when the workflow is hosted, multi-user, permissioned, or tied to SaaS systems where OAuth, consent, scoped access, and audit trails matter. In both cases, raise the bar when the agent can touch money, identity, production systems, customer data, or irreversible state. The common design rule is simple: expose the task, not the whole system. Keep the interface small, prefer parseable outputs, separate reads from writes, log consequential actions, and require approvals for operations that cannot be easily undone. Transport choice matters. Interface design matters more.

The AI Developer Productivity Debate: A Field Guide
From “Does AI Actually Make Developers More Productive? The Evidence, For and Against”



Source link

TECH & AI
I talked to Google’s former AI head about messy data
jackminion 0



Subscribe • Previous Issues
Agents Need Maps, Not Bigger Context Windows
Like everyone else, I’ve been enjoying the steady improvement in coding agents and the tooling around them, from frameworks and harnesses to evaluation suites. But the more I talk with teams actually deploying agents in enterprises, the more I circle back to plumbing. Agents need data integrations and infrastructure built for them, a theme I explored in a piece on rethinking databases for agents. I’ve also written about using knowledge graphs (GraphRAG) to improve accuracy and reduce hallucinations, which is especially important in high-stakes applications. The persistent problem has been that most teams don’t have a knowledge graph, and the few that do struggle to keep it current. A new system I recently came across is aimed squarely at that gap.
If you read often, consider becoming a paid supporter 🙏

Automating Graph Construction and Maintenance
I recently spoke with Andrew Moore, CEO of Lovelace, former head of Google Cloud AI, and former dean of Carnegie Mellon’s School of Computer Science. Lovelace’s Elemental platform turns enterprise data into structured context engines that AI agents can navigate and investigate. I think “knowledge graph” is still a reasonable term here, although “context graph” may be closer to the point. This is not a graph built mainly for a human analyst browsing nodes on a screen. It is designed for agents that need to answer questions too large, messy, or time-sensitive for ordinary search, basic RAG, or stuffing more raw documents into a context window.
Elemental ingests whatever you have: relational tables, PDF files, news feeds, JSON fragments, even satellite imagery and other multimodal sources. Everything gets converted into a common intermediate form that eventually becomes nodes and relationships in a graph. The platform automates much of the construction and maintenance of these graphs. A graph with a thousand nodes can tolerate a human in the loop, but once you’re at many millions of facts, any step that depends on a person checking whether two records refer to the same company simply collapses. Too many enterprise AI projects die in the six months of data wrangling that comes before any actual AI work, and removing that toil is the whole point.
For an agent, a context graph gives it a map of the enterprise and the surrounding world. A bank investigating exposure to a sanctioned shipping company might need to connect ownership records, trade data, vessel movements, subsidiaries, legal filings, customer relationships, and recent news. Vector search can find relevant documents, but these questions often require following relationships across many entities and events. That is where a graph-shaped context layer becomes useful.

Graphs for Agents, Without a Graph Database
Elemental is designed around four steps: data ingestion, entity resolution, graph construction, and agent-facing tool access. I covered ingestion above, but one constraint is worth adding: the system has to work without assuming clean schemas, consistent naming, or a single source of truth. 
Entity resolution is the problem of deciding when different records refer to the same real-world thing. “IBM,” “International Business Machines,” an internal vendor ID, a legal entity in a filing, and a name in a PDF might all refer to the same company, or they might not. The same issue appears with people, ships, aircraft, accounts, subsidiaries, addresses, products, assets, and events. Anyone can prototype an entity resolution system in a weekend. Making one that scales, handles multiple languages, adapts to entirely new entity types, and updates as new information arrives is brutally hard. Lovelace built its own engine and goes well beyond text matching. I half-jokingly told Andrew that the entity resolution engine alone could be a standalone product, given how many applications live or die on getting this right.
Enterprise agents do not just need more context. They need context they can trace, rank, and trust.
Auditability is just as important. In regulated or high-stakes settings, the system needs to show where a fact came from, how it was linked to other facts, and what version of the graph existed when an agent produced an answer. In plain English, that means lineage, provenance, and version control: how a fact moved through the system, what evidence supports it, and what the graph believed at a point in time. That matters if a regulator, customer, or internal reviewer asks why an agent flagged a transaction, recommended an investigation, or dismissed an alert. “The model said so” will not be enough.
Retrieval is where the graph becomes more than a data catalog. In a serious graph, a single node can have hundreds of thousands of links, so a naive “show me everything within two hops” query explodes into billions of paths and grinds to a halt. Elemental takes a different route. It reframes a question like “who is most affected by this event?” as a probability problem, then uses randomized algorithms and other graph-theory tricks to surface the strongest connections without walking every path. The result is approximate rather than mathematically exact, but it returns confident, ranked answers over millions of nodes in under a second. That trade is well worth making, because the alternative is an LLM trying to reconcile contradictory probabilistic evidence in its head, which language models are genuinely bad at.

Another interesting design choice is that Elemental does not rely on a graph database as the core storage layer. The data is exposed to agents as a graph, but the persistence layer underneath is custom. The reason is simple. Traditional graph databases are very useful, but they were not built for this particular job: broad, high-speed inference across tens of millions of nodes.
Why Private Graphs Need Public Context
Lovelace also brings another asset to the table: YottaGraph. Think of it as a large, continuously updated graph of the public world, covering companies, people, places, events, filings, sanctions records, and the movements of ships and aircraft. This is useful because internal enterprise data rarely tells the whole story. YottaGraph would be hard to replicate because it requires continuous ingestion from many sources, entity resolution at scale, and a lot of operational discipline. Importantly, the enrichment flows inward. Public context can augment a company’s private graph, but Lovelace does not share one customer’s data with other organizations.
Lovelace isn’t alone in using graphs to give agents better context, and I expect to see much more activity here. There is also a funny twist. GraphRAG was promoted heavily by graph database vendors, but some of the more interesting graph systems for agentic AI may not use graph databases at all. Whatever we end up calling these things, knowledge graphs, context graphs, or context engines, the underlying idea of structured, auditable context for agents is becoming hard to ignore.

OckBench: The Cost of Getting the Right Answer
Derived from “OckBench: Measuring the Efficiency of LLM Reasoning”



Source link

TECH & AI
What your base model doesn’t protect you from
jackminion 0



Subscribe • Previous Issues
The Data Compliance Problem AI Teams Keep Ignoring
I’ve avoided writing about copyright and AI. Not because it isn’t important, but because it felt like a legal sideshow compared to the engineering and business questions I find more interesting. That’s gotten harder to justify. There is also something mildly funny about naming my podcast The Data Exchange years ago, because I believed data markets would become central to technology, and then mostly ducking this corner of the data conversation. The data question is now central to how AI systems are built, how they compete, and how they create risk. You can’t talk seriously about any of that without eventually bumping into who owns the stuff these models are trained on.

A frequent reader? Consider becoming a paid supporter 🙏

For AI teams, data is no longer just raw material. One recent economics paper estimated that the value of data missing from official GDP figures amounts to about 4% of GDP on average, and closer to 6% in more recent years. More interesting for companies is the relative value of their own operational data: transaction logs, usage records, support tickets, product telemetry, and customer interactions. That internal data can be more informative than public web data because it captures how a real business actually works. For AI builders, the practical implication is simple: the data sitting inside your company may be more strategically valuable than anything you could scrape from the open web.

The Data Supply Chain Problem
The first practical issue is provenance: knowing where training data came from, what rights apply, and whether it can be inspected or reconstructed later. That used to sound like paperwork. It now looks like core infrastructure. What a model knows, where it performs well, where it breaks down, and what legal exposure it carries are all shaped by the data it was trained on. Pre-training is the broad phase where a model absorbs patterns from large collections of text, images, code, books, journalism, and other sources. Post-training is where you steer the model toward specific tasks, behaviors, and domains using narrower, more curated datasets. Both phases are data strategy questions as much as engineering questions. For most teams, the immediate action is not to audit a trillion-token pre-training corpus. It is to get serious about the smaller, higher-value datasets they use to adapt, evaluate, and deploy models.

Memorization adds a second layer of risk. A model does not need to act like a database to create trouble. Under the right prompts, especially when material appears many times in training data, it may reproduce protected text, code, lyrics, images, or paywalled content too closely.  That makes copyright risk a lifecycle issue, not just a training-data issue. Hosted models give providers more room to monitor, filter, and rate-limit suspicious behavior. Released model weights are harder to control. Either way, teams need to test for verbatim reproduction, near-duplicates, and outputs that could substitute for the original work.
Guarding Your Post-Training and Fine-Tuning Pipelines
Most AI teams aren’t doing pre-training. They’re taking a foundation model and adapting it: fine-tuning on domain data, building instruction datasets, running human feedback loops, assembling evaluation suites, or wiring up retrieval pipelines. That’s where the real data work happens for the majority of developers, and it comes with its own provenance problems. The data you use to customize a model, customer support logs, internal documents, expert annotations, licensed content, third-party datasets, needs the same documentation discipline as any other part of the stack. Where did it come from? What rights apply? Was it collected with appropriate consent? Can you reproduce it if challenged? These questions matter whether you’re fine-tuning a vertical copilot or building an evaluation harness, and the answers are often murkier than teams expect. A lightweight data bill of materials can help: a record of each dataset, its source, license terms, consent status, known restrictions, and intended use.

There’s also a technical risk that’s easy to underestimate in post-training contexts. Fine-tuned models can memorize training examples more readily than large pre-trained models, partly because the datasets are smaller and examples may repeat. A customer-facing model fine-tuned on proprietary documents, licensed text, or third-party content could reproduce that material verbatim in ways that create real liability. That risk doesn’t disappear after training ends. Output monitoring matters: similarity detection, content flagging, and policies for handling prompts that look like attempts to extract protected material should be part of any production deployment. No single control handles all of it, and the teams most likely to get caught flat-footed are the ones who assumed that using someone else’s base model meant the data compliance problem was already solved.

Who Owns the Fuel That Runs These Models
We are also seeing the rise of a formal data licensing market, where major publishers and content platforms sign deals with AI labs. While this reduces legal uncertainty for those who can afford it, it also threatens to create a massive moat for wealthy incumbents. Large AI firms can afford broad or exclusive deals that smaller labs, startups, researchers, and open-source projects cannot.
The legal landscape is also evolving unevenly around the world. The U.S. still relies heavily on case-by-case fair use arguments. Europe is pushing more toward transparency, opt-outs, documentation, and compliance processes. Some Asia-Pacific jurisdictions appear more permissive for computational analysis, but global deployment complicates everything. A model trained in one place can be used, challenged, or regulated somewhere else. In practice, many companies will opt to satisfy the strictest plausible standard, especially if they sell to large enterprises or regulated industries.

This is why AI and copyright no longer feel like a legal sideshow to me. They are part of a larger question about how data markets will actually work: who gets paid, who gets access, who can prove what they used, and who can afford the cleanest inputs. The industry still has to find a workable balance between adaptation and attribution. Data is no longer just exhaust from the internet or residue from business operations. It is becoming one of the main assets, bottlenecks, and fault lines in AI. The teams treating it as a compliance checkbox are going to find that out the hard way.

The Runtime Pattern Behind AI Agents

Claude Code to Cursor: a poem



Source link