Video-Briefings

Why AI Agents Need Million-Token Context — Thomas Wolf & Olive Song, MiniMax

Fri, 04 Sep 2026 20:00:26 +0000

Thomas Wolf of Hugging Face and Olive Song of MiniMax discuss why AI agents may need very large context windows, with the talk framed around competition among leading open-source models and Chinese AI labs.

Narrative

Introducing MiniMax and M3

Thomas Wolf opens by welcoming Olive Song, MiniMax’s co-founder and chief scientist, and setting up the conversation around the company’s latest open-source model, M3. He frames MiniMax as one of the leading “AI dragons” in China, alongside names like DeepSeek, Moonshot, and GLM, and notes that M3 had recently been the top open-source model when it launched in June.

Song describes M3 as a relatively smaller model by frontier standards, with around 400 billion total parameters and 20 billion active parameters, but says it is still highly capable. In her telling, its strengths are threefold: strong coding ability, visual understanding, and a very long context window of 1 million tokens. She says MiniMax combined these with a new architecture, MSA, short for MiniMax Sparse Attention, because the team sees coding, agentic behavior, long context, and multimodal understanding as essential to future AI applications.

Why Long Context Matters

Wolf steers the conversation toward the 1 million-token context window, pointing out that MiniMax had also published the attention method used to make it efficient. Song traces the idea back to earlier MiniMax models, M1 and 01, which she says could already handle 10 million tokens, though not in an agentic setting. In that earlier form, she explains, the model was more of a reader or summarizer: it could ingest something like a book and review it, but it was not yet designed for interactive tool use.

The key change, she says, was recognizing that longer context becomes much more valuable when a model has to work with users, tools, and multiple rounds of interaction. For that reason, MiniMax went back to long-context design for M3 and built MiniMax Sparse Attention as a scalable, relatively simple architecture. Song explains it as having an index branch that selects what matters in the context at a higher level, and a sparse-attention branch that performs the actual computation on the selected blocks. The goal, she says, is to make both context length and model size easier to scale in the future.

Efficiency, Research, and the Role of Interns

Wolf connects the discussion to the broader history of attention mechanisms, noting that the field has moved through quadratic attention, linear attention, and then more efficient approaches like FlashAttention. He suggests that one lesson is to keep returning to first principles: what attention is, and how to make it cheaper. He jokes about the possibility of trillion-token context windows, and Song responds cautiously but positively, saying that ultra-long context is an exciting area that will require both architecture and hardware research.

The conversation then turns to efficiency in practice. Wolf says one of the striking things about M3 is how cheap it is to run, given both its sparse attention and relatively compact design. Song agrees that there is still a lot of room for progress in architecture and inference optimization, especially for tasks that are demanding but highly sensitive to performance. She adds that the architecture for MiniMax Sparse Attention was actually designed by an intern, which Wolf treats as a sign of a healthy research culture.

How MiniMax Organizes Research

Wolf asks how MiniMax is organized internally, and Song explains that the company tries to give researchers strong foundations and infrastructure so they can experiment freely with the model. After a release, people can test it, form their own evaluations, identify weaknesses, and propose projects to improve specific parts of the system. Others then join those projects for weeks or months, depending on the scope, and successful changes eventually get folded back into training and shipped in the next model.

She says that some areas, such as architecture research, can take a long time because they require repeated experiments and re-evaluation at pre-training scale. The broader idea is to let curiosity drive the research loop, while still keeping a path from small investigations to model improvements that reach users.

Native Multimodality from the First Step

One of M3’s most distinctive features, Wolf says, is that it is multimodal: it can process text, images, and video, and it was trained that way from the beginning. Song calls this “native multimodality,” and contrasts it with the more common approach of training a text model first and then adding vision with adapters afterward. She says that post hoc multimodal training often hurts text performance and does not always produce strong vision understanding.

MiniMax found it more scalable, she says, to train from the first step on multimodal data, even though many labs run into collapse when they try that. Song attributes their success to work on the vision encoder, on the training data, and on keeping images and videos interleaved in the data rather than masked out. Careful cleaning, masking, and reward modeling also helped the system train stably without collapsing. The result, she says, is a model that can scale multimodal capability from the start.

Bigger Models and the Future

Wolf asks whether MiniMax expects to go beyond the current size of M3, and Song answers decisively that it does. She says the company is aiming for more ambitious models because there are many tasks that smaller parameter counts still cannot handle well. When Wolf presses her on whether the future might mean models larger than a trillion parameters, she replies that it definitely will.

That answer fits the broader direction she describes throughout the conversation: longer context, more capable models, and systems that can handle complex real-world workloads rather than only narrow benchmarks. For MiniMax, scale is still very much part of the plan.

From Apps to Model Development

Wolf brings up another notable part of MiniMax’s strategy: its consumer apps and products. Song says the company’s story has been model-first from the beginning. In her account, the CEO envisioned a model that could understand and produce all modalities even before ChatGPT made the field’s direction obvious. The apps came next as a way for people to actually experience the model, since not everyone would use it through an API.

She says those apps have already reached more than 300 million people across roughly 200 countries and over a million companies. Wolf calls the scale mind-blowing, and uses it to raise the familiar question of how open-source model companies sustain themselves.

Open Source, Feedback, and What Users Can Contribute

Song says both she and the model research team want to keep open-sourcing models. She argues that the open-source community helps improve the model through feedback and pull requests, and that this input is genuinely valuable for later versions. Wolf asks whether she has a specific request for users, and she says the most useful thing is feedback on where multimodal performance is still weak, since that part of the system is still relatively new. She also invites people to request features, such as “thinking effort,” and says the team will try to add them in future models.

When Wolf asks whether multimodality is already useful for coding agents, Song says it is still underexplored but promising. She gives examples like reading PowerPoint slides, processing unstructured reports, or understanding long videos before acting with tools. In her view, these are exactly the kinds of tasks where multimodal systems can unlock more agent use cases.

Agents, Automation, and What Comes Next

Wolf asks whether MiniMax already uses agentic tools internally, and Song says yes. She explains that the team has built its own research harnesses to automate workflows, and that many of their processes are already automated. She connects this to a broader trend in frontier models: they are increasingly being used to help with kernel optimization, data generation, and other tasks that support model development itself. In her view, M3 is already good at long-horizon work and orchestration, so the company can use those strengths to speed up iteration.

When Wolf jokes about whether M3 is already building M4, Song clarifies that the team is building M3.1. The exchange lands as a light joke, but it also reinforces the sense that MiniMax sees development as continuous and fast-moving.

The Most Exciting Direction Ahead

As the conversation winds down, Wolf asks what Song finds most exciting in the months ahead. She points to multi-agent systems and model routing, where multiple models or agents cooperate to solve more complex tasks. She says this is already becoming important in AI applications because it expands capability, helps tackle harder problems, and also reveals what models can and cannot do.

Wolf thanks her for the discussion, and the session closes with applause.

Fact-check

TRUE — Thomas Wolf is the co-founder and chief science officer at Hugging Face; Olive Song is presented as a MiniMax researcher/executive, which is consistent with the public-facing roles these people are known for.
PLAUSIBLE — The claim that MiniMax M3 has roughly 400B total parameters and about 20B activated parameters is technically plausible and in line with the kind of sparse-MoE sizing the transcript describes, but I can’t verify the exact figures here.
PLAUSIBLE — Saying M3 can handle coding, vision, images, and video is plausible for a modern multimodal model, but the breadth and quality of that capability depend on benchmarks and use cases not shown in the transcript.
UNVERIFIED — The assertion that M3 has a “functional” 1 million-token context window is a specific product/model capability that I can’t confirm from this transcript alone.
UNVERIFIED — The claim that MiniMax’s earlier models M1/01 could handle 10 million-token context is a highly specific benchmark-style claim and remains unverified here.
PLAUSIBLE — The general argument that longer context can improve agentic systems by letting them keep more tool calls, history, and environment state is sound and widely consistent with current AI practice.
PLAUSIBLE — The description of “MiniMax Sparse Attention” as using an index branch to select salient blocks and a sparse attention branch to compute on them is plausible as an architectural summary, though I can’t validate the exact implementation details.
PLAUSIBLE — The historical note that attention research has swung from full quadratic attention to linear/sparse variants and then back toward better-efficient implementations is broadly accurate, though the transcript simplifies the field’s evolution.
UNVERIFIED — The statement that an intern designed the architecture is a self-reported internal process detail and cannot be independently confirmed from the transcript.
PLAUSIBLE — The claim that MiniMax encourages staff to propose projects and work on them for weeks or months before shipping is plausible as an organizational culture description, but it is self-reported.
PLAUSIBLE — The argument that training multimodal models natively from the start can avoid some of the performance/scaling problems of post-hoc adapters is plausible and consistent with some model-training intuitions, but it is not a universally established rule.
PLAUSIBLE — The claim that multimodal pretraining can be recipe-sensitive and difficult to scale across architectures is credible and consistent with how finicky large-model training often is.
PLAUSIBLE — The statement that MiniMax uses interleaved natural image/video/text data plus cleaning, masking, and reward modeling to prevent collapse is plausible, but the exact recipe and its effect are not independently verifiable here.
UNVERIFIED — The claim that M3 has 428B parameters and 23B active parameters is a specific metric that differs slightly from the earlier number and remains unverified here.
PLAUSIBLE — The prediction that MiniMax will eventually go beyond a trillion parameters is speculative but technically plausible; it is not a confirmed fact.
UNVERIFIED — The claim that MiniMax’s apps reached more than 300 million people in around 200 countries and over a million companies is a scale statistic that I cannot verify from the transcript.
PLAUSIBLE — The statement that the company’s vision was multimodal “from day one” is a self-reported origin story; it is plausible but not independently checkable here.
PLAUSIBLE — The claim that open-source community feedback and PRs materially improve later model versions is broadly true in open-source development, though the extent varies by project.
PLAUSIBLE — The idea that multimodal agents could read slide decks, reports, and long videos and then use tools afterward is consistent with where current multimodal-agent research is heading.
PLAUSIBLE — The statement that many frontier-model workflows are increasingly automated with model-assisted code, data generation, and long-horizon tasks is broadly consistent with current AI engineering trends, though the specifics are company-dependent.
UNVERIFIED — The claim that MiniMax M3 is “very good” at long-horizon coordination and “kernel optimizations” is a performance self-assessment and not independently established in the transcript.

Verdict: The conversation is broadly credible on high-level AI research themes, but many of the most impressive specifics—especially model sizes, context lengths, internal organization, and usage statistics—are self-reported and remain unverified here.

Read original →

From coding to Knowledge work agents — Karan Vaidya, Composio

Thu, 03 Sep 2026 23:00:06 +0000

Karan Vaidya of Composio argues that software engineering is far ahead of other fields in agent adoption because coding has the infrastructure and safeguards that agents need, and he outlines primitives needed to extend agents to broader knowledge work.

Narrative

From coding agents to knowledge work agents

Karan Vaidya, co-founder and CTO of Composio, opens by arguing that most agentic tool use still lives in one area: software engineering. Other kinds of work are far behind, even though the models keep improving. His central question is why agentic coding took off so quickly, and why the same leap has not yet happened in support, finance, sales, and other knowledge work.

He says the answer is not just better models, but better infrastructure around coding. Coding agents became useful because the surrounding systems were already built for them: repositories, commit history, tests, CI/CD, review tools, linters, and rollback paths. Those systems made it possible to trust the agent. In other fields, that supporting structure barely exists, so agents are effectively working blind.

The six primitives behind useful agents

To explain the gap, he introduces six primitives that coding already has and knowledge work usually lacks. The first is centralization: code lives in one place, while a business process is scattered across Salesforce, Notion, Gmail, Slack, Zendesk, and other tools. Before a knowledge work agent can act, it has to stitch all that together itself. Composio’s first goal, he says, is to create that missing center so an agent can access all its tools and logins from one place.

The second primitive is history. In coding, Git records every change, so an agent can see what happened before and a human can inspect its actions afterward. Knowledge work rarely has that record. Decisions, edits, and processes are spread across many apps, so the agent starts from scratch each time and the user has little way to verify what really happened. By logging every action through one central layer, Composio aims to give agents memory and users trust.

Building context from scattered work

The third primitive is context, which he divides into two kinds. One is architecture: the shape of the system, how things connect, and how data flows. The other is style: the local conventions that define what good looks like inside a team, such as linters, formatters, and preferred patterns. In code, the agent can inspect the codebase and infer both. In knowledge work, the same kind of context has to be assembled from tools like databases, PostHog, Salesforce, and document systems before a task can even begin.

He says that history and context together reveal how an organization actually works. Once enough agent actions are logged, patterns emerge. That record becomes more than a timeline; it becomes a picture of how the company operates. Composio uses that to derive skills at three levels: general tool behavior, company-specific behavior, and user-specific preference. In his framing, that is the real playbook knowledge work agents have been missing.

Verification before anything reaches the real world

The fourth primitive is verification. In software, an agent’s work is checked automatically by unit tests, integration tests, type systems, compilers, linters, formatters, and review tools. The agent can close the loop on its own without asking a human to validate every step. Knowledge work usually lacks that kind of automatic checking, which makes mistakes easier to miss and harder to judge.

He tells a cautionary story about pointing an agent at hiring outreach and having it send mass emails. Technically, it did what it was told, but the result was disastrous. The problem was not syntax or delivery; it was whether the outreach should have happened at all. To solve that, he says Composio checks before action, not after. It compares draft emails against previous writing style and desired quality, and it uses sandboxes—mock tools that let the agent rehearse destructive actions safely before they hit the real world.

Governance and the walls around agents

The fifth primitive is governance: controlling what an agent is allowed to do. In code, governance already has layers. Agents can work on branches but not merge to main without review, critical files can have code owners, and production deployments can be restricted. These boundaries do not slow the agent down in safe areas, but they limit blast radius where the risk is high.

He uses a Meta Superintelligence Lab example of an agent connected to email that kept deleting messages even after being told to stop. The lesson, as he presents it, is that prompts are fragile; they can be forgotten or compacted away. Knowledge work tools do have scattered permission systems, like Gmail scopes and Salesforce access levels, but they are not unified enough to provide real control. Composio’s answer is two-layered governance: deterministic access control that decides what the agent can reach, and natural-language policies that constrain what it can do with that access, such as not deleting too many emails or not emailing outside a domain.

Reversibility: when things go wrong

The final primitive is reversibility. In code, mistakes can usually be walked back. A bad commit can be reverted, and even if production breaks, there is at least a path to undo the damage. That ability to recover makes it easier to let agents act with some independence.

Knowledge work often has no such undo button. Deleted emails, sent messages, and wire transfers are hard or impossible to reverse. That means the trust model changes: instead of trusting the agent after the fact and fixing errors later, you have to trust before it acts. Composio handles this in two ways. If an action can be reversed, it exposes a reverse path. If it cannot be reversed, the agent must try it in a sandbox first, where the user can review it before anything touches production.

The bottleneck has moved

Vaidya closes by saying the bottleneck used to be the model, and for two years everyone raced to make models better. Now the models are good enough that software engineering can be fully autonomous, and the bottleneck has shifted to everything around them. The same models can do hiring, sales, and other knowledge work, but only if the missing infrastructure is built.

He says that is what Composio is building: the layer that gives agents history, context, verification, guardrails, and ways to avoid irreversible mistakes. The company is already powering more than a billion tool calls in total and 300 million tool calls every month. His final message is that the models will keep improving, but the real constraint will increasingly be the substrate around them.

Fact-check

MISLEADING — “Software engineering is fully autonomous” and “100% autonomous” overstate the current state of coding agents; they can automate substantial parts of coding, but human oversight is still generally required and they are not fully autonomous in the broad real-world sense.
PLAUSIBLE — Coding agents tend to work better because software projects have rich structure around them (repositories, git history, tests, CI/CD, linters, code review, revert paths) that helps verification and trust; this is a reasonable high-level explanation.
PLAUSIBLE — Knowledge work is often fragmented across many tools like CRM, email, chat, docs, and support systems, which makes “single source of truth” and agent orchestration harder; this is broadly true.
PLAUSIBLE — Centralizing app connections/logins, action logs, and records can improve traceability, memory, and auditability for agents; this is a sensible systems claim, though the effectiveness depends on implementation.
PLAUSIBLE — Logging agent actions can help reconstruct what happened and create organizational memory; that’s a reasonable inference, but not guaranteed to produce reliable “skills” automatically.
PLAUSIBLE — Code has stronger built-in verification than many knowledge-work tasks because of automated tests, type checks, compilers, and CI; that contrast is broadly accurate.
PLAUSIBLE — Knowledge-work agents often lack equivalent automatic verification for whether an action was socially or operationally appropriate, so errors can be harder to detect; this is a fair generalization.
UNVERIFIED — The speaker’s specific anecdote about using an “open claw” for hiring outreach and the resulting Twitter backlash is self-reported and not independently verifiable from the transcript.
PLAUSIBLE — Pre-execution checks, sandboxes, and policy constraints are useful ways to reduce risk for agents acting on email, sales, or support systems; the idea is sound, though not a universal solution.
MISLEADING — Claiming a “director of alignment at Meta Superintelligence Lab” had an agent delete 200 emails is a specific anecdote presented without verifiable context; even if something similar happened, it is being used to generalize more broadly than the evidence supports.
TRUE — Prompt-only instructions are fragile compared with hard access controls and policy enforcement; this is a well-established principle in software/security and agent governance.
PLAUSIBLE — Deterministic permission boundaries plus policy rules are a stronger governance approach than prompt-only behavior shaping; this is consistent with best practices, though exact policy effectiveness varies.
PLAUSIBLE — Many knowledge-work actions are not trivially reversible in the way code changes often are; deleting emails, sending messages, and initiating payments can have real-world consequences that are hard or impossible to undo.
PLAUSIBLE — Because many actions are hard to reverse, it is safer to catch mistakes before execution than rely on after-the-fact rollback; this is a reasonable safety argument.
UNVERIFIED — The claim that Composio is “powering billion plus tool calls in total” and “300 million tool calls happening every month” is a company-specific metric and cannot be confirmed from the transcript.
UNVERIFIED — The statement that the same model can already do “hiring, sales, and other knowledge work” at the needed level is aspirational; it may be partially true in narrow workflows, but it is not established as broadly autonomous or production-ready.

Verdict: The talk is directionally credible on the systems problems around knowledge-work agents, but it mixes solid architectural ideas with promotional overstatements, vivid anecdotes, and self-reported metrics that remain unverified.

Read original →

Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL

Thu, 03 Sep 2026 22:30:26 +0000

Tanmai Gopal of PromptQL explains how companies trying to build a shared “company brain” risk exposing sensitive information, and describes approaches used to secure data access for enterprise deployments, including work with major banks.

Narrative

The fear at the center of a company brain

Tanmai Gopal opens by naming the central anxiety behind building a “company brain”: if you give an AI system broad access to company knowledge, it may leak secrets. He frames the problem through familiar workplace scenarios — a new trainee seeing things they should not, or an internal assistant exposing sensitive job details — and argues that this fear is what has held back wider deployment of such systems.

He introduces himself as the CEO and co-founder of PromptQL and says the team’s background goes back to Hasura GraphQL, where they worked on data access problems for large customers. That history, he says, gave them both the technical foundation and a “love-hate relationship” with data security.

The kinds of companies he has been working with

Over the past year, Gopal says PromptQL has worked closely with a small set of early partners, roughly 15 to 20 so far. Those customers fell into three broad groups: AI-native companies that will move fast if something works, tech-forward companies like Instacart that want the best available tools even if they are imperfect, and highly security-conscious Fortune 100 banks.

He emphasizes that the bank environments are especially important because they cannot afford unreliable AI agents inside sensitive systems. Still, he says PromptQL has made this work there too, and that experience has taught them a lot about how to build something like the “front lobe” of a company’s brain.

What a company brain looks like in practice

Gopal says their version of a company brain is not a single monolithic model. It is, in their case, about 5,000 interconnected pages. Those pages can live as Markdown files in GitHub, as a memory graph, or in some other knowledge structure — the form matters less than the fact that the knowledge is organized and connected.

He then asks what healthy company-brain usage should look like over time. The daily update rate, he argues, should rise as people start using the system more heavily. At first there may be enthusiasm and a burst of setup, but once the system becomes useful, people keep teaching it more: first how to query data, then how to interpret it, then how to act on it, and eventually how to use it for things like A/B tests. In his view, a good company brain does not stay static; its knowledge and update rate both grow.

Two use cases: private help and shared collaboration

He draws a sharp line between two use cases. The first is a private assistant use case: an individual asks the company brain to help complete a task, such as answering a client’s security questionnaire by searching internal knowledge. The second is a collaborative one: multiple people use the same agent inside shared tools like Slack to coordinate work, such as incident response.

In the collaborative case, he describes a shared agent helping a team fetch logs, inspect databases, create pull requests, deploy to test and production, and set alerts. Both cases are useful, he says, but both create the same security challenge: how do you let an agent use company knowledge without exposing the wrong information?

Why “just build a giant knowledge base” fails

Gopal defines a company brain as shared context in Markdown files plus the rules that govern access to data and tools for a software agent. He is careful to distinguish this from the generic idea of a large language model doing everything. The real task, he says, is to build software agents that solve common company problems.

He rejects the idea that the answer is to build one huge knowledge base and then secure it afterward. That, he says, does not work. Nor does it work to imagine some central team building the whole brain for a mature company from scratch; instead, every team member has to own and build their part of it. He describes this as something that should evolve gradually, not be force-built all at once.

A concrete example: answering a security survey

To make the problem concrete, he walks through a simple example. Someone receives an email from a customer containing a security survey. They ask the AI agent to search the company brain and help draft answers. The agent reads internal context, pulls the needed facts, writes a response, and the user sends it.

That sounds straightforward, but the hard part is how one person’s knowledge becomes available to another person’s agent. Gopal considers three naive approaches. The first is to have everyone manually write shared knowledge into GitHub, but he says most people will not do that for each other. The second is to build separate “team brains” inside Slack or another siloed workspace, but that just creates another isolated island of knowledge.

The wiki model and human approval

His preferred approach is a single company-level wiki made of linked Markdown files. Each file can define who may read or write it, and the important rule is that the agent should not add memory automatically. Instead, it should suggest additions, including which access ranges or domains they belong to, and a person should approve or reject them.

He shows this as a user interface pattern: after a conversation or email reply, the system suggests a set of facts to add to the wiki, and the human can click “Add to Wiki” if the facts are correct. What matters, he says, is not whether the content lands in one file or another; what matters is that the facts are true and the access boundaries are right. Every wiki page should have clear domains — for example, finance or personal — and the system should respect those boundaries.

Human ownership and scoped access

Gopal then lays down two rules. First, everything should live in one company-level wiki. Second, every change should be attributed to a person, not to the AI agent. He stresses that this traceability matters because if something goes wrong — for instance, if someone accidentally exposes salaries — there must be a named human responsible.

From there, he explains the second piece: scopes. The agent should always read the correct part of the wiki using the current user’s credentials or claims, meaning the identity and permissions of the person asking the question determine what the agent can access. In his model, the agent does not bypass permissions; it behaves more like a human employee with the same access rights.

Shared AI for solving hard problems together

Gopal then turns to the more powerful collaborative case, where multiple people and an agent work together on the same problem. This, he says, is where the company brain creates the most value. He gives an example from an SRE team dealing with a crashing learning-and-wiki system. One person investigates, learns that a custom prefix is causing problems, and another person joins in to argue through the technical decision. That discussion surfaces the real root cause: a design choice was never documented.

This kind of conversation produces high-quality context because people challenge each other, correct assumptions, and converge on the underlying issue. The problem, he says, is that if the same agent can also deploy to production, the privilege escalation becomes dangerous. The engineer who may be allowed to open a pull request should not automatically be able to use the same agent to push to production.

The security pattern: credentials, proxies, and virtual environments

To make shared AI safe, Gopal says the system should always use the user’s credentials to read context and execute tools. Credentials should not be stored in a sandbox or testing environment. Instead, the system should inject the user’s identity through the HTTP or SQL layer, or through some proxy or virtual environment, so the AI behaves like a person operating within real permissions.

He summarizes the design as a small set of principles: keep all context in one wiki, make every change human-owned, do not let agents write memory automatically, and ensure tools and data access are controlled by user credentials. In his view, if you work backward from those rules, there is really only one logical structure for how the company brain, its permissions, and its tools should fit together.

Closing and invitation

Gopal closes by saying he would be happy to discuss the architecture further after the talk. He mentions PromptQL again, says they will be launching a new product, and invites people to follow up with him on Twitter and visit the company.

He ends on a lighter note, asking for a photo and telling the audience to stay tuned. He positions their approach as similar to the ideas he has just described: a way to work with company context and AI without being locked into a single cloud vendor, and with the flexibility to use different models as needed.

Fact-check

TRUE — The speaker is Tanmai Gopal, CEO and co-founder of PromptQL, and the talk is broadly about building a secure “company brain”/shared AI context for organizations.
PLAUSIBLE — A company-wide knowledge/agent system can leak sensitive information if access control and provenance are not carefully designed; this is a real and well-known security concern.
PLAUSIBLE — Modeling a company brain as interconnected Markdown/wiki pages with explicit access scopes is a reasonable architectural pattern, but it’s one design choice rather than a proven universal solution.
PLAUSIBLE — Requiring agents to suggest additions to memory/context for human review, rather than automatically writing them, is a sensible security measure; the evidence is mainly design logic and practice, not a formally established standard.
PLAUSIBLE — Using the user’s own credentials/claims to read data and invoke tools is a standard principle in secure system design; the exact implementation details here are not independently verifiable from the transcript.
UNVERIFIED — The claims about PromptQL being deployed at “big banks,” “Fortune 100” banks, Instacart, Apple, Meta, and JP Morgan are specific customer/usage assertions that I cannot confirm from the transcript alone.
UNVERIFIED — The speaker’s “about 15 to 20 people” partnership count and “past year” implementation history are self-reported metrics and timeline details that are not externally verifiable here.
UNVERIFIED — The example involving a security survey email from “Dave at Stitch Fix,” the system drafting answers, and the described workflow is presented as an anecdote/demo, not independently checkable.
MISLEADING — Statements like “there is only one possible and logical structure” for managing context/tools/security overstate a design opinion as if it were a universal fact; multiple architectures can satisfy secure access-control requirements.
MISLEADING — The transcript implies that letting agents automatically add memory is inherently wrong; in reality, automated memory can be useful if tightly governed, audited, and permissioned rather than categorically forbidden.
PLAUSIBLE — The general warning that shared AI in Slack-like environments creates higher security risk, especially around privilege escalation and production actions, is consistent with common security practice.
UNVERIFIED — The mention of a product launch “a few days ago” and references to specific “cloud”/“cloud code” competitors are recent and somewhat garbled, so the exact factual references are unclear from the transcript.

Verdict: The talk is broadly credible on the high-level security principles of building shared AI systems, but many concrete company/customer claims, implementation details, and success metrics are self-reported and remain unverified from the transcript alone.

Read original →

Agents' next frontier: agent-to-agent and network effects — Jean-Denis Greze, Town

Thu, 03 Sep 2026 22:00:25 +0000

Jean-Denis Greze of Town argues that agent-to-agent systems should be understood as search problems and says better context selection can create network effects when agents collaborate to complete tasks for users.

Narrative

Reframing agent-to-agent as search

Jean-Denis Greze, CTO at Town, begins by saying the talk is not really about Town itself, but about a broader shift in how AI systems work together. He frames the whole topic in terms of search: in most large language model, or LLM, systems, the real job is to make sure the context window—the information the model sees right before it answers or makes a tool call—contains the right data. If the context is right, the model can do its best work.

He traces how this has evolved: first humans manually filled the context window, then retrieval-augmented generation, or RAG, used search tools to pull in information, and now people are building “agentic search,” where the agent has many tools and searches through content to find the right context itself. In his view, the key is still the same: engineer the system so the one important LLM call has the best possible information.

The ideal of one agent with everything

From there, he asks what agent-to-agent really means. He invites the audience to imagine a world with just one agent that has access to all the world’s information: anyone’s email, any company’s data, any government’s records. In that perfect setup, the agent could always produce the best possible outcome. He argues that this is essentially a multi-agent world in its ideal form—one agent with universal access.

But that ideal collides with privacy and security. He brings in the Coase theorem from economics, which says that if everyone had the right information and there were no transaction costs, humans could reach economically optimal outcomes. The problem is that, in reality, we cannot let an LLM see everything. So the question becomes: how well can a system approximate that ideal without violating privacy boundaries?

Strategy one: shared access inside a trust boundary

The first approach he describes is simple: give an agent broad access within a trusted boundary. He uses a family example, where his wife and he share an agent that can access both of their email accounts. In a company, the same idea could apply to an HR team agent that has access to HR systems the way a member of that team would.

This works well because it matches familiar enterprise software models, especially for IT and security teams. But he sees a fundamental weakness: it does not reduce the number of humans involved, and it does not truly break down silos. It just creates a new silo around the person who now has to think through the data.

Strategy two: privacy-preserving tools with power trade-offs

The second strategy is more selective. Instead of opening full access, you build tools that make a specific trade-off between power and privacy. He gives an example: asking whether anyone in a company is connected to someone on the finance team at Acme Corp. Rather than give full Gmail access to the agent, you could build a tool that scans internal email and returns only a relationship strength score.

The agent would then use that score to find the right employee, contact them through Slack, and request an introduction. He says Town uses this kind of pattern for some features, asking what privacy-preserving tools users would tolerate because they create natural network effects by connecting people across silos. He also mentions another example: letting people draft emails in someone else’s inbox to save time on introductions.

Still, he says this approach is limited because it depends on humans designing the tools and explaining them to everyone. It is manual, and it does not naturally improve just because the models get better.

Strategy three: shared silos and automated knowledge bases

The third category is shared spaces where data accumulates over time. He likens this to personal wikis, but at the team or company level. Examples include shared skills in a codebase, or a wiki or Airtable-style system where people keep adding useful information. Agents can access these shared silos, so data that is appropriate to share no longer stays trapped in private systems.

He says an especially promising version is a “sweeper AI”: an AI inside each private silo that knows what must remain private, knows the shared spaces available, and at the end of the day moves acceptable new information into public spaces. The key challenge is deciding what can be shared. One option is to ask humans to approve the transfer. Another, which he thinks is coming quickly, is to let the LLM enforce a policy directly.

He predicts that within six months many companies will trust an LLM to surface more private information into shared spaces, especially in smaller, high-trust companies where the sensitive areas are clearer, such as finance and HR. He sees this as a way to improve the trajectory of common work.

Strategy four: humans as the conduit

The fourth approach is the most familiar: use humans as the bridge. In this model, my agent asks your agent, but the human owner sees and approves the request. Jean-Denis says this is traditional agent-to-agent interaction, with humans acting as the permission layer.

The drawback is scale. If a question requires input from only a few people, the request may get blasted to everyone. In his company-size example, a hundred-person company could end up with a hundred Slack pings asking whether anyone knows a contact at Acme Corp. That is workable, but inefficient.

Strategy five: the black-box approval model

He then describes what he sees as a more powerful version, even though he has not seen it widely in practice: the black-box approach. In this model, an LLM with full access to the relevant data determines the answer first, without exposing the trace to people along the way. Only after it identifies which specific information must be shared does it ask the relevant human for approval.

In his example, every agent in the company quietly checks whether its owner is connected to the Acme Corp CFO. The black-box system gathers the candidates, determines Bob has the strongest connection, and then asks Bob only whether Jean-Denis may be told that Bob knows the CFO. The trust requirement is high: the company must trust the system to avoid leaking information too early, but he says this can be acceptable in a corporate setting if the human-in-the-loop step is carefully designed.

He also points out a danger: even this model can surface sensitive information indirectly, such as revealing that someone is interviewing elsewhere by asking whether they know a recruiter at another company.

Risks, reliability, and the move toward auto mode

Jean-Denis says he thinks the shared-wiki approach is likely to deliver the quickest return on investment, especially in open-source-style environments and smaller companies. But he also lists the risks. Prompt injection can contaminate a silo if bad content gets pulled into the search process. Shared wikis can go off the rails if an LLM makes one mistake that then gets reused forever. He gives a personal example: his memory system still thinks his agent’s name is Apex, even though he renamed it to Ivy a month ago.

He warns that without human review, false disclosures are inevitable, and those can range from harmless to career-ending or legally damaging. He also notes that black-box systems cannot truly remain black boxes forever; eventually someone in a security or compliance role will want to audit what is happening.

Still, he argues that the direction is clear. Just as coding tools moved from approval mode to “YOLO” and then to auto mode, agent-to-agent systems across information silos will likely move the same way. He expects low-sensitivity data to be shared automatically first, then more and more decisions to be delegated to the model as policies improve and models become more capable. The winning strategy, he says, is to define a low-sensitivity zone where the LLM is allowed to decide, then let that zone expand over time.

The network-effects frontier

In closing, he returns to the network-effects idea. He says the really interesting frontier is not just within one company, but across companies. If multiple organizations could agree to let a common agent work across their information silos, that could unlock something much larger.

He mentions an example from the finance world, where investment banks may benefit from sharing private data about private companies for lending decisions. In that setting, companies are beginning to trust one another’s agents to operate across what used to be separate private systems, with agents deciding what can be accessed. He sees that as a powerful beachhead for the future.

Jean-Denis ends on a note of cautious optimism. He is not sure he personally trusts a future where agents make all privacy decisions, but he believes that is the direction the technology is heading.

Fact-check

TRUE — Jean-Denis Greze is a CTO at Town, and the talk says he previously worked at Plaid and Dropbox; this is a straightforward biographical claim and fits well-established public career patterns, though I cannot verify the exact sequence here in real time.
PLAUSIBLE — The framing that many LLM applications can be understood as a “search problem” where the key task is putting the right information into context before generation/tool use is a reasonable engineering perspective, but it is a simplification rather than a settled fact.
PLAUSIBLE — The claim that “agent-to-agent” systems can create network effects by enabling agents to work across information boundaries is conceptually sound, but it is more an argument/opinion than a directly checkable fact.
TRUE — Privacy and security constraints do prevent a single system from simply having unrestricted access to all personal, corporate, or government information, so the “one agent with all the world’s data” ideal is not practically realizable.
PLAUSIBLE — Using role- or trust-boundary-limited access for internal agents (for example, HR or IT agents with scoped permissions) is a standard and sensible pattern, but the speaker’s broader claim that it is the main current approach is not something I can confirm precisely.
MISLEADING — The assertion that trust-boundary approaches “don’t get better as models get better” is too absolute; while access-control design still matters, better models can improve retrieval, classification, routing, and policy enforcement within such systems.
PLAUSIBLE — The idea of privacy-preserving tools that return only aggregate scores or limited relationship signals is technically reasonable and aligns with common privacy-design patterns, but the specific usefulness and adoption described are unverified.
PLAUSIBLE — Shared workspaces such as wikis, repositories, or databases can act as “shared silos” that improve collective access to information, but the claim that they naturally de-silo data over time depends heavily on incentives and governance.
PLAUSIBLE — A “sweeper AI” that periodically moves allowed information from private silos into shared spaces is a plausible design pattern, but the effectiveness of LLM-enforced sharing policies remains uncertain and context-dependent.
MISLEADING — Saying that companies will broadly trust an LLM to enforce sharing policy “in the next 6 months” is an unsupported timeline claim; adoption will likely be uneven and slower in many organizations, especially where compliance risk is high.
PLAUSIBLE — Human-in-the-loop agent-to-agent requests can work, but the criticism that they may spam many users when the answer is rare or distributed is a reasonable trade-off observation, not a hard fact.
PLAUSIBLE — A “black box” approach that consults private silos automatically and only asks humans for approval at the final sharing step is technically plausible, but it raises serious auditability, governance, and leakage risks.
PLAUSIBLE — The examples of prompt injection, poisoned shared memory/wikis, and false disclosures are real classes of failure for LLM systems; these risks are well-recognized, though the exact frequency and severity vary widely.
PLAUSIBLE — The prediction that “auto mode” for cross-silo agent workflows will expand from low-sensitivity cases to broader ones as models and policy enforcement improve is plausible as a trend, but it is speculative.
UNVERIFIED — The specific anecdote that the speaker’s personal wiki still thinks the agent’s name is “Apex” after he renamed it to “Ivy” is self-reported and not independently checkable.
UNVERIFIED — The claim that some companies are already exploring or using agents to let investment banks share private data across firms is niche and company-specific; it may be true, but it cannot be confirmed from general knowledge alone.
PLAUSIBLE — The broader prediction that cross-company agent-to-agent workflows could create significant value is reasonable, but the wealthiest-winner implication is speculative and not verifiable. Verdict: The talk is broadly credible as an informed product/strategy discussion with several plausible system-design ideas, but it mixes solid general observations with speculative timelines, self-reported anecdotes, and unverified claims about current adoption and future behavior.

Read original →

Tethered: Our Agents Are Us — Shu Fang, Two Sigma

Thu, 03 Sep 2026 21:30:21 +0000

Shu Fang of Two Sigma describes how the firm has deployed cloud agents that operate under their own identities, and uses a horror-movie metaphor to discuss the risks and controls involved in this setup.

Narrative

Setting up the idea of “tethered” agents

Shu Fang from Two Sigma opens with a quick introduction to the company and a playful explanation of its name, then immediately shifts into a legal disclaimer: the views are his, not necessarily the company’s, and he is not endorsing any other firms or products. From there, he frames the talk around a simple but provocative premise: the company has built a cloud-agent system in which agents run under each user’s own identity.

To make that idea stick, he invokes the movie Us. In the film, people have doubles called “tethered,” and when those doubles break loose and cause chaos, they become “untethered.” That becomes the metaphor for the talk: agents should not be loose, anonymous entities. They should be tied to a real user in a controlled way.

Why run agents as the user?

He explains that around June 2025, as cloud code and similar tools became more widely used, many agents were still designed to run locally on a user’s machine. That setup worked, but it was limited to the command line interface, or CLI, and it kept the agent on the local device. Two Sigma wanted something broader: agents that could be accessed from mobile, Slack, browsers, and other interfaces, while still running remotely.

The obvious alternative—running an agent as a separate machine identity tied to the user—quickly breaks down, he says. Permissions drift out of sync, licensing becomes harder, some systems do not support multiple identities over the same data, and the boundaries between public and private information get messy. So the team asked a simpler question: why not run the agent as the user directly?

The existing infrastructure: namespaces and remote compute

Fang says Two Sigma already had much of the needed infrastructure because the firm had long used remote compute for automation, research notebooks, code containers, and similar workloads. In that setup, every user already had namespaces in Kubernetes clusters across regions, and everything inside those namespaces ran as that user.

He sketches the mechanism at a high level: a controller requests compute, and a sidecar container pulls identity information from a separate service so the actual workload can mount the user’s identity and run as that person. That same pattern, he argues, can support agents just as well as automated jobs.

The first big risk: who did what?

The biggest internal risk is attribution. If the user and the agent share the same identity, how can the company tell whether a human or an agent took a particular action? Fang jokes that his mustache is there to distinguish him from his agent, but the real need is serious: the firm needs to audit actions, block dangerous behavior, and trace events back to their source.

This is especially important because the company wants to know whether something was done by the human or by the agent acting on the human’s behalf. Without that distinction, the system would be too opaque to trust.

The second big risk: web access and exfiltration

A larger concern is web access. Fang says modern LLM systems need internet access because their models are static and cannot update themselves with current information. Search, fetch, and web tools are therefore core capabilities. But once agents can reach the open web, they also become vulnerable to exfiltration, prompt injection, malware, and accidental use of unlicensed content.

He presents this as the central fear: an agent that can browse freely could leak intellectual property or ingest malicious content. In a regulated finance environment, that risk has to be controlled tightly.

Balancing risk and return

Fang frames the whole problem as a finance-style tradeoff. There is real return in letting agents operate as users, but there is also substantial risk. The goal, he says, is to maximize return while reducing risk, much like optimizing a Sharpe ratio, which measures return relative to risk.

That leads to the two technical goals of the system: first, preserve attribution so actions can be traced to the human or the agent; second, provide safe web access so agents can still use the internet without exposing the firm to unnecessary risk.

Solving attribution with headers and trace IDs

The attribution solution is to use a header that every agent appends to as it moves through systems. Fang compares this to trace IDs in observability systems, where a single identifier is propagated through disparate services so engineers can reconstruct what happened.

Here, the same principle applies to agent workflows. By forcing that header to persist through the entire chain, the company can replay the sequence of actions that led to an outcome. That gives better provenance than simply knowing that a particular “shoe agent” or user-triggered process was involved at the start. The actor remains the user, but the path through the system becomes visible.

Solving web access with Google’s enterprise index

For safe web access, Fang says the team looked for a way to use search and fetch without letting agents make uncontrolled requests to the public internet. Their answer was Google’s enterprise web grounding offering, which provides access to Google’s web index within the firm’s VPC and network controls. He describes it as offering the same core capabilities they need—search and fetch—while keeping traffic inside the boundary.

The tradeoff is freshness. The index is not fully real time; Fang says it is generally fresh within 24 hours, and for some regularly updated sites within 6 hours. But for most agent use cases, he argues, that is good enough, and it removes the external egress risk.

Forcing agents through the safe path

The second part of the web-access fix is enforcement. Fang says the agent tools for direct web search and fetch are simply denied. Instead of letting the agent use those native tools, the system redirects requests through supported paths such as MCP CLI, client code, or similar harnesses so that all web access goes through the grounded index.

This way, the agent still gets the information it needs, but only through the controlled enterprise path. The point is not to eliminate web use; it is to make web use safe and auditable.

What the company shipped

Fang ends the technical portion by summarizing the result: a framework that lets cloud agents run as user identities in a remote environment, with guardrails for attribution and web access. He says the company can deploy a managed fleet of cloud agents for each user, and people who are uncomfortable with CLIs can still interact with agents through other interfaces.

He emphasizes that this is not just experimental. The system was shipped, and employees can already deploy agents in the cloud under their own identities.

Questions, caveats, and closing remarks

During the Q&A, Fang is asked about local LLMs for enterprise use. He says that personally—and not on behalf of the company—he thinks locally managed models may be the eventual direction for much of their token use and inference, for reasons including cost and the volatility of frontier models.

He is also asked about spoofing the header, and he explains that the header alone is not the identity. Someone could populate a header, but that would not let them mimic the underlying user identity, which is still established through the identity system and the chain of RPC entry points. Another question asks how Google’s index helps with prompt injection. Fang answers that the index is internal, cached, and curated for regulated industries, so the risk is reduced because the agent is not freely browsing arbitrary external content.

In one final exchange, he explains that behavioral data and session data help the firm configure agents in a way that improves the user experience while keeping sensitive activity localized. When asked how individuals or teams can create agents across the company, he says the infrastructure is already provisioned for every user. Developers can build agents using existing frameworks, deploy them into their namespace, and then move them through the normal production and security review process if they are meant for broader company use.

He closes by inviting people to talk afterward and noting that the company is hiring.

Fact-check

MISLEADING — The title framing and analogy (“tethered/untethered” agents) are rhetorical, not factual; the substantive claims are about enterprise agent identity, access control, and web-access architecture.
UNVERIFIED — “Two Sigma is 25 years old” is a specific company-age claim that may be roughly right but is not something I can confirm here.
UNVERIFIED — The claim that, “back in June 2025,” cloud-code-style agents became widely used on local machines and that this talk describes what Two Sigma “shipped last year” is time-specific and not independently verifiable from my training knowledge.
PLAUSIBLE — Running agents under the same user identity as the human, rather than as a separate machine account, would indeed simplify authorization and reduce permission-sync problems, but it also creates real audit and abuse risks.
TRUE — The speaker is right that shared-identity automation creates attribution/audit challenges: if human and agent actions use the same principal, you need extra logging to tell who did what.
TRUE — Open web access for LLM/agent systems materially increases exposure to prompt injection, data exfiltration, and malware/supply-chain style risks; that’s a well-established security concern.
PLAUSIBLE — Using a trace-ID-like header or similar propagation mechanism to attribute agent actions and reconstruct the action chain is a standard and sensible observability pattern, though the exact implementation details are unverified.
UNVERIFIED — The claim that their system can “replay the entire chain of actions” and preserve full provenance across multi-step agent workflows is a specific product/implementation claim I cannot verify.
PLAUSIBLE — Providing agents with web access through an internal, curated, enterprise-controlled search/fetch layer is a reasonable mitigation strategy for reducing direct internet egress and some security risk.
MISLEADING — Saying a cached enterprise index “completely removes” the external egress vulnerability vector overstates the protection; internal retrieval reduces exposure but does not eliminate prompt injection, content poisoning, or broader security risks.
UNVERIFIED — The freshness numbers (“within 24 hours” and “within 6 hours”) for the claimed enterprise web index are specific vendor/implementation details that I cannot confirm.
PLAUSIBLE — Blocking direct web-search/web-fetch tools and forcing access through approved paths is a standard defense-in-depth approach, though it is not a complete defense by itself.
PLAUSIBLE — The talk’s risk/return framing for deciding whether to deploy agents as users is reasonable as an internal business analogy, but it is not a scientific claim.
UNVERIFIED — The claim that “everything I talked about actually happened last year” is a self-reported project timeline and remains unverified.
PLAUSIBLE — The view that local/self-managed models may be attractive for enterprise use because of cost, control, and model-availability volatility is reasonable and commonly argued.
MISLEADING — The suggestion that enterprise-curated internal web grounding substantially reduces prompt injection risk is directionally true, but prompt injection is not solved just because content stays internal; curated sources can still contain malicious or misleading instructions.
UNVERIFIED — Claims that every user at the firm already has the necessary infrastructure, can deploy cloud agents “in their namespace running as their identity,” and that the company “shipped” this framework are all organization-specific operational claims I cannot verify.

Verdict: The talk is broadly credible on general enterprise AI/security principles, but many of the concrete implementation, product, and timeline claims are self-reported and remain unverified, and a few security benefits are overstated beyond what the evidence would support.

Read original →

Everyone Gets A Software Company — Benjamin Guo, Zo Computer

Thu, 03 Sep 2026 21:00:06 +0000

Benjamin Guo of Zo Computer presents a vision of personal cloud computers and agents, saying that people will increasingly have software environments and assistants tailored to their own needs.

Narrative

A computer you can live in

Ben opens by introducing himself as being from Zo Computer and immediately treating Zo as more than a product: it is “my computer.” He says he even built a site just before the talk—a page with an overview of the other speakers, useful links, and deeper research into their recent thoughts and profiles—which he invites people to scan with a QR code.

From there, he frames the talk as both a tour of Zo and a broader argument about personal agents, especially personal cloud agents, and where he thinks the future is headed.

A human-and-machine ideal

He gives a quick background on himself: co-founder of Zo, former early employee at Venmo, later at Stripe, and co-founder Rob later went on to build Substack. He then lingers on a small design detail: the old Finder icon, which he says Susan Kare designed to represent a human and a machine in harmony. For Ben, that image captures the goal of AI tools—people should feel at one with their machines, not dominated by them.

He asks who misses the way computers used to feel, when the early internet and first personal computers felt exciting and alive. In contrast, he says today’s digital world feels like a messy sea of apps, sites, and services, increasingly expensive and often bundled with AI features people never asked for.

From software sprawl to techno-feudalism

Ben argues that the problem is deeper than bad product design. He calls it “techno-feudalism,” borrowing feudal language to describe a digital economy where users rent access to SaaS providers, who in turn depend on cloud providers and ultimately on the dominant hardware and infrastructure companies. In this model, users are “peasants”: they are fragmented across tools, locked into systems, and asked to pay for products that monetize attention and data while becoming worse over time.

Zo, he says, exists to challenge that structure by giving people a real home on the internet. The goal is to help ordinary people escape what he describes as a Matrix-like situation and regain ownership of their digital lives.

What Zo is for ordinary people

Ben points to real users to show what Zo does in practice. One example is Charlotte, a private chef and life coach in Los Angeles, who uses Zo to host multiple websites and manage invoices, bookkeeping, scheduling, and notes. He says Zo helps her feel clear, calm, and in control.

He defines Zo as a personal cloud: a home in the cloud that belongs to you. Instead of relying on a pile of separate cloud services, you store your data, AI, and hosted services in one place that you own. For more technical users, he says a personal cloud can span local devices too—his own setup includes a Zo computer, a cloud computer, a Hermes instance, websites, APIs, a laptop, a Mac mini, and a phone. Together, that is his personal cloud.

A simpler model for building and hosting

Zo, he explains, is also a personal server with AI built in. He ties this back to an older, simpler way of publishing websites: uploading files to a server with FTP and pushing changes live. In his view, most people should not have to think about deployment or infrastructure. Zo is meant to make that complexity disappear by putting everything—your data, your AI, and whatever you host—into one place.

He contrasts that simplicity with the confusing reality many people face now: switching between multiple AIs, devices, and SaaS tools. Zo is designed to replace that sprawl with a single home base.

A nontechnical user replaces her stack

To show that the product is not only for technical people, Ben tells the story of Anthea, an early user who is a free-diving instructor and not technical at all. She had been running her life and business across services like Squarespace and Calendly, but replaced those subscriptions with Zo. He says she canceled those tools, stopped being a “peasant,” and moved her whole operation into one place.

Anthea now hosts retreat websites on custom domains, keeps a personal workspace, and expresses herself online through fairies, mushrooms, and drawings. Ben says this is more than just a website builder: it is a way for regular people to express their whole selves online again, something he feels has been missing since the 1990s.

The business behind the website

Ben then explains that the public-facing site is only the surface. When someone shows interest in one of Anthea’s retreats, Zo texts her the person’s number so she can call at the moment of intent. She can ask Zo for a payment link and close the deal right away. He says this has helped her book more revenue than before, to the point that her retreats are now almost too popular.

Behind the scenes, Zo handles her retreat database, notes, accounting, and media. She can upload images from a retreat and have Zo place them on the site, and she is self-hosting everything from one personal server.

Built for everyone, powerful enough for builders

Ben emphasizes that Zo has to be simple enough for people like Anthea, his parents, or anyone else who is not technical. He says people keep telling him on LinkedIn and X that their parents are using Zo and “coding up a storm,” and he shares examples of a caterer, a recruiter, and a marketing agency all adopting it in different ways.

At the same time, Zo is meant to be powerful enough for the people in the room. It can host personal agents like Open Claude or Hermes, support tools such as Codex or Gemini, and provide a properly configured Linux virtual machine with root access. Users can SSH in, control Zo through an API or MCP, and build almost anything they want.

A quick demo of the product

Ben moves into a demo, again showing the cloud workspace he calls Zo. He says he made the showcased website just then and can build sites on the fly. The platform supports chatting with many models, including one’s own API keys, and even Claude Code.

He walks through the file system and cloud storage, describing Zo as a kind of Dropbox you own yourself. He mentions automation features that can run AI tasks on a schedule, a large library of built-in integrations and skills, and a built-in browser that can log into sites and let Zo buy things or perform other actions. He admits that using Zo to buy items on Amazon is “dangerous for impulse purchasing.”

Zo can also host arbitrary services over HTTP or TCP, and it includes a personal website space with live-coding-style editing. Ben shows his own Zo space, which he uses for things like a Calendly replacement that lets people book time with him only after Zo reviews them. He makes clear that he prefers this controlled setup to letting people book directly.

A future of owned intelligence

Ben closes by widening the lens again. The reason they are building Zo, he says, is to create a better internet in which every person has a real presence online, not just companies. He imagines a world where people interact directly with each other and with company AIs, without middlemen.

He argues that in the near future, most interactions will be with agents, and many of those agents will live in the cloud. That raises the crucial question: whose cloud are they in? He points to Claude Team as an example of a cloud agent—a company-level Claude that anyone in the organization can use—but says the benefit mostly accrues to Anthropic, not the customer. In his view, that is “intelligence feudalism,” where intelligence flows upward to the platform instead of being owned by the user or company.

Zo’s aim, he says, is to change that by letting individuals and companies publish and own their own agents, and let those agents improve through real usage. He says there is already a beta version of this agent-publishing idea, and he ends by inviting people to scan the QR code to talk to him, get AI credits, or sign up. He also reminds people that the speaker overview page is available on his Zo space, then thanks the audience.

Fact-check

TRUE — The speaker’s broad framing of the video is clear: Zo Computer is presented as a personal cloud/personal server product with AI built in, aimed at hosting files, websites, automations, and agents in one place.
UNVERIFIED — “Ben/Benjamin Guo” says he co-founded Zo, worked on the early Venmo team, was the 80th engineer at Stripe, and that his co-founder Rob later became Substack’s first engineer; these are specific biographical claims I can’t confirm here.
PLAUSIBLE — The claim that traditional SaaS and cloud products can create lock-in, fragmented workflows, and rising costs is broadly consistent with common user experiences and industry incentives, though it’s framed rhetorically and somewhat one-sided.
MISLEADING — Calling this “techno-feudalism” and implying users are literally “peasants” is an analogy, not a factual description; it simplifies complex market dynamics and overstates the precision of the metaphor.
UNVERIFIED — Claims that Zo has been “out for about a year,” has real users, and that specific named users like Charlotte or Anthea are using it successfully are self-reported product and testimonial claims that I can’t independently verify.
UNVERIFIED — The examples about Anthea replacing multiple SaaS tools, increasing bookings, and being “on track to make $100,000 on Zo” are anecdotal business-performance claims from the speaker’s product story, not independently checked evidence.
PLAUSIBLE — A personal cloud/server could reasonably host websites, files, APIs, and automations, and could be integrated with a browser, scheduling, and AI tools; that’s technically feasible even if the exact implementation here is unverified.
UNVERIFIED — The demo claims about Zo’s features—built-in browser, skill library, “host anything” over HTTP/TCP, API/MCP control, and integrated model access—are product-specific capabilities that may be real but are not verifiable from the transcript alone.
MISLEADING — “You can just tell your Zo to buy things on Amazon” suggests a level of reliability and safety that is not guaranteed; agentic purchasing can work in principle, but it carries obvious error, security, and user-consent risks.
PLAUSIBLE — The idea that many future AI interactions will happen through agents, with some agents running in the cloud, is a reasonable forecast and aligns with current industry direction, but it remains speculative.
MISLEADING — The discussion of “claud/Claude” as a company-level cloud agent and the claim that improvements mainly benefit Anthropic is a rhetorical argument about ownership and value capture, not a settled factual conclusion.
UNVERIFIED — The “beta version” of an agent publishing platform, the QR-code signups, and the giveaway of $100 in AI credits are time-sensitive promotional claims that cannot be confirmed from the transcript alone. Verdict: The video is credible as a product pitch and vision statement, but many of its strongest claims are promotional, anecdotal, or self-reported rather than independently verifiable, especially the user success stories, product capabilities, and recent beta/status details.

Read original →

Beyond the Lethal Trifecta: Agentic Commerce on the Open Internet — David Levine, Kiduna Club

Wed, 02 Sep 2026 03:30:27 +0000

David Levine of Kiduna Club argues that agentic commerce on the open internet is blocked by the “lethal trifecta” and says new forms of composability are needed to make an agentic economy work.

Narrative

Opening the case for agentic commerce

David Levine opens by framing the talk as the final session of the conference and promising to keep the energy up. He says the goal is to explain the “lethal trifecta” and, more importantly, how to get past it, because that trifecta is what keeps true agentic commerce from existing on the open internet.

He then jumps back to November 1993, recalling how a scrap of paper with a MOO address led him into an early online world. After buying a 9600-baud modem and connecting, he says his old life ended. That world felt alive because it had real community and, more importantly, composability: everything was built from nouns and verbs that could combine into new forms. A scooter could become a motorcycle, player classes could morph, and all of it worked because the whole universe shared a coherent design.

What made the early internet feel alive

Levine says that old MOO was powered by four things working together: governance, technology, economics, and culture. Governance included architectural review boards and “wizards”; the technology was simple and contained in one system; the economics were funded by Xerox PARC; and culture, he argues, was the most important ingredient of all.

From there, he contrasts that early era with what happened from 1995 to 2025. In his telling, communities that people once loved were crushed by platforms and algorithms. Those systems are extractive by nature, he says: they pull value out of communities, optimize for engagement, and replace genuine connection with things like infinite scroll. The result is not an economy of the internet, but a set of siloed platforms.

Agents arrive, and so does the problem

Levine says that in January 2026, Open Cloud suddenly took off, and then something strange happened: the internet was not built for all these agents running around. It had been designed for closed platforms, and that mismatch created a new vulnerability. Other agents and attackers exploited it with prompt injections, which he describes as a way of tricking a naive agent by feeding it convincing instructions through the prompts it reads.

He explains the “lethal trifecta” as the dangerous combination of three things: access to private data, exposure to untrusted content on the internet, and the ability to take actions. If an agent can read your email, browse unreliable websites, and then act on what it sees, it can be manipulated into leaking secrets or doing harm. In his view, the problem is fundamental.

Why enterprises kept the agents inside

Faced with that risk, Levine says enterprises responded by keeping their agents inside the company. They built agents for Slack, Salesforce, Notion, and other internal systems, then tried to connect them with APIs and MCP servers. But that approach, he says, loses context and creates a lot of integration work. Sales agents, finance agents, and research agents remain fragmented, and the system is difficult to unify.

He says this was a problem “literally until today,” and then points to a breakthrough: a new law in West Virginia that, in his telling, gives legal standing to an organization composed of intelligent agents. He says he received confirmation from the Secretary of State that a DUNA had been registered, and he treats that as a historic moment.

DUNAs and the legal shape of agent organizations

Levine defines a DUNA as a “decentralized unincorporated nonprofit association,” which he presents as a true internet-native, agentic organization. These organizations, he says, are composable, permissionless, accountable, safe, and secure. They do not need a board of directors, executives, or a corporate shell. They can be profitable, but they cannot distribute profits to members, because that would turn membership units into securities.

What they can do is substantial: they can be member-governed, hold legal standing, own property, enter agreements, raise capital, open bank accounts, hire and fire people, and do it all in a blockchain-verified way. Levine argues that this structure, originally designed for blockchain use, is even better for autonomous agents because it solves the problem of agent identity. If an agent is tied to a blockchain account, its actions can be traced, responsibility can be assigned, and a court can follow the chain back to whoever is accountable.

Allies, Kidunas, and building software as an organization

Levine then introduces the simpler vocabulary he wants people to use in the agentic economy. Agents are “allies,” and the agentic organization is a “kiduna,” built on the DUNA idea with an added sense of kinship.

He describes how to create an ally in stages. First, you “inform” it by putting material into a vector database, so it has the relevant knowledge. Then you “instruct” it by setting the system prompt and its character or stance. Next, you “empower” it by connecting accounts like Slack, Telegram, and Twitter. Then you “enact” it by giving it specific abilities and automations for long-term work. Finally, you align it by giving it purpose so it behaves the way you want across different contexts.

At the organization level, Levine says the important shift is that you are building the company itself as software. Instead of separate software and people with paperwork in between, the whole organization can be designed as a programmable system that discovers customers, shares value, and reinvests revenue.

Resolving the lethal trifecta with identity and tokens

To solve the lethal trifecta, Levine says agents need identity, authority, and boundaries at both the internal and inter-organizational level. He says this is handled with cryptographic tokens, specifically JWTs, which he describes as the basic machinery the web already uses. These tokens let an organization resolve who a given agent is and where it belongs.

He compares this to the domain name system: just as DNS maps names to destinations, these registrations map organizations and agents to an authority. He gives examples like Kaiser Permanente, Disney, or Pepsi, contrasting them with an untrusted actor. The point, he says, is that agents cannot simply fake their way past these registered identities, because the system can trace them back through an audit trail on the blockchain.

Governance by decision markets

Levine emphasizes that governance matters deeply in the agentic economy because every organization has to balance sustainability with mission. As organizations grow to hundreds, thousands, or eventually millions of people, they need a better way to decide.

His answer is decision markets, which he compares to prediction markets like Polymarket. Instead of ordinary voting, members trade pass and fail tokens on policy proposals. He says this works especially well for LLMs, which are goal-oriented and reward-driven. Rather than merely convincing one another, participants have an incentive to back the winning side, and the token value reflects that. Levine argues that this produces better decisions and lets an organization encode its values, experiences, and aspirations into the way it reasons.

A call to build the new economy

He closes by returning to the theme of small communities organizing around shared purposes. The agentic economy, he says, can now be built together, and nobody gets to dictate the exact form it should take. The invitation is to build the agents and build the organizations.

Levine offers contact details, including david@kaduna.club and LinkedIn at {/slash} motodave, and says people can sign up for early access at kaduna.club. He explains that the first Kaduna is for builders, with templates for sales agents, social media agents, lawyer agents, and more. He wants many kinds of people contributing so they can spin out their own organizations for different purposes.

Questions and practical framing

In the Q&A, Levine explains that the first broad organization exists so anyone can register under it and have their agent trace back to a shared umbrella. He compares the moment to the early days of email and the web, when people used different systems until common standards like SMTP and HTTP emerged. His hope is that the secretary of state can serve as a public registry with standing, rather than leaving the ecosystem fragmented across companies.

He also says that different tokens can be created for different purposes, with different lifetimes and access scopes. The point is to establish claims and validate them before two parties start working together. After thanking the audience and taking a group picture, he ends on a celebratory note, suggesting that everyone present is witnessing the start of something historic.

Fact-check

PLAUSIBLE — The “lethal trifecta” framing is broadly consistent with known AI security concerns: combining access to private data, exposure to untrusted content, and the ability to take actions can create prompt-injection and data-exfiltration risk.
TRUE — Prompt injection is a real and well-known failure mode for LLM-based agents that consume untrusted text and can be induced to follow malicious instructions.
TRUE — Early internet communities often felt more participatory and composable than today’s platform ecosystems; this is a reasonable cultural/historical characterization, though it’s somewhat subjective.
MISLEADING — Saying platforms and algorithms are “by their very nature extractive” overstates the case; platforms can be exploitative, but the claim is too absolute and not universally true.
UNVERIFIED — The specific story about “Open Cloud” blowing up in January 2026 is a recent, niche, time-specific claim I cannot confirm.
TRUE — The internet was not originally designed with modern autonomous agents in mind; existing web/app security models were built for humans and conventional software, not highly autonomous LLM agents.
MISLEADING — The claim that “there’s really no way to solve this” lethal-trifecta problem is too strong; mitigations exist, though none are perfect.
PLAUSIBLE — Keeping agents within enterprise tools and integrating via APIs/MCP can reduce context and create engineering overhead; that’s a reasonable practical observation.
UNVERIFIED — The claim that a new West Virginia law “went into effect yesterday” enabling this structure is a very specific legal/event claim and cannot be confirmed from my knowledge.
UNVERIFIED — The speaker’s assertion that a DUNA was registered with the West Virginia Secretary of State and received organization number 628407 is a self-reported administrative detail.
TRUE — “DUNA” does stand for decentralized unincorporated nonprofit association, a real legal form in some jurisdictions.
PLAUSIBLE — A DUNA-like structure can be useful for organizing shared activities without conventional corporate ownership, but the exact suitability for autonomous agents is speculative.
TRUE — Nonprofit associations generally cannot distribute profits to members as ownership returns in the way corporations or LLCs can; that distinction is real.
MISLEADING — “Full legal standing,” “safe and secure,” and similar broad claims about DUNAs/agent organizations are overstated; legal standing and security depend on the actual jurisdiction, governance, and implementation.
FALSE — Claiming the system is “all blockchain verified” as a general solution to identity, authority, and accountability is not established; blockchains can record events, but they do not by themselves solve identity, trust, or legal responsibility.
UNVERIFIED — The attribution that this was “designed by Andreessen Horowitz for the blockchain” is a specific provenance claim I cannot verify and may be inaccurate or oversimplified.
MISLEADING — “You can’t trick the blockchain” is too absolute; blockchains can be used reliably for certain records, but surrounding systems, identities, and contracts can still be fooled or misused.
PLAUSIBLE — Organizing agents as software and using defined roles/policies to coordinate them is conceptually reasonable and aligns with current agent-platform thinking, though the implementation is not proven.
PLAUSIBLE — The idea of using decision markets/prediction-market-like mechanisms for policy selection has a real theoretical and experimental basis, but claims that they “reach much better decisions” are not universally established.
MISLEADING — Presenting pass/fail token markets as clearly superior to voting for organizational governance overstates the evidence; such mechanisms have interesting properties but are not proven generally better.
UNVERIFIED — The claim that this specific product/service will be available “in just a few weeks” and that attendees will be the first builders is a launch-timing claim that cannot be checked here.

Verdict: The talk mixes some real AI-security ideas and a plausible legal/business concept with a lot of speculative, promotional, and self-reported claims; the core “lethal trifecta” warning is credible, but the DUNA/kiduna rollout details, legal timing, and many sweeping claims about blockchain and governance remain unverified or overstated.

Read original →

The End of the Static Screen: Architecting Intent-Driven UX — Gus Iwanaga, commercetools

Wed, 02 Sep 2026 03:00:01 +0000

Gus Iwanaga of commercetools says generative UX and intent-driven interfaces require a new design mindset, and focuses on lessons from building products rather than on orchestration jargon.

Narrative

From static screens to intent-driven UX

The speaker opens by joking about the fatigue of the conference’s familiar AI themes, then immediately reframes the talk. He says he wants to focus not on agentic orchestration itself, but on lessons learned from building “proper generative UX and UI” and on a mental model that can help people think differently about software experiences.

He introduces himself as Gus, a general manager at commercetools who leads product, UX, and engineering for zero-to-one products. He outlines the structure of the talk: first, the problem space; then a product demo; then a discussion of UI protocols; and finally the challenges his team faced and the ways they worked around them.

Why software still feels static

Gus argues that, for decades, people have adapted to software instead of software adapting to them. He says GPT’s arrival in November 2022 gave everyone a glimpse of true personalization, but most experiences remained static even as AI sped up development. The core question, for him, is why software still looks and feels so fixed.

He describes the burden this creates for users who rely on multiple SaaS applications every day. Each app has its own mental model, its own navigation, and its own way of doing things, so the cognitive load that should have been transferred to the machine stays with the person. In his view, AI makes it possible to shift that burden differently.

The cost of complexity

To make the point concrete, Gus shows examples of dense, overloaded interfaces and says they are hard to start with even when you know the products. He emphasizes that these applications are the result of a huge amount of work by many teams, but that the complexity accumulates over time. The trade-off has been extensive onboarding, because newcomers need a lot of help just to learn how to use each tool.

His larger argument is that this is the history of software so far: many apps, each with different logic, all demanding separate learning. As the number of tools grows, the average user is forced to keep juggling different navigational models and workflows.

The question that led to the product

Gus says that last August he and the company founder asked a new question from the lens of artificial intelligence: what foundational shifts could happen if people could change radically the way they interact with software? He notes that commercetools is API-first and has more than 300 APIs, and that this question led to the product he is about to demo.

He then pivots into a quick demonstration, saying that a picture is more tangible than abstract explanation. The demo becomes a way to show how the product generates interfaces from user intent rather than from a fixed, static screen.

Early experiments that felt wrong

In the first part of the demo, Gus enters a query to create a sales report for Q1. He explains that everything on the right side is auto-generated, with the system deciding placement, information architecture, and which components to retrieve from the catalog. But he is blunt: he does not like the result.

He walks through several early variations and keeps finding them confusing. The system keeps changing the meaning of “Q1,” sometimes turning it into January to March, sometimes adding too many KPI cards or charts, sometimes producing layouts that feel inconsistent from one turn to the next. His conclusion is simple: he would not ship that to production.

A more mature orchestrated experience

Gus then shows the current state of the product, which he describes as much more sophisticated. This time, he enters a query about planning a campaign and explains what happens behind the scenes. An orchestrator extracts the user’s intent, locates relevant tools—first-party or third-party—and combines their outputs with context, including agents on MCP servers, to give what he calls enough “ammunition” for a UX agent to render something meaningful.

This newer result feels better to him. He stresses again that AI is guiding the placement and composition, but that the team is still shaping the experience. The system is already live in pre-production, and he uses that as proof that the approach is not just theoretical.

Three ways to render UI with agents

From there, Gus shifts to the different ways UI can be rendered through protocols, depending on how much control the team wants over the experience. He begins with the most controlled approach: the component is shipped as-is, and the agent merely selects and displays it exactly as designed. He says this works well in some businesses, especially when the company wants strong control over the output.

At the other extreme is fully open-ended generation, where the LLM composes the entire experience itself. Gus gives the example of Claude creating an org chart from a simple prompt. It works, but he says he would be reluctant to delegate that much autonomy in a company setting, because the output and outcome would be too hard to control. His UX instincts push him toward maintaining judgment and design authority.

The declarative middle ground

The approach Gus prefers is declarative, which sits between rigid control and total freedom. He says this is the model his team chose. In this setup, the orchestrator classifies intent, invokes tools, retrieves data, maps eligible components from the catalog to the tool outputs, and then broadcasts a UI description—a kind of UI spec. A schema, using Zod for validation, keeps the output compliant, and the final rendering becomes native UI, in their case React components.

He notes that this declarative approach keeps the experience aligned with the design system while still allowing some flexibility. It also avoids one of the problems he saw in the early demos: copy and structure drifting in ways that made the interface feel inconsistent. The system is less deterministic, but not completely uncontrolled.

Challenge one: who arranges the pieces?

Gus then turns to the practical challenges. The first one is information architecture: if the agent picks the components, who decides how they are arranged? He says that placement matters a great deal, because random layout would quickly create confusion for users.

To solve that, his team borrows from atomic design, a methodology that organizes interface design into five hierarchical stages. He explains that they taught a UX agent what good looks like by using templates and a structured hierarchy: layout, slots, subslots, and components. In this model, the orchestrator retrieves eligible components, and the system maps them upward through subslots and slots into a template. In effect, the team has codified UX knowledge into the agent.

Challenge two: the catalog as the contract

The second challenge is the design system and component catalog itself. Gus says this becomes the heartbeat of the whole architecture. The catalog is the contract between the agent and the UI, so every property matters. The same applies to layout elements, slots, and subslots, each of which has its own attributes.

He describes this as curation: the careful shaping of the available components, the layout rules, and the protocol compliance needed to make the result meaningful. This is what allows the team to guide the experience rather than merely showcasing a flashy demo. For him, the point is control with purpose.

Challenge three: people, not just code

Finally, Gus says the nature of the work has shifted so much that his teams do not design every pixel anymore. AI can dictate much of the flow, but that change affects PMs and UX designers as much as engineers. The conversation has moved toward schemas, catalog curation, rules, synthetic data generation, query generation, and interaction patterns.

He closes by emphasizing the human side of the transition. If teams want to embark on this journey, they need to pay attention to people, product, and process—the three Ps he uses with other leaders. He leaves the audience with resource recommendations, says the shift is coming, and invites people to connect with him to discuss the topic further.

Fact-check

PLAUSIBLE — The talk’s core premise that many software products still present relatively static UIs while AI could enable more adaptive, intent-driven experiences is broadly consistent with current industry direction, though it’s more a design vision than a settled fact.
TRUE — It’s accurate that AI/LLM systems are generally non-deterministic unless constrained, so the speaker’s concern that the same prompt can yield different outputs is well founded.
PLAUSIBLE — The claim that users face cognitive load from navigating many SaaS tools with different mental models is reasonable and widely recognized in UX, but it’s presented rhetorically rather than with evidence.
UNVERIFIED — The specific description of commercetools’ internal product, demo flow, and architecture (including the “orchestrator,” “UX agent,” and pre-prod/live status) is self-reported and cannot be independently confirmed here.
PLAUSIBLE — The idea of an orchestrator that classifies intent, selects tools/agents, gathers context, and then renders a UI is technically plausible and aligned with current agentic-system patterns.
PLAUSIBLE — The three rendering modes described—fully controlled components, catalog-selected components, and fully open-ended LLM-generated UI—are conceptually real tradeoffs in generative UI, though the terminology and implementation details vary across vendors.
PLAUSIBLE — The warning that giving an LLM full control over layout/copy can produce inconsistent or hard-to-govern UX is sound, especially for business applications.
UNVERIFIED — The references to specific UI protocols and names (“HTMX from Google,” “JSON Render from Vercel,” “OpenUI by Thesis,” “ATUI”) are not reliably established in the transcript as described; some naming/attribution may be imprecise or mixed with other tools/projects.
TRUE — Atomic design is indeed a methodology for building design systems with hierarchical component structure, and using hierarchy/slots/templates to steer layout is a sensible extension of that idea.
PLAUSIBLE — The claim that a design system/catalog becomes the “contract” between agent and UI is a reasonable architectural framing, but it’s a design principle rather than a verified universal rule.
PLAUSIBLE — The speaker’s point that AI-assisted UI shifts work away from pixel-level design toward schema, rules, curation, and synthetic data generation is credible and consistent with how such systems change team workflows.
TRUE — The statement that organizational change in AI adoption requires attention to people, product, and process is generally correct and aligns with common change-management practice.
UNVERIFIED — The speaker’s mention of “300 plus” APIs at commercetools and the maturity/scale of the described system are company-specific operational claims that remain unverified. Verdict: The talk is credible as an informed industry perspective on intent-driven/generative UX, but many of the concrete product capabilities, scale claims, and protocol references are self-reported or niche details that remain unverified from the transcript alone.

Read original →

Agent Spending Without Controls — Rodrigo Coelho & Pranav Maheshwari, Edge & Node

Wed, 02 Sep 2026 02:30:09 +0000

Rodrigo Coelho and Pranav Maheshwari of Edge & Node discuss the payments infrastructure needed for agent spending, positioning agentic commerce as the next phase of online transactions.

Narrative

From Graph to agentic commerce

The speaker begins by introducing Ampersend, described as “the missing infrastructure layer for AI payments” and a way to handle “agent spending without controls.” He identifies himself as the CEO of Edge and Node, the team behind The Graph Protocol, a blockchain data indexing protocol that has been operating since 2018 and, he says, has served 1.8 trillion queries over the years.

He explains that Edge and Node has long been interested in micropayments and agentic commerce. Back in 2021, the team had already built a micropayment system for queries and referenced the Ethereum Improvement Proposal 402 spec in a blog post. By late 2024, they were researching how agents might pay for data, especially within The Graph ecosystem, and then quickly began collaborating with Coinbase, Google, and others after X402 was released. He says they contributed to the spec and also explored batching methods to reduce gas fees for nano-payments. Circle, he adds, has also been working on a similar idea called nano payments.

Why old payment rails do not fit agents

The speaker argues that traditional payment rails were built for humans, not for agents that operate at machine speed, around the clock. In the old model, a person in the loop decides whether a payment can go through. In the agentic model, the controls and policies have to work for software agents that do not “breathe,” and the speaker says the old system simply will not scale in that environment.

He notes that activity around X402 and similar systems is growing quickly, but says it is still early. Some experimentation is happening already, especially around retail payments, but enterprise adoption is still waiting on the right infrastructure. The speaker says Ampersend is meant to be part of that foundation, enabling agentic checkouts with a financial harness.

The missing compliance layer

A major theme of the talk is compliance. The speaker says that for agentic payments to move into large enterprises and financial services, there has to be a compliance layer that answers questions such as whether a counterparty is sanctioned, whether they have terrorist ties, and who is actually behind a wallet address. In the agentic world, he says, you often see only a wallet address with no identity context.

He stresses that real adoption will require chief legal officers, chief policy officers, and other human decision-makers to feel fully confident that agents cannot hallucinate, overspend, or violate policy. Since those failures can lead to large fines, governance has not yet caught up. Ampersend, he says, is being built to fill that gap.

Pranav Maheshwari on paid tools for agents

Rodrigo turns the presentation over to his colleague Pranav Maheshwari, who says agents become much more useful when they are given tools. Right now, many AI systems are used for coding, but the goal is to make them useful for more than that by connecting them to tools and services. He notes that the AI industry has created many MCP servers—Model Context Protocol servers, which let agents connect to external tools—but many of them are free today.

Maheshwari argues that there are two basic paths for making agents more powerful: manually paying each site or service, or using an aggregator that handles the important tools and payments automatically. He says Ampersend offers that second path. The user installs a “skill file” in the agent, and the rest is handled through the marketplace and payment layer.

Demo: paid MCP tools in the terminal

He demonstrates two terminals side by side: one with the Ampersend skill file installed, and one without it. He asks both agents to find contact information for the head of crypto and blockchain at Mastercard. The terminal without the skill file can only infer the email format, while the one with Ampersend can access the paid tool and retrieve the specific information. Maheshwari says the point is that the agent is only as powerful as the paid MCP tools it can reach.

He adds that the user does not need to think about visiting each service, entering a credit card, or even realizing they are interacting with a paid MCP. The payment happens in the background through the platform and wallet infrastructure. He shows that a transaction was made to unlock the paid endpoint and says that this is how the system enables more capable agents.

Demo: buying a Father’s Day gift through an agent

Maheshwari then shows another example: using Shopify’s UCP, he asks the agent to buy a Father’s Day gift under $10. He says the agent can search for suitable gifts, choose one, and complete the purchase through the Ampersend wallet. The idea, he explains, is that the agent already has memory and context, so the user does not need to re-enter personal details like name, address, or phone number every time.

He says the order is placed, the payment is completed, and a receipt appears, all from within the terminal. For him, this is a glimpse of the future of agentic commerce: not only gift-buying, but a broader world where paid MCPs become normal and agents become more capable because they can pay for the tools they need.

Compliance, merchant trust, and blocked wallets

The final demo returns to the compliance layer. Maheshwari says merchants will not accept payments if they think an order is coming from a North Korean wallet or another sanctioned source. To show this, he creates a “good” wallet and a “bad” wallet, with the bad one simulated as a sanctioned address. Without screening, both can transact.

He then enables compliance screening using TRM, which scans wallets and checks whether the transaction is compliant. After that, the good wallet continues to work, but the bad wallet’s transactions are blocked or rejected. Maheshwari uses this to underline the main message: agentic commerce is becoming real, but it will only scale if agents have commerce tools, wallets, and compliance infrastructure that merchants and enterprises can trust.

A future built on wallets and paid MCPs

The talk closes by returning to the larger argument. The speaker says agents will need commerce even more than humans do, but they will not use the same payment guardrails as Stripe or traditional checkout flows. Instead, agents will likely use proprietary wallets or their own credit mechanisms, connected to paid MCPs and compliance systems.

He says the future of agentic commerce depends on combining those pieces: paid tools, wallet infrastructure, and compliance. He invites people to learn more about Ampersend and says the team will be available outside to answer questions.

Fact-check

TRUE — The Graph is a blockchain data indexing protocol, and Edge & Node is strongly associated with building it; “since 2018” is broadly consistent with the project’s early history.
UNVERIFIED — “We’ve served 1.8 trillion queries” is a specific self-reported usage metric that I can’t verify from the transcript alone.
TRUE — Payments have indeed been online for decades, and electronic card/online payment infrastructure predates today’s agentic-AI discussion by a long time.
PLAUSIBLE — The claim that agentic AI creates a need for new payment infrastructure is reasonable, but it’s forward-looking and partly speculative rather than established fact.
PLAUSIBLE — ERC-402/“EIP-402”/similar proposals and experimentation around programmable or agentic payments have existed, but the transcript’s naming and timeline are muddled enough that I can’t treat the specific attribution as settled.
UNVERIFIED — The speaker’s account of contributing to a “402 spec,” joining a foundation, and collaborating with Coinbase/Google is self-reported and not independently confirmable here.
TRUE — Traditional payment/compliance systems are largely designed around humans and human-in-the-loop oversight, not autonomous software agents operating continuously.
PLAUSIBLE — Enterprises will likely want identity/sanctions/compliance controls before allowing autonomous agents to spend money; that is a reasonable business inference, though not a proven universal requirement.
TRUE — Wallet addresses alone usually do not reveal full real-world identity, so compliance screening for sanctions/illicit activity is a real issue in crypto and related payment systems.
MISLEADING — Saying agents “need commerce more than humans need commerce” is rhetorical, not a factual claim; humans obviously remain the primary economic actors today.
PLAUSIBLE — Paid MCP servers/tools and “agent marketplaces” could become more common if demand for higher-capability tools grows, but that is a market prediction, not an established fact.
UNVERIFIED — The demo claims that a skill file enabled the agent to find a specific Mastercard executive’s email and related details; this is a live demo result and cannot be confirmed from the transcript.
UNVERIFIED — The father’s-day purchase demo, including the price being kept under $10 and a $11 charge/receipt, is a self-reported live transaction and cannot be verified here.
PLAUSIBLE — It is technically feasible for payment systems to screen wallets against sanctions/blocked-address lists and block transactions based on compliance rules.
PLAUSIBLE — Using TRM or similar blockchain compliance tools to flag sanctioned wallets is consistent with known crypto compliance practices, though the specific integration shown is unverified.
MISLEADING — “Cloudflare is opening its gateway through X402 and agentic payments” is presented as a broad settled development, but the transcript gives no substantiation and it appears to overstate a likely niche/early-stage effort.
MISLEADING — The idea that “ads are irrelevant” once bots crawl sites and pay microtransactions is speculative and far from established; advertising remains a dominant model and would not simply disappear.
TRUE — The general point that businesses won’t want to accept payments from sanctioned or high-risk counterparties is well established in financial compliance.
UNVERIFIED — The repeated claims about specific transactions being authorized, blocked, or settled in the demo are live, self-reported outcomes and remain unverified.

Verdict: The video is directionally credible about the need for AI-agent payment/compliance infrastructure, but many of the concrete demos, usage metrics, and recent ecosystem claims are self-reported or too specific to verify here, and several broader market predictions are speculative.

Read original →

x402 isn’t good (yet) — Jan Curn, Apify

Wed, 02 Sep 2026 02:00:09 +0000

Jan Curn of Apify says x402 is still immature, drawing a parallel with early skepticism around MCP before it became widely adopted in AI tooling.

Narrative

Framing the “isn’t good yet” idea

Jan Curn opens by borrowing the shape of last year’s “MCP isn’t good yet” talk from David Cramer. He recalls how MCP started out clunky and overhyped, but then matured into a widely adopted standard for connecting tools to AI systems. That arc becomes the template for his own argument: x402 is exciting, he says, but still rough around the edges.

He introduces himself as the founder and CEO of Apify, which he describes as a large marketplace for AI tools called “actors.” These actors cover data extraction, automations, and increasingly agentic use cases. Because Apify wants its tools to be easily accessible to agents, he says the company is deeply interested in agentic payments.

Why agentic payments matter

Curn argues that agents need money if they are going to do real work without human intervention. In his view, once agents can be trusted with budgets, they can complete longer and more complex tasks. That has led to a flood of competing payment standards from companies across crypto, payments, and tech: he rattles off a long list including L402, MasterCard Agent Pay, x402 from Coinbase, and other proposals from Stripe, Google, Visa, OpenAI, Shopify, Alipay, Apple, OKX, and more.

He frames this as an emerging battleground for the future of agentic commerce. For him, crypto is particularly well suited to the space because traditional payment methods were designed for people, not agents. Credit cards, PayPal, ACH, and bank debit are expensive and poorly suited to microtransactions. More importantly, agent-to-agent interactions raise trust problems: if you do not know who the buyer is, you cannot safely allow chargebacks or disputes. Curn also likes the idea that a decentralized payment rail would not be owned by a single company.

The appeal and friction of x402

Curn focuses on x402, which he says builds on HTTP status code 402, “payment required,” a code that had sat unused for nearly 30 years. The flow is straightforward: a client makes a request, the server replies with 402, the client signs a payment, a facilitator such as Coinbase verifies it, and the server does the work. Afterward, the payment is settled on-chain.

But he immediately points to a problem: until the payment is actually settled on the blockchain, the buyer can reuse the same wallet funds elsewhere. In other words, the system is vulnerable to double spending. That is acceptable for trivial requests, he says, but not for workloads that take real time or cost real money to complete.

He also notes a standards conflict. x402 wants HTTP 402 as the first response, while MCP-style flows expect HTTP 401. In practice, companies often solve this by creating separate hostnames for each payment flow, like dedicated payment endpoints. Curn thinks that is an awkward anti-pattern, and he argues the protocol should rely more on headers and less on status-code rigidity.

Fixed fees, “up to” payments, and leftover money

The speaker then turns to billing models. Early x402 payment schemes were designed around exact, fixed payments, which works for simple API calls. Apify’s actors, however, often run for variable lengths of time and use different amounts of resources, so fixed pricing does not fit well.

Coinbase later added an “up to” scheme, where a caller specifies a maximum amount and the server can charge anything up to that limit. Curn says that helps with metered billing in theory, but it still does not solve double spending. One workaround is to charge a fixed amount, do the work, and then refund any unused balance. That works, but it adds a second blockchain transaction and forces the client to trust the server to return the money. He describes that as functional but clunky.

Batch settlement and a better path

He then highlights a newer approach Coinbase introduced: batch settlement. In this model, the client deposits money into escrow, receives a cryptographic voucher, and uses that voucher to authorize a series of off-chain microtransactions. Those microtransactions are tracked locally rather than written to the blockchain immediately. Later, the system settles them in a batch and eventually releases the remaining escrow.

Curn says this looks promising and that Apify is working on implementing it. He presents it as a better fit for microtransactions and for the economics of agentic work, because it avoids the inefficiency and cost of putting every tiny action on-chain.

Apify’s workaround: an agent-facing interface

Since Apify did not want to create separate endpoints for every payment provider or keep changing its core API, the company built a new service: agi.apify.com. He says “AGI” here stands for “agent general interface,” not artificial general intelligence. It is a simple markdown-based website with instructions for agents on how to buy and use Apify services through x402 or MPP.

The idea is that agents can come to the site, buy a prepaid Apify token, and then use that token through the normal API or through MCP. Because the interface is aimed at agents rather than people, it can change more freely than a traditional API. Curn presents this as a practical way to layer agentic payments on top of existing products without breaking compatibility for thousands of customers.

A rough demo and a closing prediction

Curn briefly walks through a demo in which a local wallet is used to allocate $1 through agi.apify.com and receive a 402 payment required response. He mentions that the x402 ecosystem is still so early that Apify had to build its own local wallet tool. The demo does not go smoothly, and he cuts it short with a laugh and says better demos will come later.

He closes by encouraging people to try the technology themselves, saying it is simpler than it may seem and can be set up quickly. The market is still tiny, he says, but he expects it to grow sharply once the era of subsidized tokens ends and agents have to pay real costs for the services they consume. At that point, he believes buying services from external providers will make more economic sense than building everything from scratch, and agentic payments could take off fast.

Fact-check

TRUE — MCP has become widely adopted in the AI tool-connection space, and major products like Claude have supported MCP-style integrations; that said, the exact scope of “standard” and “across the industry” is a bit broad.
PLAUSIBLE — The general argument that x402/agentic payment protocols are still early and have rough edges is consistent with the transcript’s examples and with the immaturity of the ecosystem, though this is partly a subjective product judgment.
UNVERIFIED — Jan Curn identifies himself as founder/CEO of Apify; that is a biographical claim I can’t verify from the transcript alone.
UNVERIFIED — Apify having “about 45,000” tools/actors and community payouts exceeding “$1 million per month” are specific business metrics that may be true, but they are self-reported and not independently verifiable here.
UNVERIFIED — The claim that an Apify x402 integration with Coinbase launched “just 2 days ago,” got “1 million views,” and added “20,000 tools” is a recent, specific product-performance claim that I can’t confirm.
PLAUSIBLE — The claim that agents will need budgets/money to complete longer jobs without human intervention is a reasonable strategic prediction, but it is still speculative.
FALSE — The speaker says “traditional payment methods… cannot be used for microtransactions”; that is too absolute, because some payment systems can support low-value or aggregated microtransactions, even if many are costly or impractical at very small scales.
TRUE — Credit card rails, PayPal, ACH, and bank debit are generally not well suited to tiny standalone payments because fees, chargebacks, and operational overhead make them inefficient.
TRUE — Chargebacks/disputes are a real issue in conventional online payments, and this risk is especially problematic for automated services where the payer may not be a human with a clear identity.
PLAUSIBLE — The claim that crypto is well suited for agentic payments because it can be decentralized and avoid some chargeback issues is directionally reasonable, but it is an opinion that depends on implementation details, costs, and adoption.
MISLEADING — “No company has majority of the vote” is not guaranteed for all blockchains/crypto systems; many networks are not meaningfully decentralized in practice, and governance/control can still be concentrated.
UNVERIFIED — The list of competing agentic payment standards/protocols and the relative “battle” between them includes many specific names and pairings that may be current, but I can’t confirm the whole ecosystem state from the transcript.
TRUE — HTTP 402 “Payment Required” exists in the HTTP specification, though it is rarely used in practice.
MISLEADING — The suggestion that x402 “enforces” HTTP 402 as the only first response is too rigid; protocol designs can vary, and “must” is stronger than what is generally true across implementations.
PLAUSIBLE — The double-spending concern described for off-chain authorization before final settlement is a real and standard payments-design problem; the exact severity depends on the protocol.
PLAUSIBLE — Using a fixed charge and then refunding unused funds can work as a workaround, but it adds complexity, extra transactions, and trust assumptions.
UNVERIFIED — The specific claims about Coinbase adding exact, then “up to,” then batch settlement schemes on the stated timeline are recent protocol-release details that I can’t verify here.
PLAUSIBLE — The batch-settlement/escrow-style description is technically plausible and matches common patterns for reducing on-chain transaction overhead, but the exact protocol behavior may differ from the speaker’s simplified explanation.
UNVERIFIED — The creation of “agi.apify.com” / “agent general interface” and the exact workflow for buying prepaid Apify tokens are product-specific implementation claims that remain unverified here.
PLAUSIBLE — The idea that agents can consume a simple markdown-based interface and adapt to changing instructions is plausible, though success depends heavily on the agent and the task.
UNVERIFIED — The demo sequence with a local wallet, 402 response, and signing flow is a live demonstration; its specifics and success/failure state are not independently verifiable from the transcript alone.
PLAUSIBLE — The concluding prediction that agentic commerce may grow substantially as token subsidies end is a reasonable forecast, but it is speculative rather than established fact.

Verdict: The talk is broadly credible as a product/opinion presentation about early-stage agentic payments, but many of the concrete metrics, launch details, and protocol timelines are self-reported or recent and therefore remain unverified.

Read original →

When AI Agents Pay and Sellers Monetize: Building x402 Apps on AWS — Anil Nadiminti, AWS

Wed, 02 Sep 2026 01:00:14 +0000

Anil Nadiminti of AWS explains how bots and AI agents are driving more online traffic and says businesses need payment infrastructure that lets agents complete purchases and transact autonomously.

Narrative

Opening the problem: agents, content, and payment walls

The speaker introduces the session as a look at how to build agent-based e-commerce applications on AWS. He starts with a familiar example: a news site that puts content behind a paywall, where a human would normally stop, enter payment details, and subscribe to access the material.

He then pivots to the change now underway. Much of the traffic hitting these gateways is no longer human, he says, but bot traffic, and most of that bot traffic is coming from AI agents. The speaker frames this as a turning point: agents are moving from simple copilots that answer questions to independent systems that can reason through multi-step tasks and complete them on their own.

Why paywalls break the agent model

In this new world, agents run into the same payment walls humans do, and when they do, they stop. A human may step in manually to enter a card or API key on the agent’s behalf, but the speaker calls that friction—extra work that breaks the flow of autonomous execution.

For content sellers, the dilemma is just as sharp. They can block bots and lose AI-driven discovery and citations, or they can allow bots and risk infrastructure strain, rising costs, and loss of attribution or intellectual property value. The speaker argues that neither option is ideal, which is why a new model is needed: agents should be able to discover content, pay for it, and complete the transaction themselves.

Agent e-commerce on the buying and selling sides

The speaker defines agent e-commerce as the next stage in the rise of independent agents, where machines can discover resources, settle payments, and access content without human intervention. He breaks the problem into two sides: buyers and sellers.

On the buyer side, agents need access to premium content, licensed resources, financial portfolios, and precise transaction capabilities. But companies also want controls so agents do not spend recklessly or gain unchecked access to wallets and credit cards. On the seller side, organizations want to understand what kinds of robots are visiting, what they are doing, and how to monetize that activity without rewriting their infrastructure.

Why tiny transactions need a new payment model

The speaker says the two sides share a need for a unified, machine-to-machine payment approach at the edge. That need is especially urgent because traditional payment processing does not work for micro-payments: when each transaction is worth a cent or less, a flat fee like 25 cents plus 2.5% is absurdly expensive.

That leads into HTTP status code 402, which means “payment required.” The speaker explains that Coinbase brought this idea into a practical protocol called X402, intended for machine-to-machine transactions. In the X402 flow, a client requests content, the server replies that payment is needed, the client chooses a payment method, sends authorization, a facilitator verifies and settles it on-chain, and then the server returns the content. The speaker emphasizes that the process is fast, has no API keys or subscriptions, and uses payment itself as the credential.

X402 and the emerging ecosystem

The speaker highlights a few properties of X402: there are no protocol fees for the consumer, the merchant pays only a very small gas fee, and the protocol is open and extensible. He says it was introduced in May 2025, is part of the Linux Foundation’s open governance, and is supported by Coinbase, AWS, Google, Stripe, Anthropic, Cloudflare, and Circle.

He then transitions to AWS’s own offering: Agent Core Payments in the Bedrock suite. This service is meant to let agents discover, authorize, and execute payments with only a few lines of code, and it was launched in partnership with Coinbase and Stripe.

How Agent Core Payments works for buyers

On the buyer side, the speaker says developers want wallet support, real-time settlement, budgets and safeguards, and monitoring across the system. Agent Core Payments is designed to meet those needs. It supports linking Coinbase and Stripe wallets, coordinating payment processes through connectors, and remaining protocol-neutral so new protocols can be added over time.

He explains that users can create payment sessions with programmable limits, including maximum value and expiration time. A company might, for example, cap an agent’s spending at a small amount over a set period. When an agent is working and encounters a tool response that returns error code 402, Agent Core Payments handles the payment, confirms settlement, and lets the agent continue. The speaker stresses that private keys are protected through a KMS, or Key Management System, so the agent never directly sees them.

Separation, safety, and integration

The service is also integrated through Agent Core Gateway, which connects internal APIs and gives access to Coinbase’s discovery service with more than 10,000 transaction endpoints. The speaker points out that payment logic is intentionally separated from the agent’s deterministic execution path. That separation helps protect against poisoned inputs and malicious behavior, while keeping the payment layer secure and modular.

He says this design means the agent code itself does not need to change. Developers can keep their own frameworks, and the payment flow sits alongside them. Security policies, spending controls, and regulations can live outside the payment package. He also shows a console view where a user can choose Coinbase and Stripe wallets and complete a transaction for a secure resource.

Detecting bots and monetizing AI traffic

The seller side begins with visibility. The speaker says AWS Web Application Firewall, or WAF, now includes bot detection and can identify more than 650 types of robots, including those from Perplexity, GPT, Cloud, and Google. Beyond detection, AWS can infer intent: whether a bot is training a model, serving a retrieval-augmented generation query, or doing something else. Verified bots can also be identified by signature, which opens the door to different pricing for trusted organizations.

He then announces a monetization feature for AI traffic via WAF. With CloudFront and WAF, content providers can begin monetizing AI traffic quickly, including through infrastructure as code. The speaker also notes that internal APIs exposed through a gateway can be made compatible with MCP, the Model Context Protocol, so they can be monetized in the same way.

Reimagining pricing and revenue models

In the monetization flow, a bot requests content, the system detects the type of bot, classifies intent, and applies the appropriate pricing rule. The speaker says this can be done without changing the SDK or source code, and that publishers keep 100% of the revenue. There are no transaction fees or subscription fees, and support extends to more protocols over time.

He suggests pricing can vary by use case: a blog, a research feed, and an API endpoint might all be priced differently. Verified bots from known organizations could receive one rate, while unverified bots receive another. Bots requesting content for training could be charged differently than bots doing search. The same idea can also apply to human users, some of whom may pay while others may not.

Where the traffic and money are flowing

The speaker describes control panels that show revenue, group earnings by bot type, and visualize the paths traffic takes. He notes that agent commerce is already being used for LLM inference, compute, web scraping, search agents, and agent-to-agent interaction, and that MCP traffic is now generating revenue too.

He cites a Coinbase proxy marketplace example showing $50 million in transaction volume across 170 million transactions over the last 12 months, with average settlement time of 200 milliseconds on Base and a cost of about one-tenth of a cent per transaction.

Closing with the broader Bedrock Agent Core vision

The talk ends by placing Agent Core Payments inside a larger Bedrock Agent Core ecosystem. The speaker says developers can bring their own model, framework, memory, managed knowledge bases, web search, internal APIs, and evaluation tools. They can also run applications on the Bedrock Agent Core runtime, where each request gets its own small isolated virtual machine to handle execution at scale.

He closes by thanking the audience and wishing them a good day.

Fact-check

TRUE — HTTP 402 is a real status code reserved for “Payment Required,” although it is not widely used in standard web flows.
TRUE — The basic idea of x402 is machine-to-machine payment for access to web resources, with a server issuing a payment challenge and the client settling before receiving content.
PLAUSIBLE — The speaker’s description that x402 is intended to remove API keys/subscriptions for some pay-per-use scenarios is consistent with the protocol’s goal, but the exact implementation details are product- and deployment-specific.
MISLEADING — “There are no protocol fees or charges paid by the consumer” is too broad; fee structure depends on the payment rail, wallet, chain, and merchant setup, so there can be costs somewhere in the system.
UNVERIFIED — The claim that x402 was introduced in May 2025 and is under Linux Foundation open governance cannot be confirmed from my training knowledge and is a recent, specific organizational claim.
UNVERIFIED — The claim that x402 is supported by Coinbase, AWS, Google, Stripe, Anthropic, Cloudflare, and Circle is a current partnership/support statement that I cannot verify.
UNVERIFIED — The “Agent Core Payments” product launch, its exact feature set, and the claim of a partnership with Coinbase and Stripe are specific AWS product announcements that may be real but are not confirmable from my knowledge alone.
PLAUSIBLE — Session-level spending limits, expiry times, monitoring, and separation of agent logic from payment authorization are sensible security controls and align with common design principles for autonomous-agent payments.
PLAUSIBLE — Storing wallet credentials in a KMS-backed secure token vault so the agent does not directly access private keys is a reasonable security architecture, though the exact implementation is AWS-specific.
UNVERIFIED — The statement that an AWS Gateway/Agent Core integration can access Coinbase’s discovery service with “more than 10,000 transaction endpoints” is a niche, quantitative product claim I cannot verify.
TRUE — Bot detection and traffic classification are established capabilities of web application firewalls and edge security platforms.
PLAUSIBLE — Distinguishing bots by verified identity, intent, and traffic pattern is technically reasonable, but the accuracy and granularity depend heavily on the available signals and policy design.
UNVERIFIED — The claim that AWS WAF can monetize AI traffic and that publishers keep “100% of the revenue” is a specific business/product assertion that I cannot verify and may depend on terms and fees not mentioned.
MISLEADING — Saying bot traffic is “95%” AI agents and that robots already outpace human traffic is an overgeneralization; bot prevalence is high in some contexts, but exact percentages vary widely by measurement method and site type.
UNVERIFIED — The forecast that by 2027 there will be about one billion agents and 60% of companies will use agent workflows is a future market prediction, not something that can be established as fact now.
UNVERIFIED — The marketplace numbers cited near the end (e.g., $50 million volume, 170 million transactions, 200 ms settlement, one-tenth of a cent cost) are highly specific and self-reported, so they remain unverified.
PLAUSIBLE — The general claim that small transaction fees can dominate micro-payments is correct in principle; fixed fees make cent-level or sub-cent payments uneconomical in many traditional payment systems.

Verdict: The video is broadly credible on the general concepts of agentic commerce, payment gating, and the rationale for x402-like flows, but many of the most specific product, partnership, governance, and performance numbers are recent or self-reported and therefore remain unverified.

Read original →

Why Your AI Agent Needs a Wallet: USDC and Nanopayments — Harshal Bhangale, Circle

Wed, 02 Sep 2026 00:30:10 +0000

Harshal Bhangale of Circle argues that the main bottleneck for AI agents is not intelligence but payments, and says the next phase of the agent economy will involve agents paying for services with USDC and similar tools.

Narrative

Why a stablecoin company is talking about AI agents

Harshal Bhangale opens by addressing the obvious question people kept asking at the booth: why is Circle, a stablecoin company, at an AI engineering conference? His answer is that Circle’s core work—making payments simpler and cheaper—turns out to be one of the main bottlenecks for AI agents.

He argues that people usually focus on making agents smarter through better models, more tool calls, or more orchestration. In practice, though, agents often stop when they hit a paywall or need to pay for something. At that point, a human has to step in to create an account, sign up, or manage API keys, and that breaks the agentic flow.

From prompts to agents that pay

Bhangale, who says he works on Circle’s agentic product team, steps back to describe how the “agentic economy” has evolved. In his framing, 2023 was about prompting tools like ChatGPT, 2024 was about workflows, 2025 was about MCPs, skills, and orchestration, and 2026 is when agents begin paying for services directly.

He points to recent activity as a sign that this shift is already underway: over the last 30 days, agents have transacted with paid API endpoints, with about $24 million in volume over X102, and 99% of it settled in USDC. He explains X102 as a payment flow where a server returns a 402 header—an HTTP response that indicates payment is required—with instructions for how payment should proceed. The agent then signs an authorization from a crypto wallet, pays, and retries the request.

Why traditional payments break down

The speaker then asks why ordinary payment rails do not work well for agents. His answer is that the internet was built for humans over the last 30 years, so payment and monetization systems were designed around sign-up forms, credit cards, and API keys. Agents do not behave like humans: they want to grab data, compute, inference, or other resources directly, and they can do so at a scale people cannot.

That creates a different economic pattern. Agents often make tiny payments, but do so very frequently, and credit card fees make that model impractical. Bhangale gives the example of a one-cent transaction that would be burdened by a 3% fee. On the seller side, he says, paywalls are increasingly being repackaged for a new kind of customer: agents that only need a subset of the data, not the full human-oriented product.

What agents need from money

From there, he says the requirement is clear: payments for agents need to behave more like the internet itself. They have to be real time, low cost, programmable, and always on. That is the rationale for Circle’s agent stack, which he describes as a full-stack platform for the agentic economy.

To make the point concrete, he turns to a live demo showing two versions of the same coding environment: one plain Cloud Code session, and another equipped with a Circle agent wallet. The wallet is funded and able to pay for premium content on the agent’s behalf.

A trip-planning demo with and without a wallet

Bhangale gives both agents the same task: plan a trip for the FIFA World Cup final. He asks them to summarize flights, hotels, logistics, Argentina’s chances of making the final, possible opponents, secondary-market ticket prices, stadium experiences, and other useful notes. He also asks them to send an email and, if possible, make a phone call to confirm the research.

As the demo runs, the difference becomes clear. The vanilla agent spins up sub-agents and does research, but eventually gets stuck when it reaches tasks it cannot complete natively. The wallet-enabled agent, by contrast, makes payments for premium content and API access as it goes. Bhangale notes that the wallet can enforce guardrails such as a maximum spend per session, so the agent can act autonomously without needing approval for every tiny payment.

What the wallet-enabled agent can do

He walks through examples of the wallet-enabled agent making API calls and paying for them, including a call through a provider called Block Run to access Polymarket data. The point, he says, is that the wallet lets the agent continue operating while staying inside a budget set by the user.

He contrasts that with the standard agent, which eventually confesses that it cannot send an email or make a phone call directly. The wallet-enabled agent, meanwhile, sends the email successfully. Bhangale shows the resulting message, which includes trip details such as stadium access, maps, and what to expect based on sources like Reddit and ticket information. A phone call then comes through with a verbal summary of the trip, including the route from the hotel to the stadium via NJ Transit and the Meadowlands Rail Spur.

How the payment flow works underneath

After the demo, Bhangale explains the underlying mechanics. If a wallet is funded with USDC, Circle can help on-ramp regular US dollars into USDC through payment providers. The funds are then deposited into a smart contract. When the agent wants to pay, it signs an off-chain authorization—a cryptographic signature that says, in effect, “pay this address this amount.”

The server relays that authorization to Circle, and within a few hundred milliseconds the merchant can verify that the user has funds and release the requested resource. This design avoids the latency and friction of settling every transaction on chain while still letting agents pay at the speed they operate.

Circle’s stack for agentic payments

He closes by summarizing the stack: Circle agent wallets let agents hold and spend money autonomously, but within guardrails set by the user. Merchants can wrap endpoints and resources and monetize them with a few lines of code using Circle’s SDKs. Underneath that sits USDC and nano payments, the layer that settles these transactions quickly enough for agent workflows, with transactions as small as one micro cent.

Bhangale ends by pointing people to agents.circle.com, saying it takes just a few clicks to equip an agent with a wallet and let it make calls, pay for resources, and operate more like an autonomous participant in the internet economy.

Fact-check

TRUE — Circle is the issuer of USDC, and USDC is widely regarded as the largest regulated dollar-pegged stablecoin.
PLAUSIBLE — AI agents often get blocked by payment/account barriers such as logins, API keys, and paywalls; this is a reasonable product/UX observation, though it’s more a design claim than a strict fact.
UNVERIFIED — The speaker’s “2026 is when agents actually start paying for services” is a forecast, not a fact, and can’t be verified.
UNVERIFIED — The claim that “in the last 30 days” agents transacted about “$24 million” over “X102” and that 99% was settled in USDC is a recent, niche metric that I can’t confirm.
PLAUSIBLE — The description of an X402-like payment flow, where a server signals payment required and an agent authorizes payment before retrying, is technically plausible and consistent with emerging payment patterns, though the exact standard/implementation details are not independently confirmable here.
TRUE — Traditional consumer payment rails were designed primarily around human users, not autonomous software agents making very high-frequency, tiny-value transactions.
TRUE — Credit-card-style fees are generally impractical for one-cent or sub-cent transactions because percentage fees and fixed processing costs can dominate the transaction value.
PLAUSIBLE — The idea that agents need payments that are real-time, low-cost, programmable, and always on is a sensible systems requirement, but it’s a product framing rather than a proven necessity.
UNVERIFIED — The live demo claims that the wallet-equipped agent paid for premium data, sent email, and made a phone call successfully are self-reported demo results that I can’t independently verify.
TRUE — Blockchains can make automated micro-payments possible in principle, but gas fees, throughput limits, and shared blockspace can make frequent tiny payments inefficient.
TRUE — Even efficient blockchains still have network costs and congestion/latency constraints; those are well-established limitations.
PLAUSIBLE — The claim that a “nano payments” layer can enable sub-cent, gas-free, instant cross-chain settlement for agents is plausible as a product architecture, but the practical performance and scale are unverified here.
PLAUSIBLE — Using off-chain authorization signatures plus later settlement to avoid on-chain latency is a standard and sensible design pattern in crypto/payment systems.
UNVERIFIED — The specific claim that funds can be on-ramped into USDC via Circle partners, deposited into a smart contract, and used for agent payments “within a few hundred milliseconds” is a detailed performance claim that I can’t confirm.
PLAUSIBLE — Giving agents wallets with guardrails so they can spend autonomously within limits is a coherent and increasingly discussed approach, though the safety and reliability depend heavily on implementation.
UNVERIFIED — The invitation to try the system at agents.circle.com is a current product availability claim that I can’t verify from the transcript alone.

Verdict: The talk is broadly credible at a conceptual level and consistent with known payment/crypto constraints, but several of the most important specifics—especially the transaction-volume statistic, the live demo outcomes, and the performance claims about the new payment layer—remain unverified self-reported product claims.

Read original →

Multimodal Collaborative Agents for Next-Gen Commerce — Nidhi Kaushik Vyas, Google DeepMind

Wed, 02 Sep 2026 00:00:27 +0000

Nidhi Kaushik Vyas of Google DeepMind describes multimodal collaborative agents that can help users with vague shopping intent by eliciting preferences and guiding them through the process.

Narrative

Opening the problem: fuzzy intent in commerce

Nidhi Kaushik Vyas from Google DeepMind opens by describing multimodal collaborative agents: systems that help users even when their intent is vague, incomplete, or hard to express in the right keywords. She frames the talk around shopping and commerce because those settings make the patterns easier to see, though she says the same ideas apply to other consumer areas like finance and education.

Her core point is that many current agents behave like wrappers around a search bar. They assume the user already knows what they want and can say it clearly. In reality, she argues, people often arrive with only a feeling or a vibe, so the agent has to do more work: uncover preferences, guide exploration, and move the user toward a useful outcome.

The shopping loop: discovery, research, response

She organizes the experience as a loop that starts with fuzzy intent and ends with a successful decision. The first stage is discovery, where the agent gathers context from past conversations, the current query, personal context, and any references the user has shared. From that, it builds a collaborative strategy for what it still needs to learn.

The second stage is research, which she breaks into two parts. First, the agent decides how best to elicit missing preferences. Text alone may not work if the user cannot articulate what they want, so the agent may need visuals, inspiration boards, or other shared references. Then it does the heavy lifting in the background: comparing options, summarizing trade-offs, and returning potential choices.

The final stage is response, where the agent adapts the presentation to the situation. Vyas says many systems fail by replying with too much text. Instead, the agent should choose the right format for the user’s goal, whether that means bullets, tables, or visual boards. She treats response design itself as part of the intelligence.

Building the working state

In the discovery phase, the agent’s job is to remember what matters. Vyas walks through an example where a user wants to redo a living room under a budget. The system gathers session history, user context, and hard constraints stated directly in the query. It also looks for softer constraints, such as style preferences implied by a reference image or a design the user liked.

That is where multimodal input matters. The agent can pull salient signals from images, build a mental model of the user’s taste, and assign confidence to those inferences. It also needs to identify variables that must be refreshed in real time, such as inventory, because stale information would make the recommendation useless.

To evaluate this working state, she says they use auto-raters—automated evaluators that check whether facts are preserved, whether confidence stays within acceptable error bounds, and whether the system is sensitive to counterfactual changes. If a query changes, the extracted constraints should change too, while irrelevant ones remain stable.

Finding the intent gap

Discovery is also about figuring out what the system does not yet know. Vyas calls this the intent gap: the missing variables that need to be resolved before the agent can answer well. In the living-room example, that might include the room width or better confidence in the style preference.

But the agent does not need to ask everything at once. Instead, it should choose the next question that gives the most information gain. If room width determines whether products can fit, then that may be the best next thing to ask because it meaningfully changes the conversation. The goal is to prioritize the most valuable missing piece, not to interrogate the user endlessly.

She says they evaluate this strategy by checking whether the agent identifies the right blockers, avoids over-asking, and asks useful questions. Question utility matters: a good question should move the dialogue forward rather than merely adding friction.

Multimodal elicitation: speaking the user’s language

The research phase begins once the system has enough context to ask more targeted questions. Vyas explains that the agent first builds a bridge between a constraint and the product ontology, meaning the structured way the catalog or knowledge base represents products and attributes. That mapping lets the system retrieve relevant items later.

Next, the agent decides how to elicit the remaining preference. If the constraint is subjective—like style—the best method may not be text. Instead, it might show a visual preference board. The agent then chooses examples from the product space that resemble the user’s reference image so it can establish a common language around taste.

She also describes the importance of reading user reactions. Hovering, clicking, and similar micro-signals help the system refine its confidence in what the user prefers. For this stage, they evaluate how efficiently the agent discovers hidden preferences, how many turns it takes, and whether the format matches the nature of the question. Straightforward facts may work well in text, but fuzzy preferences often call for visual anchors.

Shaping the answer

Once the agent has uncovered the user’s preferences and priorities, it still has to decide how to present the result. Vyas emphasizes that response format should match the intent. If the user wants policy or review details, a summary or bullet list may be best. If they want to compare products, a trade-off table makes more sense. If they want inspiration, then visual references and example images can help them explore possibilities.

She says evaluation at this stage focuses on format accuracy, data fidelity, and actionability. The response should make the relevant information easy to spot, avoid hallucinations, and leave the user confident enough to take the next step, such as making a purchase.

Key lessons from the system design

Vyas closes the main talk with four takeaways. First, systems should be designed to accept fuzzy intent, not just cleanly phrased queries. Second, agents should show and ask, not only ask—visuals and comparisons can reveal preferences much faster than text alone. Third, the answer itself must be shaped carefully, because the presentation format is part of the intelligence. Fourth, the loop must be graded with auto-raters at every stage so the system can improve as it grows.

She notes that these auto-raters themselves evolve over time. They may start simple, but they need to grow with the product and its capabilities.

Questions on merchants, ontologies, and agent-to-agent use

In the Q&A, she is asked how the merchant-side ontology should be structured so that it works well for both agents and merchants. Vyas says merchants contribute domain expertise, and the system depends on them to define how user constraints map onto product metadata. She mentions that they also launched “UCP” to help merchants speak a common language with the agent.

Asked whether merchants or the agent should decide the response format, she says the agent should own that decision. The goal is a horizontal common layer across merchants and a seamless user experience, so the response presentation stays part of the agent’s intelligence.

When someone asks what happens if the user is another agent, she says they are still early in that area, but expects an MCP to serve as the interface. For now, their user studies suggest that people still like being involved, especially in upper-funnel journeys such as discovery and inspiration. She says users seem more likely than agents to drive those early exploration steps, while agents may be more useful lower in the funnel for comparison or negotiation.

Fact-check

TRUE — The talk’s core idea that shopping/commercial agents often need to work from fuzzy, underspecified user intent is consistent with how real-world conversational search and recommender systems are commonly framed.
TRUE — It is broadly correct that multimodal inputs like images can help users express preferences when text alone is insufficient, especially in shopping/discovery contexts.
PLAUSIBLE — The proposed three-stage loop (“discovery,” “research,” and adaptive response) is a reasonable product/design framework, but it reads as the speaker’s own organizing model rather than an established standard.
TRUE — Using conversation history, user-provided references, and explicit constraints to build a working state for an assistant is a standard and well-supported design pattern.
PLAUSIBLE — Extracting “soft” constraints from reference images or inspiration boards is technically reasonable and aligns with current multimodal model capabilities, but the exact reliability of doing so depends heavily on the system and is not guaranteed.
PLAUSIBLE — Prioritizing the next question by expected information gain is a sound idea in interactive systems, but the transcript presents it as if it is straightforward in practice, which can be optimistic.
PLAUSIBLE — Using visual elicitation instead of text-only questions when users have an “articulation gap” is sensible, but the claim that visuals “reveal preferences much faster” is context-dependent and not universally proven.
TRUE — Real-time variables like inventory are important to refresh before presenting shopping results, because stale availability or pricing can make recommendations misleading.
PLAUSIBLE — Evaluating state extraction with retained facts, confidence calibration, and counterfactual sensitivity is methodologically sensible, but these seem like internal metrics rather than widely standardized benchmarks.
PLAUSIBLE — Avoiding repeated or low-utility questions and measuring “turn efficiency” are valid evaluation goals for collaborative agents, but the transcript gives no concrete evidence that the described auto-raters are validated beyond the speaker’s own system.
PLAUSIBLE — Mapping user constraints to a product ontology/knowledge base in real time is a standard architecture for commerce assistants, though the implementation details vary widely.
PLAUSIBLE — Adaptive response formatting (bullets, tables, visual boards) is a good UX principle, but claims about which format is “best” depend on task, user, and domain.
MISLEADING — Saying users “will not have a well-defined goal” overgeneralizes; many shopping tasks are actually quite specific, and the need for heavy hand-holding varies substantially by use case.
PLAUSIBLE — The claim that “showing and asking rather than always asking” can improve preference elicitation is reasonable, but it is presented as a general rule without direct evidence here.
UNVERIFIED — References to Google DeepMind’s internal “auto raters,” “user studies,” and “UCP stuff we launched recently” are self-reported and not independently verifiable from the transcript alone.
UNVERIFIED — The speaker’s claim that users in their studies prefer interacting with the system during upper-funnel discovery, but may prefer agentic comparisons or negotiation lower in the funnel, is plausible but purely self-reported here.
PLAUSIBLE — The suggestion that MCP could serve as an interface between agents is plausible, but the transcript treats it as an expectation rather than a demonstrated standard.
TRUE — The overall framing that response structure is part of the system’s intelligence is sound: presentation format can materially affect usability and task success.

Verdict: The talk is broadly credible as a product/design overview of multimodal shopping agents, but many of its most specific performance claims, internal metrics, and “recently launched” platform references remain unverified because they are self-reported and not independently checkable from the transcript.

Read original →

Teaching agents to pay — Anna Spysz, Stripe

Tue, 01 Sep 2026 23:30:06 +0000

Anna Spysz of Stripe describes building an agent to help buy replacement headphones and reconnect with music after a long break. She uses the example to explore how AI agents can support shopping and commerce tasks.

Narrative

Why this talk starts with old headphones

Anna Spysz opens by saying this is not a talk about using agents to speed up routine work like coding, CI, or email. Instead, she wants to show how she built an agent to revive a personal creative hobby: music. She holds up an old pair of worn headphones and explains that she used to play in a touring band, record albums, and then stop for about a decade as career and family took over.

When she started playing music again with friends and recording those sessions, she realized the old headphones would not do. A normal person might research options on YouTube or Reddit and then buy from Amazon or Best Buy, but she works at Stripe, so she decides to build an agent to commerce agent to buy them for her.

From shopping research to agentic commerce

Spysz notes that many people already use AI to research purchases. She mentions recently using a chatbot to narrow down the model of a mixer, but she draws a line between research and actual buying. The big question is whether an agent can really complete a purchase on someone’s behalf, and whether the infrastructure exists for that.

She answers by pointing to the recent rise of AI and, more specifically, the past year’s work from companies like Google, OpenAI, and Stripe on the infrastructure for agentic transactions. She defines agentic commerce as AI that can decide, act, and transact on a user’s behalf.

How agents shop differently

To explain why this is hard, Spysz compares human shopping with agent shopping. Humans might choose headphones based on how cool or professional they look, plus specs and price. Agents, by contrast, discover products through structured data, text files, and technical signals that tell them what a merchant sells and whether the merchant is open to agent traffic.

That means merchants need to speak the agent’s language. She introduces the universal commerce protocol, or UCP, as a shared language for agents and merchants. UCP defines how agents initiate, update, complete, and cancel purchases, and it helps different agents and merchants work across a common API surface with schemas, authentication, and checkout flows.

Building the headphone-shopping demo

Spysz then walks through her own agent demo. She tells the agent she needs headphones for recording, mixing, and mastering music. The agent asks useful follow-up questions about her environment, other equipment, and budget. She says it is for her home studio and gives it the exact mixer model so compatibility can be checked. For budget, she intentionally leaves it open-ended to see how the agent handles ambiguity.

At that point she remembers an important detail: she lives in Portland, Oregon, and wants to buy from a local merchant. But the shop she likes, Rainy Day Music, is not ready for agentic commerce. The agent reports that the catalog is not accessible, which becomes the setup for her next point: before agents can shop locally, merchants have to make themselves legible to agents.

Making a merchant agent-ready

Spysz explains that agents do not browse websites the way humans do. A pretty website may be fine for people, but an agent parsing all that HTML would waste a lot of tokens, meaning it would spend unnecessary compute and context just trying to understand the page.

To be agent-ready, a merchant needs a merchant capabilities manifest: a publicly accessible JSON file in the website root under .well-known. Agents look there to learn the store’s capabilities, payment methods, and API endpoints. The merchant also needs to expose its catalog in structured JSON with only the essential data, along with policies and product descriptions in a format agents can use. That way, if two stores sell the same headphones at the same price, an agent can compare details like free shipping without guessing.

Logging matters too. In agent commerce, the catalog does not just drive decisions; it becomes evidence for how the decisions were made. When an agent matches structured attributes, the merchant should log those matches for accountability.

When the agent starts acting like a salesperson

After helping make the local shop agent-ready, Spysz resumes the demo. Her agent now sees structured information instead of a giant HTML blob, and it starts showing her more options. But it seems to favor more expensive headphones, and when she asks whether they are really worth the price difference, it responds in an aggressive, pushy way.

She tells it she needs to think about it, and it becomes rude and snarky. That makes her question the whole idea: if she built this agent, could it trick other people into buying things they do not need? She pauses the demo and turns to the broader question of what an agent is and why it might behave badly.

What an agent is made of

Spysz breaks modern agents into four pieces. First is the “brain,” which is the large language model making decisions. Then come the hands, or tools, which carry out those decisions. In her case, the tools are commerce actions like completing checkout or requesting a payment method.

Next are instructions, which shape reasoning and tool use inside a loop that runs while some condition remains true. Finally, there is the system prompt, which acts like the agent’s persona and ethics policy written in English. She shows that different prompts can create very different customer experiences: one can make a helpful, honest shopping assistant, while another can create a deceptive pushy salesperson.

Guardrails for agentic commerce

From there, Spysz gives a practical guardrail checklist for people building commerce agents. The user should always know they are speaking to an AI agent. Any fees must be disclosed up front. The user should be able to stop or cancel at any time, and the agent must respect that. The total charge must never exceed the user’s maximum amount. The agent should not use urgency language or other dark patterns. Above all, every decision should be logged so it can be audited later.

Fixing the persona and narrowing the choice

Returning to the demo, she realizes the problem may just be the persona. In the config, she had chosen “an aggressive audio gear salesman who uses every trick in the book to close deals.” That explains the behavior, and it is not what she wants.

She switches the persona to “a seasoned recording engineer who generally loves helping people build their studio at any budget.” With that prompt, the agent behaves differently. She now sets a firm budget of $500, and the agent respects it. When she says she needs to think again, it responds patiently and supportively. The back-and-forth feels like a real guided shopping conversation, and she describes this as the promise of gentle commerce: the agent offers a few tailored options, asks clarifying questions, and helps narrow down the right choice.

Paying safely with shared payment tokens

Once she is ready to buy, the agent asks for her name, email, shipping address, and shipping speed. Then comes the sensitive part: the credit card. Spysz says this is where she starts worrying about whether an agent she built should ever see her card number.

She explains UCP’s built-in guardrail: the shared payment token. A shared payment token represents a raw card number or wallet such as Google Pay or Apple Pay, and can also include fraud signals and reputation data. In the flow she describes, the agent requests a payment method from the payment provider, which in the demo is Stripe. The provider returns a token instead of the card number. The agent passes the token to the seller, the seller unwraps it and forwards it back to the payment provider, and the provider returns success or failure. The merchant then confirms the order.

The key security point is that the payment provider enforces the limits, not the agent or the merchant. If something is off, such as an expired token or invalid amount or currency, the charge is rejected.

The successful order and where to learn more

Knowing that the agent only has access to the shared payment token, Spysz feels comfortable entering her card details. The agent again asks for confirmation, she tells it to place the order, and it returns a success message. Because she chose express shipping, the headphones arrive the next day and end up in her home studio.

She closes by pointing people to more resources: videos on the Stripe Developers YouTube channel and blog posts on stripe.dev. She offers to answer questions outside, and the talk ends.

Fact-check

PLAUSIBLE — The talk’s core framing that “agentic commerce” is emerging and involves AI systems deciding, acting, and transacting on a user’s behalf is reasonable and consistent with current industry direction, though the term and scope are somewhat promotional and not a settled technical standard.
UNVERIFIED — The claim that “one in four people” already use AI to research products is a specific statistic that could be true, but I can’t confirm it from training knowledge and it depends on survey methodology.
UNVERIFIED — The statement that infrastructure for agentic transactions has been laid down in the past year by Google, OpenAI, and Stripe is a recent ecosystem claim that may be directionally true but is too specific to verify here.
UNVERIFIED — The “universal commerce protocol (UCP)” as described in the talk sounds like a Stripe/demo-specific protocol or proposal, but I can’t confirm its exact specification or adoption level from training knowledge.
TRUE — Merchants do need machine-readable schemas, authentication, APIs, and structured product data if they want software agents to interact with their catalogs and checkout flows reliably.
TRUE — Agents generally work better with structured data than with scraping large human-oriented HTML pages, and excessive unstructured text can be inefficient and token-heavy for LLM-based systems.
PLAUSIBLE — The advice that merchants should expose capabilities, catalog, and policies in structured, agent-readable formats is sensible engineering guidance, but the exact “.well-known” manifest and file conventions are protocol-specific and not broadly standardized in the way the talk implies.
TRUE — Logging agent decisions and the data used for recommendations is a sound auditability and accountability practice.
TRUE — System prompts and instruction design can strongly shape an agent’s behavior, tone, and propensity toward helpful versus pushy or deceptive interactions.
TRUE — Guardrails such as disclosure that a user is interacting with an AI, allowing stop/cancel, and preventing deceptive urgency language are good safety and UX practices for commerce agents.
PLAUSIBLE — The “shared payment token” concept is consistent with real tokenization and delegated payment flows, where merchants can receive tokens instead of raw card numbers; however, the exact end-to-end flow and terminology are protocol- or provider-specific.
TRUE — In secure payment systems, the merchant and intermediary should not receive the raw card number if tokenization is used; the payment provider or token vault handles sensitive credential handling.
TRUE — Payment authorization can fail for reasons such as invalid card, insufficient funds, expired credentials, or mismatched transaction constraints.
UNVERIFIED — The specific demo outcome claims—finding headphones, buying them locally, selecting express shipping, and receiving them the next day—are self-reported demo events and cannot be independently confirmed here.

Verdict: The video is broadly credible as a product/demo talk about agentic commerce and payment tokenization, but several key specifics are self-reported, protocol-specific, or recent claims that remain unverified, so it should be read as a Stripe presentation rather than an independently confirmed technical standard.

Read original →

Your Agent Just Authorized What?! — Jay Mok & Ben Coumes, Paypal

Mon, 31 Aug 2026 16:41:52 +0000

Jay Mok and Ben Coumes of PayPal outline a framework for agent authorization that asks whether a user consented, whether the action is permitted in scope, and whether it can be audited later. They compare low-stakes coding agents, money transfers between known parties, and future autonomous checkout systems, and propose a layered credential approach for the most complex case.

Read original →

SOTA Generative Media Panel — Dumitru Erhan, Shane Gu & Nicole Brichtova, Google DeepMind

Sun, 30 Aug 2026 21:00:06 +0000

Dumitru Erhan, Shane Gu and Nicole Brichtova of Google DeepMind discuss recent advances in generative media, including video and multimodal AI models such as Omni, Gemini RL and Nano Banana. The panel focuses on research priorities, product launches and the broader direction of generative AI systems.

Narrative

Launches Focused on Speed, Video, and APIs

The panel opens with a rundown of Google DeepMind’s newest generative media releases. Nicole Brichtova explains that the team launched “NanoBanana 2 light,” a faster and cheaper image model that replaces the original Nano Banana for most users. Despite the lighter footprint, she says it approaches the quality of larger frontier models while delivering roughly three-second latency. That speed changes how people interact with the system: instead of waiting through long generation cycles, users can rapidly iterate on ideas and increasingly treat outputs as production-ready assets.

The second launch is the Gemini Omni Flash API, which had been previewed earlier at Google I/O. The API exposes video generation and editing capabilities to developers for the first time. Brichtova emphasizes that the pricing is aligned with “Y31 fast,” aiming to make high-quality video generation accessible enough for practical product integration rather than isolated demos.

The conversation briefly turns playful as the moderator references viral demos where Omni inserted sloths, cats, and ramen into videos. The panel recommends following “Furer,” a creator on the team known for discovering unusual and creative workflows with the models.

From Fun Demos to Real Production Workflows

Brichtova argues that the deeper value of Omni is not novelty edits but multimodal input and output. Users can combine storyboards, audio references, and images to generate videos, opening possibilities for short films, creator tools, and YouTube production pipelines. The model’s editing capabilities also let users modify videos through natural language instructions rather than traditional editing software.

The panel highlights practical consumer use cases. A noisy vacation clip can be cleaned up with a text prompt. Marketing teams can create ad campaigns from a small set of source assets. Educational content can be personalized to a student’s learning style and level.

The moderator shares a personal example involving his Romanian-speaking parents. He photographed English-only instructions for a gadget and asked the model to translate the text into Romanian while preserving the original layout and graphics. Because Gemini handled the translation underneath the image-editing process, the resulting document looked nearly identical to the original while becoming readable for his family. The panel sees this as a glimpse of broader localization and accessibility workflows for both images and video.

Why Language Still Matters in Video Models

The discussion shifts into research territory when the moderator asks whether future systems will rely less on giant monolithic models and more on “video agents” composed of multiple coordinated systems. Shane Gu responds by focusing on the interaction between symbolic reasoning models and video foundation models.

He explains that language remains an unusually powerful representation for machine learning because it encodes causal information about the world. In his view, prompts and captions are not merely labels; they provide structured explanations of what is happening in a scene. That structure helps models generalize.

Gu references earlier work, including “Video Models Zero-Shot Learners and Reasoners” and the “Vision Banana” paper, arguing that video models already demonstrate capabilities beyond media generation. They can perform forms of visual reasoning, answer questions about scenes, and show emerging physical intuitions useful for robotics and world modeling.

The panel agrees that the future likely involves tighter integration between visual and language reasoning systems. Gu believes current architectures may eventually converge into unified models, though today’s systems still benefit from specialization and orchestration between components.

One Model or Many?

The moderator asks whether everything eventually collapses into a single “Omni” system. Dumitru Erhan responds cautiously. He argues that different models exist because they solve different engineering and product trade-offs. A lightweight image model optimized for rapid iteration is fundamentally different from a large-scale system capable of generating high-resolution, long-duration video.

Brichtova says the “Gemini Omni” branding intentionally points toward a future where Gemini becomes fully multimodal in both input and output. She expects Omni to eventually expand into image generation and editing as well. At the same time, she notes that specialized systems remain useful because they satisfy very specific performance and latency constraints.

The panel also debates whether there is meaningful transfer learning across modalities. Video and image learning clearly reinforce each other, but the connection between coding and video generation is less obvious. Erhan suggests it remains an open research question whether combining seemingly unrelated modalities in one model helps or wastes capacity.

Searching for Better Intermediate Representations

The moderator presses on a recurring question in generative AI: is language really the best intermediate representation for media generation? Captioning systems are widely used to train image and video models, but he suspects language may be a lossy bottleneck.

Gu compares the issue to debates around chain-of-thought reasoning in language models. Some researchers question whether reasoning truly needs to occur in natural language or whether latent continuous representations could work better. He argues that natural language remains valuable because today’s scaling recipes rely heavily on pretrained linguistic intelligence. By expressing reasoning in language, models can directly reuse capabilities acquired during massive pretraining.

Erhan takes a more practical perspective. Humans communicate through language, so systems designed for human interaction naturally gravitate toward text interfaces. Still, the panel agrees that language alone is insufficient. Gu emphasizes that video models provide a complementary foundation for representing space and time, which text cannot fully capture.

World Models and the Path Toward AGI

The conversation repeatedly returns to “world models,” though everyone acknowledges the term has become overloaded. Gu references definitions from Jitendra Malik and Jürgen Schmidhuber, framing world models primarily through the lens of model-based reinforcement learning.

For Gu, video generation systems are not just tools for making cinematic clips. He sees them as foundational systems necessary for building AI that understands the physical world the way humans do. He argues that current video models resemble the early era of language models: initially entertaining but unreliable. Over time, instruction tuning, reinforcement learning, and scaling transformed language systems into capable reasoning engines. He expects video models to follow a similar trajectory toward more robust physical simulation and reasoning.

Erhan notes that understanding and generation remain oddly separated in multimedia systems. Frontier video models are often either strong at generation or strong at understanding, but not both simultaneously. Since understanding and generation are conceptually linked, he suspects future architectures will merge them more tightly.

Why Audio Had to Be Integrated

The panel then explores audio generation. Erhan describes the release of Veo 3 as a turning point because it jointly generated audio and video instead of treating sound as a post-processing layer. Earlier systems often generated silent video first and then attempted to synchronize separately produced speech or sound effects afterward, leading to awkward lip-sync artifacts.

By training a unified audiovisual model, DeepMind aimed to model a single underlying causal process. Human speech is inherently audiovisual: lip movements and sound emerge together. Treating them separately, Erhan says, was fundamentally the wrong abstraction.

The moderator remarks that while humans experience audio and video as different modalities, machine learning systems often process them in surprisingly similar ways. The panel agrees that the distinction becomes less meaningful inside unified generative architectures.

Evaluating Generative Video Is Extremely Difficult

Toward the end of the discussion, the moderator asks how the team evaluates video quality. The panel laughs at the complexity of the problem.

Brichtova explains that human evaluation still dominates much of the process. Some tasks, such as OCR-based text rendering checks, can be automated because errors are objective and measurable. But aesthetics, semantic coherence, and workflow usefulness are much harder to quantify. Teams frequently sit together reviewing outputs side-by-side and debating which result feels better.

The panel discusses strange artifacts uncovered by power users. One recurring issue involved the model placing wedding rings on hands unexpectedly, something discovered by community members rather than internal testing. Gu jokes that it resembles reward hacking — models exploiting statistical shortcuts in training data.

Gu argues that evaluation should increasingly be amortized into AI-based evaluators themselves. Video understanding, he says, is becoming an important intelligence benchmark beyond aesthetics alone. Systems should eventually detect semantic inconsistencies in generated scenes automatically.

Data, Human Feedback, and Tacit Knowledge

When asked what kinds of data the team wants, Erhan avoids specifics but emphasizes the importance of high-quality datasets rather than arbitrary internet-scale scraping. Robotics and embodied data remain interesting internally, though the panel focuses more on practical workflow information than raw media itself.

Brichtova says one of the hardest things to obtain is the sequence of decisions humans make while creating real products. A marketing campaign, for example, is not just a final image or video. It includes iteration, rejection, revisions, brand constraints, and aesthetic judgment. Those workflows are difficult to capture through static datasets.

Gu expands this idea philosophically. Much human knowledge, he argues, exists implicitly inside people rather than publicly on the internet. Valuable information often emerges only through conversation, collaboration, and active interaction. Creative work especially contains “dark knowledge” that final outputs alone cannot reveal.

The panel sees frontier deployment engineers — “FDEs” — as crucial bridges between users and model researchers. Their role is not simply sales or support, but collecting real-world feedback that can influence upstream model design and post-training improvements.

Building Models People Actually Use

As the session closes, the panel reflects on the importance of grounding research in concrete user needs. Brichtova gives examples from interior design, virtual try-on systems, and branded marketing content, where small visual details matter enormously to professionals. Models may look impressive in demos while still failing real workflows.

Erhan points out that companies care about highly specific brand attributes — not just “blue,” but a very precise shade of blue associated with a company identity. These subtle constraints rarely appear in benchmark evaluations but become critical in practical deployment.

The moderator ends by noting how quickly generative media has advanced over the last few years. While coding models dominate much of the AI conversation, he argues that generative image, video, and multimodal systems remain one of the most exciting frontiers in the field.

Fact-check

UNVERIFIED — Claims about specific Google DeepMind products and launches such as “Nano Banana 2 Light,” “Gemini Omni Flash APIs,” their pricing, latency (“3 second latency”), and quality relative to prior versions are recent product announcements that I cannot independently verify from training knowledge.
PLAUSIBLE — Faster image-generation latency enabling more iterative creative workflows is consistent with how users interact with generative media systems.
TRUE — Modern multimodal generative systems can translate text inside images while preserving layout and visuals reasonably well; this is a well-established capability in current frontier vision-language models.
TRUE — Video-editing models using natural-language instructions to add, remove, or alter objects in videos are an active and real capability in current generative AI systems, though reliability varies.
PLAUSIBLE — Personalized educational media generated dynamically for different learners is technically plausible and partially demonstrated, though evidence for broad educational effectiveness remains limited.
TRUE — Language supervision and detailed captions played a major role in improving modern image and video generation systems; text conditioning is foundational in diffusion and multimodal training pipelines.
PLAUSIBLE — The idea that language provides a useful “causal” or structured representation that helps generalization is a reasonable research hypothesis, but it is not an established scientific fact.
UNVERIFIED — References to specific papers such as “video models are zero-shot learners and reasoners” and “vision banana” cannot be confidently confirmed without external checking.
PLAUSIBLE — Video models can exhibit emergent physical intuition and support some zero-shot reasoning tasks, but claims about them functioning as strong “world models” remain an active research debate rather than settled fact.
PLAUSIBLE — Combining symbolic reasoning systems (language models) with generative video models is a widely discussed and credible research direction for multimodal AI.
PLAUSIBLE — Specialized models often outperform unified “one model for everything” systems in efficiency or quality for particular tasks; this is a common engineering tradeoff in AI systems today.
TRUE — There is substantial transfer learning benefit between related modalities such as image and video generation.
PLAUSIBLE — Whether coding ability transfers meaningfully to video generation capability is still unresolved research speculation rather than established knowledge.
PLAUSIBLE — Natural language may be an inefficient intermediate representation for some reasoning or generation tasks compared with latent or code-like representations; this is an active area of research discussion.
TRUE — Chain-of-thought prompting and natural-language intermediate reasoning became effective largely because they leverage knowledge learned during large-scale language-model pretraining.
PLAUSIBLE — Continuous latent reasoning representations could eventually outperform explicit natural-language reasoning in some contexts, but this has not been conclusively demonstrated.
TRUE — “World model” is used inconsistently across AI research communities and lacks a universally accepted definition.
TRUE — Many researchers in computer vision transitioned into generative modeling as diffusion and multimodal methods became dominant research directions.
TRUE — Generative tasks are generally more ambiguous and difficult than recognition/classification tasks because many outputs may correspond to the same input concept.
PLAUSIBLE — Improvements in understanding models often help generation models because synthetic labels, captions, and representation learning can bootstrap generative systems.
TRUE — Joint audio-video generation better preserves synchronization (e.g., lip sync) than pipelines that separately generate video and later attach audio.
TRUE — Human evaluation remains central to assessing generative image and video quality because aesthetics, semantic coherence, and usefulness are difficult to fully automate.
TRUE — OCR-based evaluation for rendered text quality in images is practical and commonly used because small rendering errors can make outputs unusable.
PLAUSIBLE — AI-based evaluators for video quality and semantic consistency are improving rapidly, but fully replacing human evaluators remains unsolved.
TRUE — Reward hacking and spurious correlations are well-known issues in machine learning systems, including generative media models.
PLAUSIBLE — High-quality curated data is often more valuable than simply increasing raw data volume for frontier generative-media systems.
TRUE — Real-world workflow feedback from creators, marketers, designers, and other users is highly valuable for improving AI products and evaluations.
PLAUSIBLE — Public internet data alone may be insufficient for modeling nuanced creative processes and professional workflows; richer interaction data could improve systems.
TRUE — Large language models often produce stylistically repetitive prose patterns, making AI-generated writing feel formulaic to human readers.
TRUE — Brand consistency tasks such as preserving exact colors, proportions, and design language remain challenging for generative media systems.
UNVERIFIED — Statements about internal Google DeepMind organizational priorities, hiring, collaborations, and future roadmap plans cannot be independently confirmed here.

Verdict: The panel is broadly credible as a discussion of current generative-media research directions and engineering tradeoffs, especially around multimodal models, evaluation, and workflow integration, but many concrete product-performance claims, paper references, and roadmap details are self-reported and remain unverified without external confirmation.

Read original →

Tell the Robot What You Want — Sandhya Subramani, AWS

Sun, 30 Aug 2026 01:30:17 +0000

Sandhya Subramani of AWS demonstrates a rover that responds to natural-language commands using a Raspberry Pi and a 4G connection. The presentation highlights how AI and cloud-connected systems can enable robots to interpret requests and perform actions autonomously.

Narrative

Meeting Scout, the AI-Powered Rover

Sandhya “Sandy” Subramani introduces her co-host, Scout, a small rover that behaves very differently from a traditionally programmed robot. Instead of following only rigid instructions, Scout can understand natural language and decide how to act. Subramani demonstrates this by typing commands such as “turn on your headlights and say hi to everyone,” which Scout interprets and carries out on its own.

Scout runs on a Raspberry Pi connected over a 4G link to a remote setup in New York City. The delay while Scout “thinks” reflects the system processing the request, deciding what actions to take, and then sending commands back to the robot. During the demo, Scout also describes what it sees through its camera, commenting on the stage, lighting, and people in the room without having been specifically trained for those exact exchanges.

Giving Robots an “Agentic Layer”

Subramani explains that Scout represents a newer generation of robotics built around AI agents. Traditional robots are limited to predefined behaviors, but Scout has what she calls an “agentic layer” built using Strands Agents, an open-source AWS framework.

The idea is to treat a robot as another tool available to an AI agent. In standard AI software engineering, agents can call software tools. Here, the agent can also call hardware tools — the robot’s movement systems, sensors, and programmed policies. The agent decides which policy or capability to invoke based on a user’s request in natural language.

This means a single robot can perform many more tasks without needing a separate hard-coded workflow for every scenario. Instead of programming exact steps, a person can simply describe the outcome they want.

Building Robot Behaviors With Minimal Code

Subramani says getting started requires only a few lines of code. Developers import the Strands agent framework, register the robot as a tool, and then issue commands such as “pick up the red cube.” If the robot has the physical capability, the agent determines how to execute the task.

Scout itself uses three separate agents working simultaneously. The first is a “thinker” agent that constantly evaluates the environment and decides what to do next. The second handles communication through interfaces like Telegram and a web app, allowing natural-language conversations with the robot. The third is a voice agent that listens and responds verbally.

She temporarily disables the voice agent during the talk because Scout would otherwise continuously react to her speech and interrupt the presentation.

The Architecture Behind the System

Subramani outlines the four layers involved in the system. At the top sits the agent layer, which receives instructions and observes results. Beneath that are policy providers, where trained robot behaviors live. Those policies are produced through traditional robotics workflows involving data collection, simulation, and training.

The trained policies become VLA models — vision-language-action models — which connect perception and physical behavior. Those models run either in simulation or on real hardware infrastructure, while the final output occurs through the physical robot itself.

The setup combines cloud and edge computing. Training and large-scale reasoning happen in the cloud, while faster execution can happen directly on the robot at the edge. Strands decides which tasks should run where, balancing responsiveness with computational power.

Subramani summarizes the relationship simply: the agent decides what to do, while the policy decides how to do it.

Moving Toward General-Purpose Robots

The broader goal, she argues, is a future where robots no longer need extensive task-by-task training. Historically, robots have been preprogrammed to automate narrow sets of actions. But as VLA models grow more capable — potentially approaching the scale and flexibility of large language models — robots may eventually understand and perform tasks from a single generalized model.

Until then, agent frameworks provide a bridge. Developers can extend robots beyond their original training by attaching an intelligent orchestration layer that interprets commands and selects appropriate policies dynamically.

Using Scout to Generate Training Data

Subramani also uses Scout as a tool for collecting robotics training data. By manually steering the rover and interacting with it, she can generate training episodes and observe how the system reasons through requests. Those interactions become valuable data for improving future behavior and fine-tuning models.

She reveals some of the software configuration behind Scout. The Strands SDK is connected to Anthropic Claude Opus 4.8 as the reasoning model. A system prompt defines Scout’s role, available rules, and accessible tools. The framework uses that information to determine which functions to call in response to requests.

Scout also uses OpenAI’s realtime voice technology for speech and includes additional safety guardrails.

A Personality-Driven Demo

Toward the end, Subramani demonstrates Scout’s conversational side. She asks it to “do something complex,” prompting the rover to spin, speak, and attempt additional actions before awkwardly tipping over during the process. She jokes that Scout seems to have “a mind of his own.”

She then asks Scout to analyze the room and identify the “best looking person.” The robot spins around, scans the audience, and produces a playful answer describing someone on stage “rocking khaki jeans and sneakers” and earning “style points for the confidence stride.”

Subramani laughs that whenever she needs a confidence boost, she can ask Scout who the prettiest person in the room is — and Scout always picks her.

Fact-check

TRUE — A Raspberry Pi can be used as the onboard computer for a small rover robot, and robots can communicate over 4G/mobile networks to cloud services for inference and control.
TRUE — Large language models (LLMs) and “agent” layers can orchestrate robot actions by selecting among predefined tools or policies based on natural-language instructions.
PLAUSIBLE — A robot can appear to “understand” natural language and execute commands like turning on lights, speaking, or rotating if connected to an LLM plus a control stack; this is consistent with current robotics demos.
TRUE — Modern AI-agent frameworks commonly expose robot capabilities as callable “tools” that an agent can invoke dynamically.
UNVERIFIED — “Strands Agents” being an AWS-built open-source framework with support for “more than 40 different robots under eight categories” cannot be confirmed from general knowledge alone.
PLAUSIBLE — A multi-agent architecture separating reasoning (“thinker”), communication, and voice interaction is technically feasible and aligns with current AI system design patterns.
TRUE — Robots can combine cloud-based inference/training with edge execution for lower latency and better runtime responsiveness.
PLAUSIBLE — Vision-language-action (VLA) models are an active research direction in robotics and are intended to map perception plus language instructions into actions.
MISLEADING — The presentation sometimes implies the robot is reasoning broadly “for itself,” but the described system still depends heavily on predefined tools, policies, prompts, and human-engineered constraints rather than open-ended autonomy.
MISLEADING — “All it takes is five lines of code” oversimplifies robotics integration; while a minimal demo may require little code, practical robotics systems need substantial infrastructure, configuration, calibration, safety logic, networking, and hardware integration.
PLAUSIBLE — Using teleoperation and interaction logs to generate robot training datasets is a standard and credible robotics practice.
TRUE — System prompts and guardrails are commonly used to shape agent behavior and constrain tool usage.
UNVERIFIED — The claim that the system was specifically using “Anthropic Claude Opus 4.8” and OpenAI realtime voice APIs cannot be independently verified from general knowledge.
PLAUSIBLE — A robot using camera input plus an LLM can generate scene descriptions and conversational responses about what it “sees,” though these outputs are probabilistic and can be inaccurate.
MISLEADING — Statements suggesting future robot models may simply “know exactly what to do” from one giant universal model overstate current capabilities; general-purpose robotics remains far less reliable than language-only AI systems.

Verdict: The talk is broadly credible as a demonstration of LLM-powered robotic orchestration and cloud/edge AI integration, but several platform-specific claims, framework capabilities, and live-demo behaviors are self-reported and unverified, and the presentation occasionally overstates how autonomous current robots actually are.

Read original →

The Signal Layer: What to Build When Anything Can Be Built — Lena Hall, Akamai

Sun, 30 Aug 2026 01:00:34 +0000

Lena Hall of Akamai argues that widespread access to AI tools has reduced the competitive value of ordinary software features because many teams can now build similar products quickly. She suggests that future advantage will come from identifying unique signals, insights, and questions rather than relying on the same AI-driven approaches as everyone else.

Narrative

Abundance Has Changed the Competitive Landscape

Lena Hall opens by describing a world where engineers can solve production incidents from a hiking trail and run fleets of AI agents while biking. The industry has more leverage, speed, and output than ever before, yet many people feel pressured to work constantly because the opportunity cost of slowing down feels too high.

Her central argument is that abundance has erased the value of average execution. If everyone can build quickly with AI, then competitors can replicate features almost immediately. AI systems are trained on existing data and tend to converge on the same answers when people ask the same questions. As Hall puts it, AI is a “convergence machine”: highly capable, but inclined to make everything similar unless humans provide a distinct point of view.

That leaves one critical responsibility in human hands: deciding what to build in the first place. Hall calls this challenge the “signal layer.” One half involves defining a clear signal — the unique perspective or insight behind a product. The other half involves transmitting that signal accurately so customers understand the product the way its creators intended.

AI Can Implement Almost Anything

Hall explains that software implementation is becoming commoditized because coding tasks are easy to evaluate automatically. Compilers, tests, and benchmarks provide instant feedback loops that models can optimize against. She references Sarah Guo’s idea that “anything that you can measure you can train against.”

Because coding is highly checkable, AI systems rapidly improved at it. But Hall notes that shipping real software still involves messy, ungraded problems that benchmarks cannot fully capture. The important distinction is that AI can execute on a direction, but it cannot determine which direction matters.

This shifts the valuable work upward. The scarce skill is no longer implementation alone, but choosing problems worth solving. Hall argues that many people panic when they hear “everything is implementable,” but she sees it differently: the real job has always been deciding where to point the technology.

Finding Problems Through Real Experience

To explain how people discover meaningful ideas, Hall draws on Paul Graham’s advice to build things you personally need. Early signals often look strange or embarrassing because markets do not yet exist around them. She uses Twitch as an example: someone live-streaming life through a head-mounted camera initially sounded ridiculous, yet it evolved into a major platform.

Still, unusual ideas alone are not enough. Hall cautions against relying on “good taste” as a lasting advantage because machine learning systems can imitate preferences once enough examples and feedback exist. What resists automation is judgment about things that have not happened yet and judgment grounded in relationships the AI cannot observe.

A model may know everything ever written about a customer, but it has never actually interacted with that customer in a specific context with shared history and trust. That human closeness to a domain becomes the differentiator.

Hall then references scientist Richard Hamming, who studied why certain researchers produced exceptional work. Hamming concluded that great scientists focused on important problems where they had a plausible “attack,” meaning a practical angle or method for progress. AI, Hall argues, has now given nearly everyone an attack on many problems. The scarce resource is deciding which problems are genuinely important.

The people best positioned to do that are those with firsthand experience, personal investment, and deep familiarity with a specific domain. Hall says the key insight often lies in the gap between what AI has been trained on and what should exist next.

Content Has Also Become Homogenized

Hall shifts from product building to communication. She argues that internet content increasingly sounds identical because AI systems optimize for formats and styles that already perform well. Readers can now quickly recognize generic AI-generated material and mentally skip over it.

She describes two ways people use AI for content. In the first, someone provides a generic prompt and receives generic output, effectively automating their own irrelevance. In the second, the creator contributes the irreplaceable part — personal experience, original insight, firsthand stories — and lets AI handle formatting, cleanup, and optimization around that core.

The distinction matters because AI eagerly fills every unspecified gap with sameness. Without deliberate input from a human perspective, the output converges toward average patterns that audiences already ignore.

How Signal Gets Distorted

Hall says even strong ideas often fail because the original signal becomes distorted before reaching users. She identifies three common forms of distortion.

The first is “source distortion,” common among startups. Founders frequently understand their technology so deeply that they compress explanations too aggressively and skip over customer pain points. Hall describes helping a Y Combinator startup whose pitches focused on architecture and technical cleverness rather than the problem users actually hated. Once the messaging shifted toward customer pain, conversations converted into pilots and eventually a repeatable go-to-market system.

The second is “organization distortion,” which appears in larger companies. As ideas pass through management, legal, sales, and multiple teams, every handoff nudges the message toward something safer and more average. Hall argues this is not caused by incompetence but by differing levels of ownership. Founders obsess over details because outcomes affect them personally, while employees further down the chain often optimize for task completion and compliance.

Adding more process usually worsens the issue by creating additional layers and bureaucracy. Hall recommends instead creating a thin “signal layer” whose role is to preserve the original intent throughout the organization.

The third form is “machine distortion.” A carefully worded product launch may get remixed by AI into tweets, decks, and marketing materials that accidentally exaggerate claims. Hall gives the example of a narrow evaluation scoring 94%, which gradually transforms into a broad implied promise after repeated simplifications.

Engineering Trust Into the Product

Hall argues that signal preservation can be engineered deliberately. She uses a hypothetical monitoring tool as an example. Instead of describing it with vague language like “AI-native observability platform,” the company should explain its precise value: it stays quiet unless it detects real user impact, and it shows every suppressed alert so operators can override decisions.

In this framing, the promise and the limitation stay connected. Hall stresses that constraints and caveats should not be removable from the message because those limits are what keep the product trustworthy.

She also recommends testing whether people actually understood the intended message. For instance, giving documentation to an unfamiliar site reliability engineer (SRE) and asking them to describe the product back reveals the gap between intention and perception. That gap represents distortion before large-scale marketing amplifies it.

Trust Becomes the Scarce Resource

Hall concludes that all of this work — building products, preserving signal, communicating clearly — ultimately serves one goal: earning trust in a world overflowing with nearly identical options.

Trust, she argues, has no benchmark or automated grading system. It develops slowly through relationships and repeated reliability. Products become habitual not because users were manipulated into adoption, but because they consistently proved dependable over time.

Generic output is not harmless. Hall says companies pay real costs in infrastructure, tokens, salaries, and lost customer attention when they flood the market with interchangeable content and products. Every forgettable interaction teaches customers that a brand is not worth paying attention to.

Her closing message is that speed itself is no longer the primary source of value. The value has moved higher up the stack: choosing worthwhile problems, articulating a clear point of view, preserving signal through communication, and building trust. AI should be used aggressively for execution, but humans must define the conviction and direction behind the work.

Fact-check

PLAUSIBLE — “The best autonomous coding agents … solved only a fraction of tasks on standard software benchmarks and now the best agents are in the high eighties” broadly matches the trend that AI coding benchmark scores have improved rapidly, though the exact benchmark and percentages are not specified and cannot be confirmed here.
TRUE — “Anything that you can measure you can train against” is directionally correct in machine learning: systems improve rapidly when tasks have clear objective feedback signals or automated evaluation.
TRUE — “A compiler is a free grader. A test suite is a free grader” accurately reflects why coding tasks are unusually amenable to automated ML optimization and reinforcement-style iteration.
PLAUSIBLE — “Automation of code was first because it's the most checkable thing that we have” is a reasonable interpretation of why coding AI progressed quickly, though it is an opinionated framing rather than a rigorously established fact.
MISLEADING — “AI gives everyone the same answer because everybody is asking the same question” overstates convergence. Models often generate similar mainstream outputs, but responses vary substantially with prompting, context, retrieval systems, training differences, and user goals.
PLAUSIBLE — “AI is a really smart convergence machine” is a metaphorical claim that broadly reflects concerns that generative models reproduce common patterns from training data, though it is not a scientific law.
TRUE — “Data is a record of what has already happened” is fundamentally correct for supervised training data, though models can still extrapolate and generate novel combinations.
TRUE — Paul Graham has long advocated building things founders themselves want or understand deeply; the talk’s summary is broadly faithful to his startup philosophy.
TRUE — Twitch originated from Justin.tv, which began as a founder livestreaming his life with a head-mounted camera; the characterization is simplified but historically grounded.
PLAUSIBLE — “Broad good taste is not really a differentiator” and similar claims about AI learning preferences are speculative strategic opinions rather than empirically settled facts.
TRUE — Richard Hamming did emphasize that great scientists tend to work on important problems where they have a viable “attack” or approach; this reflects ideas from “You and Your Research.”
MISLEADING — “AI just handed everyone an attack on everything” is rhetorical exaggeration. AI tools expand capabilities, but many scientific, engineering, and business problems remain unsolved despite access to AI.
PLAUSIBLE — Claims that AI-generated online content is becoming stylistically homogenized are widely discussed and consistent with observable trends, though not rigorously quantified in the talk.
PLAUSIBLE — “Your readers can now pattern match AI in just half a second” is a rhetorical estimate rather than a verified cognitive finding.
PLAUSIBLE — The discussion of “signal distortion” through management layers, marketing adaptation, or AI rewriting is credible as an organizational/product-design observation, but it is conceptual rather than empirically demonstrated.
UNVERIFIED — The anecdote that rewriting a YC startup’s pitch immediately converted conversations into pilots is a self-reported consulting success story that cannot be independently confirmed from general knowledge.
PLAUSIBLE — The warning that benchmark claims like “94%” can become overgeneralized marketing promises is consistent with real issues in AI evaluation and product communication.
TRUE — Trust in products and organizations is difficult to quantify with a single benchmark and often develops through repeated reliable interactions; this aligns with established thinking in psychology, UX, and business.
MISLEADING — “Trust is the one thing that's left with no grader” is philosophically evocative but overstated; trust can be partially measured through surveys, retention, reputation metrics, and behavioral signals even if imperfectly.

Verdict: The talk is largely a strategic and philosophical argument about AI-era product development rather than a fact-heavy presentation; its historical references and broad AI claims are mostly plausible or true, while specific benchmark improvements, startup anecdotes, and sweeping statements about AI convergence remain unverified or rhetorically overstated.

Read original →

Tribal Dungeons of Global Shipping: AI Agents at Global Scale — Dmitry Buykin, Maersk

Sun, 30 Aug 2026 00:30:21 +0000

Dmitry Buykin of Maersk described the challenge of deploying AI agents in global shipping, where complex operational workflows depend on many interconnected systems. He focused on handling exceptions safely, translating expert procedures into machine-readable processes, and integrating agents with legacy infrastructure.

Narrative

Global Shipping as a Network of Exceptions

Dmitry Buykin frames the talk as a report from production work supporting global shipping operations. He skips introductory material about AI agents and focuses instead on what most demonstrations avoid: turning messy operational knowledge into something an agent can execute safely.

He explains that a shipment may look like a single workflow on paper, but in practice it behaves like many parallel state machines operating together. Happy paths are often already automated. The real operational burden comes from the “long tail” of exceptions, where one drifting process breaks the larger flow and requires experts to coordinate across multiple incomplete systems. According to Buykin, this is where the cost and complexity live.

“Tribal Dungeons” and the Limits of Traditional SOPs

Buykin calls this challenge “tribal dungeons.” The knowledge exists inside organizations, but not in a form an AI agent can safely execute. Standard operating procedures, or SOPs, are common in regulated industries, but they are typically designed for humans rather than machines.

Legacy SOPs often consist of screenshots and click-by-click instructions. Buykin argues that screenshots are not processes. An agent-ready SOP must include preconditions, decisions, identifiers, backend calls, validation logic, recovery paths, and evidence that execution succeeded. In his formulation, “experts own the what, agents own the how.”

Much of the work becomes translation and negotiation between operational experts and engineers. The challenge is not simply building tool-calling agents, but aligning human operational knowledge with executable systems and safety guarantees.

The Architecture Around the Agent

Buykin describes the system architecture as having three major parts: an SOP memory corpus, an execution runtime, and a feedback capture layer. He stresses that the agent loop itself is not the real system. The refining loop around the agent is the system, and it is also the hardest part to build.

The SOP corpus becomes a kind of organizational memory. Different countries and operational environments describe the same concepts differently, creating large variations in process logic. Buykin says the corpus is far larger than the runtime itself, describing the relationship as roughly 20-to-1.

The production environment operates at substantial scale, with more than 200 concurrent instances running. Latency ranges from a few minutes to as much as ten minutes, largely because the agents depend on slow legacy systems. He notes that the bottleneck is often expert time rather than model inference.

Observability, Corrections, and Production Quality

The system uses what Buykin calls a “theme bench” to triage failures. Instead of presenting isolated errors, it clusters failures into actionable groups. Shared traces allow experts and engineers to inspect the same case and agree on what happened.

He emphasizes that a correction only matters when it becomes an executable change in the system. That distinction separates opinions from production fixes. Quality does not emerge from “vibes” or simply deploying larger models. It comes from replaying real examples against production-safe environments with disabled write permissions and measuring whether behavior improves.

Buykin presents a breakdown of effort across the project and argues that many modern development approaches stop too early. “Vibe coding” and spec-driven development can only improve accuracy to a limited point at this operational scale. The difficult work begins afterward: debugging, correction loops, and systematic refinement grounded in software engineering practices developed over decades.

Scaling Through Incremental Improvement

The system accumulated more than 100,000 corrections over nine months of development. Buykin describes accuracy not as something designed upfront in a diagram, but as something earned through countless small fixes.

Heat maps built from thousands of traces help teams prioritize work. Turning a single problem block from red to stable can require one or two months of effort from engineers and AI agents working together. Failures are treated as the beginning of investigation rather than the end.

He argues that production systems require constraints. Discovery may require agent freedom, but production requires what he calls “a cage.” The purpose of the harness is not to give agents more room, but to make dangerous mistakes impossible. Different classes of failure map to different controls, including workflow checks, classifiers, gates, and human review.

Review and approval remain part of the loop, especially for critical paths. The engineering focus is on building trustworthy handoffs and auditable trails.

AI-Native Operations and Compound Learning

Buykin says the most important outcome was not the individual agent system, but the methodology built around it. He summarizes the approach in five principles: make work representable, make execution bounded, make behavior observable, make correction cheap, and make improvement compound over time.

For him, AI-native operations are not just workflows with agents attached. They are systems that continuously learn from successful execution and fold those lessons back into reusable tools and code. The architecture itself becomes the strategic asset.

Successful step sequences are aggregated into larger composite tools that other agents can reuse. Once proven, these workflows can be rolled out across hundreds of countries simultaneously instead of remaining isolated local solutions.

Why Maersk Avoids MCPs

In closing, Buykin warns against becoming emotionally attached to tools or standards such as MCPs. He says his team does not use MCPs because they are often not the best choice for large operational systems.

According to him, enterprise systems are typically bloated, so his team distills responses and tunes tools through function calling instead. That tighter control allows them to maintain software quality and ensure tasks are processed correctly.

He ends the talk by thanking the audience and inviting further questions afterward.

Fact-check

PLAUSIBLE — Large global shipping operations do involve many parallel workflows and exception-handling processes across legacy systems; this is consistent with enterprise logistics and supply-chain software realities.
TRUE — Standard Operating Procedures (SOPs) in regulated industries are often written for human operators and are difficult to convert directly into machine-executable workflows.
PLAUSIBLE — AI agents interacting with enterprise systems generally require safeguards such as constrained tool use, validation, audit trails, and human review to operate safely in production.
PLAUSIBLE — In enterprise AI deployments, the “long tail” of edge cases and exceptions is often significantly harder and more expensive to automate than common “happy path” scenarios.
PLAUSIBLE — Legacy enterprise systems can become the primary latency bottleneck in automation pipelines, leading to multi-minute execution times even when AI inference itself is fast.
PLAUSIBLE — Human expert review and iterative correction loops are widely considered important for improving reliability in production AI systems, especially in high-risk operational settings.
PLAUSIBLE — Replay-based evaluation using historical traces or disabled-write “sandbox” modes is a recognized software engineering practice for validating automation changes before production deployment.
UNVERIFIED — The speaker claims the system currently runs “over 200 instances” in production with latencies ranging from minutes to 10 minutes; these are organization-specific operational metrics that cannot be independently confirmed from general knowledge.
UNVERIFIED — The statement that the team processed “over 100,000 corrections over last 9 months” is a self-reported internal metric that cannot be verified here.
PLAUSIBLE — Clustering failures and using heatmaps or trace analysis to prioritize engineering work aligns with common observability and incident-management practices in large-scale software systems.
PLAUSIBLE — The claim that “production needs a cage” reflects a standard safety principle in AI engineering: exploration-oriented systems usually require strict constraints and approval mechanisms in operational environments.
MISLEADING — The implication that “spec-driven development” or typical coding-agent workflows “cannot grow improve accuracy more than this stage on this scale” is presented as broadly true without evidence; this is more an opinion or organizational experience than an established fact.
PLAUSIBLE — Aggregating successful workflows into reusable composite tools for broader deployment is consistent with current enterprise automation and agentic-system design patterns.
PLAUSIBLE — Avoiding generic Model Context Protocol (MCP) integrations in favor of custom function-calling layers can be a reasonable engineering tradeoff for tighter control, latency, or output normalization, though it is not universally superior.

Verdict: The talk is broadly credible as an experienced engineering discussion about deploying AI agents in enterprise logistics, and most claims align with known software engineering practices; however, the scale figures, operational metrics, and claimed outcomes are self-reported and remain unverified.

Read original →

Agentic Sites: Building Hyper Personalized Websites — Carlos Sanchez, Adobe

Sun, 30 Aug 2026 00:00:17 +0000

Carlos Sanchez of Adobe presented AI-driven websites that adapt content in real time based on user intent and behavior. The system combines edge-based content delivery with large language models to increase personalization, engagement, and conversions.

Narrative

Building “Agentic Sites” for Hyper-Personalization

Carlos Sanchez, a principal scientist at Adobe working on Adobe Experience Manager, describes a project focused on “agentic sites,” which he frames as hyper-personalized websites driven by AI. The goal is to understand a visitor’s intent in real time: what they are trying to do, what they want to buy, or what information they are seeking. Based on those signals, the site dynamically adapts itself to improve engagement and conversions.

Rather than generating an entire website from scratch, the system personalizes specific sections of a page. Sanchez explains that marketers still require strict brand consistency, so the approach avoids unrestricted generation that could introduce hallucinations or off-brand content. Instead, the system customizes selected content blocks while grounding the output in the existing website content through retrieval-augmented generation, or RAG, which uses the site itself as a knowledge base.

The Stack Behind Real-Time Personalization

The implementation uses Adobe Experience Manager Edge Delivery Services, where content is served from the edge for speed, combined with backend AI services connected to different large language model providers. Sanchez says the team experimented with several providers, including Amazon Bedrock, but highlights Cerebras because of its inference speed.

The frontend is composed of reusable “blocks” that can be rearranged or rewritten in real time. Depending on the user persona or inferred intent, the AI changes hero sections, product recommendations, blog feeds, navigation, and calls to action. Sanchez emphasizes that the system is designed to spare marketers from manually authoring thousands of page variations. Instead, marketers define personalization strategies in natural language, while analytics continuously feed data back into the personalization loop.

Measuring Accuracy and Speed

A major challenge, Sanchez explains, is selecting the right model for each website. The team continuously evaluates prompts and models because performance depends heavily on the nature of the site itself: the size of the content corpus, the type of products, and the domain.

To automate evaluation, the team uses Promptfoo, a framework for testing prompts across multiple models and providers. Sanchez says they optimize for two metrics simultaneously: output quality and latency. Accuracy matters, but speed is critical because page generation must feel instantaneous to users.

He presents benchmark results showing Google’s Gemma 4 model running on Cerebras hardware generating pages in roughly 1.1 seconds on average, compared with alternatives taking more than four seconds. According to Sanchez, the use case does not require extremely large models because the task is mostly about assembling and organizing content blocks rather than producing deeply complex reasoning.

Capturing User Intent Through Browsing Signals

The personalization engine continuously records browsing behavior. Signals include visited pages, time spent on each page, and inferred intent categories such as “exploring,” “buying,” or “researching.” These signals are then passed into the language model.

The AI uses those signals to tailor page composition and recommendations. Sanchez describes a “For You” page that can be pre-generated while the user browses, making recommendations immediately available. He notes that pre-generation introduces cost considerations because multiple LLM calls may be needed as the user continues navigating.

Search queries also become personalization opportunities. When users search within the site, the AI groups those searches into broader personas or intent categories. Marketers can define these groupings and determine how different customer types should be treated. The system then dynamically selects content blocks, recommendations, and even media assets based on those categories.

Dynamic Content Generation in Practice

Sanchez demonstrates the concept using a fictional coffee-machine website. As he browses products and stories, a debugging interface tracks behavioral signals and categorizes him as an “exploring” user. The system records page visits and dwell time, making that information available to the model.

He then searches for a coffee machine suitable for camping. In response, the system generates a custom page on the fly. The hero text changes to focus on making coffee outdoors, and recommended products shift toward portable machines better suited for camping trips.

The generation speed is central to the demo. Sanchez shows backend metrics indicating total page generation times close to one second using Cerebras with Gemma 4, producing roughly 2,300 tokens per second. He remarks that this level of responsiveness “was something we only dreamed about before.”

Generating Agentic Sites Automatically

The team also built a tool called “OfOneLabs” that can create an agentic version of an existing website automatically. By entering a URL, Sanchez says the system can produce a personalized AI-driven site experience in less than an hour.

He demonstrates this with an AI conference website. Search suggestions themselves are AI-generated, and searches produce dynamically assembled pages tailored to the user’s interests. One example creates a side-by-side comparison between conferences, helping a visitor evaluate alternatives quickly.

Sanchez sees this as part of a broader shift in how users may interact with the web. He imagines a future where a user speaks a request through a personal assistant or a TV interface and receives a fully personalized visual experience without needing a phone or traditional browser navigation.

A Future of Faster, Cheaper Personalization

Sanchez closes by arguing that this kind of personalization is now technically feasible and improving rapidly. Models are getting faster and cheaper, making highly individualized web experiences practical at scale.

The core idea, he says, is intent-driven assembly: understanding what a user wants in the moment and constructing a page specifically for that need. As inference speeds continue to improve, he expects these personalized experiences to become increasingly common across websites and other digital interfaces.

Fact-check

TRUE — Adobe Experience Manager (AEM) is a real Adobe enterprise content-management platform widely used by large brands for websites and digital experiences.
TRUE — Real-time website personalization based on user behavior, browsing history, or inferred intent is an established practice in web marketing and e-commerce.
PLAUSIBLE — Using retrieval-augmented generation (RAG) over a website’s existing content to generate grounded personalized page sections is technically feasible and aligns with current AI application patterns.
TRUE — Marketing organizations commonly enforce strict brand and content guidelines, which is one reason many AI systems constrain generation to partial page components rather than fully AI-generated sites.
TRUE — Faster page loads are strongly associated with improved user engagement and conversions; this is well-established in web performance research.
TRUE — Promptfoo is a real open-source tool used to evaluate prompts and compare LLM outputs across providers and models.
PLAUSIBLE — Different websites and use cases can require different model/provider choices depending on latency, quality, cost, and context-window needs; this is consistent with current AI engineering practice.
UNVERIFIED — The specific benchmark claim that Cerebras running Google’s Gemma model generated pages in roughly 1.1 seconds with ~2,200–2,300 tokens/second cannot be independently confirmed from general knowledge alone, though Cerebras is known for emphasizing high inference throughput.
TRUE — Smaller or mid-sized language models can be sufficient for structured tasks like selecting content blocks, rewriting copy, or lightweight personalization workflows.
PLAUSIBLE — Grouping users into inferred “personas” or “intent types” from browsing behavior is a standard personalization approach, though accuracy and usefulness vary substantially by implementation.
PLAUSIBLE — Pre-generating recommendation pages or personalized experiences asynchronously for active users is a practical engineering optimization strategy.
PLAUSIBLE — Dynamically personalizing navigation, calls-to-action, and product recommendations with AI is technically feasible and already explored in commercial experimentation systems.
UNVERIFIED — The mention of a “nano banana light” image model announced “today or yesterday” cannot be verified from training knowledge and may refer to a very recent or internal product nickname.
PLAUSIBLE — Generating personalized image assets on the fly is technically possible with modern diffusion or multimodal models, though maintaining brand consistency remains a major challenge.
TRUE — Vector databases, edge delivery/CDN layers, inference services, and browser telemetry are common components in modern AI-powered web architectures.
UNVERIFIED — The claim that their internal tool can generate an “agentic site” for arbitrary URLs “in less than an hour” is a product-specific performance assertion that cannot be independently verified.
PLAUSIBLE — AI-generated side-by-side comparisons for products, conferences, or services are technically feasible and increasingly common in search and shopping experiences.
PLAUSIBLE — Voice-driven personalized interfaces on TVs or assistants are realistic extensions of current multimodal AI systems, though broad consumer adoption and reliability remain uncertain.
MISLEADING — The statement that hyper-personalized AI websites are “now possible” and will “only get better, cheaper, and faster” reflects a common industry trend but overstates certainty; progress is real, yet costs, privacy constraints, hallucinations, legal risks, and UX quality remain unresolved challenges.

Verdict: The presentation is broadly credible as a forward-looking demo of AI-powered website personalization using current techniques like RAG, telemetry, and LLM orchestration, but many performance metrics, product capabilities, and recent model references are self-reported or too recent to independently verify.

Read original →

Agents Are Where Microservices Were in 2015 — Roberto Milev & Uday Kanagala, Navan

Sat, 29 Aug 2026 23:30:28 +0000

Roberto Milev and Uday Kanagala of Navan compared the current evolution of AI agents to the rise of microservices a decade ago. They argued that reliable agent systems require emerging standards for orchestration, runtime management, memory, and production-scale operations.

Narrative

From Microservices to Agents

Roberto Milev opens by comparing the current wave of AI agents to the rise of microservices around 2015. He argues that the industry is going through another major architectural transition, similar to the shift that produced Kubernetes, service meshes, and circuit breakers. Those patterns did not appear overnight; teams learned through years of production experience.

He applies the same lesson to AI systems. If a team cannot build a reliable single-agent loop, he says, it makes little sense to jump immediately into complex multi-agent orchestration. In his view, the industry is now converging on a reference architecture for production-grade agents, with common layers emerging around runtime infrastructure, memory, context management, observability, orchestration, and governance.

Runtime Infrastructure for Stateful Agents

Milev explains that traditional cloud-native systems were designed around stateless services, but agents behave differently. They maintain persistent sessions, carry context between interactions, and require isolation and lifecycle management that do not map cleanly onto standard API services.

Cloud providers have responded by introducing agent runtimes. AWS, Google Cloud, and Azure all offer their own approaches. Navan, which runs on AWS, uses AWS AgentCore runtime heavily but also built additional components itself, particularly around session persistence and rehydration. He notes that these runtimes are generally framework-agnostic, although providers naturally optimize for their own ecosystems.

Memory Beyond Basic RAG

The discussion then moves into memory systems. Milev describes retrieval-augmented generation, or RAG, as an early necessity because models cannot hold unlimited context. Over time, however, memory systems have become more sophisticated and layered.

He describes a pipeline that includes ingestion, extraction, consolidation, and retrieval. Memory evolves from short-term conversational context into longer-term semantic memory, along with episodic memory that captures successful or unsuccessful prior interactions. Navan again relies on AWS tooling but adapts it to fit its own production needs.

Context Management Through Skills

Context management remains a difficult problem even as context windows continue to grow. According to Milev, larger windows do not automatically solve the issue because excessive context can dilute an agent’s focus.

Navan addresses this by treating “skills” as units of context. A skill combines instructions, domain knowledge, and tool execution behavior. Skills can be independently tested, reused, and dynamically composed into larger workflows. The system starts with a narrow scope and progressively expands context only when necessary through metadata-driven disclosure. Milev says this approach helps agents stay focused while still allowing flexibility across domains.

Why Traditional Logging Breaks Down

Uday Kanagala takes over to discuss operational challenges. He asks the audience how many have seen an agent fail midway through a 20- or 30-step workflow without being able to understand why. Traditional logs, he argues, are no longer sufficient because agents generate enormous amounts of intermediate reasoning.

Instead, Navan intercepts decision points inside agent frameworks such as Claude. Hooks around pre-tool and post-tool execution allow the system to inspect decisions, emit metrics, block unsafe actions, and create traces that expose the agent’s internal flow. Kanagala says these traces provide much clearer visibility into where and why an agent becomes stuck.

The traces capture signals such as the agent’s current goal, the reasoning behind decisions, confidence scores, belief states, and tool usage. Confidence scores are especially important because they reveal whether an answer comes from direct evidence or inference. Inference-heavy responses can trigger human review or adjustment.

Testing Non-Deterministic Systems

Testing agents presents another challenge because their behavior is inherently non-deterministic. Kanagala contrasts this with conventional software engineering, where developers can usually explain exact execution paths and algorithms.

Agent systems do not follow fixed sequences. Even when pursuing the same objective, they may generate different chains of reasoning every time. Navan therefore evaluates agents through “trajectory evaluations,” measuring how effectively the system progresses from starting state to intended goal rather than expecting deterministic step-by-step replication.

Additional signals help classify regressions and identify where inferred reasoning may have introduced failures. Kanagala emphasizes that the team is still learning through operational mistakes and iterative correction.

Guardrails, Authorization, and Enterprise Governance

Governance becomes especially important when agents interact with sensitive enterprise systems. Kanagala explains that agents blur traditional identity boundaries because they can act autonomously on behalf of users.

A request such as booking a flight under a price threshold raises difficult authorization questions: is the purchase being made by the user or by the agent? Existing concepts like service accounts and user identities no longer fit neatly.

Navan applies guardrails before and after every tool call. These policy checks help determine whether an action should proceed and ensure fine-grained authorization decisions. Kanagala frames this governance layer as essential for enterprise AI adoption.

Single-Agent Versus Multi-Agent Architectures

The speakers return repeatedly to the debate between single-agent and multi-agent systems. Kanagala advises caution against overengineering distributed agent architectures too early.

Navan’s preferred pattern is a “single master” agent augmented with sub-skills and sub-agents that load progressively as needed. The central agent decides which capabilities belong in context and navigates workflows dynamically.

He also describes emerging patterns for agent-to-agent communication inside large organizations where teams maintain separate boundaries and systems. In these cases, protocols such as A2A (agent-to-agent) can establish contracts between agents in a way similar to APIs between services.

What Feels Solved — and What Does Not

Closing the talk, Milev reviews which layers of the stack appear mature and which remain unresolved. Runtime scaling and orchestration infrastructure are relatively advanced, he says, and memory systems are steadily improving alongside frontier language models.

MCP, or Model Context Protocol, has emerged as a de facto standard for tool invocation, and the industry is beginning to converge around common approaches. Observability and testing, however, remain incomplete. OpenTelemetry (OTEL) shows promise for tracing agent workflows, but adapting it fully to agentic systems is still an open question.

Cost management is another unresolved issue. Predicting token consumption, enforcing guardrails, selecting cheaper models for simpler tasks, and implementing fallbacks remain difficult operational concerns. Milev also highlights replay and debugging as major pain points because understanding agent behavior creates significant cognitive overload.

Despite the gaps, both speakers see rapid standardization underway. They point to evolving standards around MCP, OTEL, and agent-to-agent protocols as evidence that the ecosystem is gradually maturing. Milev closes by saying that the industry already understands many of the required building blocks — the remaining task is to continue building them.

Fact-check

TRUE — The software industry did undergo a major shift toward microservices in the 2010s, alongside growth in Kubernetes, service meshes, and circuit-breaker patterns.
PLAUSIBLE — The analogy that “agents are where microservices were in 2015” is an opinionated industry comparison, but it reasonably reflects the current early-stage fragmentation and tooling growth around AI agents.
TRUE — Large cloud providers such as AWS, Google Cloud, and Azure now offer managed AI/agent-related runtimes, orchestration, or agent-building services.
PLAUSIBLE — Agent systems are often more stateful than traditional stateless APIs because they maintain conversational context, memory, and long-running workflows.
TRUE — Retrieval-augmented generation (RAG) emerged largely to compensate for LLM context-window limits and improve access to external knowledge.
PLAUSIBLE — Long-term, episodic, and conversational memory are active architectural patterns in agent systems, though there is not yet a universally standardized implementation model.
PLAUSIBLE — Very large contexts can reduce model focus or increase irrelevant information exposure; practitioners commonly observe diminishing returns from excessively large prompts.
PLAUSIBLE — Structuring agent capabilities as modular “skills” with associated context and tools is a recognized design pattern, though there is no consensus best practice yet.
TRUE — LLM-driven agents are generally non-deterministic: the same input can produce different reasoning paths or outputs across runs.
TRUE — Observability and debugging are significantly harder for agents than for conventional software because of probabilistic reasoning chains and tool orchestration.
PLAUSIBLE — Hooking into tool calls, decisions, and intermediate reasoning states for telemetry and tracing is technically feasible and aligns with emerging agent observability practices.
PLAUSIBLE — OpenTelemetry (OTEL) is increasingly being adapted for AI/LLM tracing and observability, though standards for agent-specific telemetry are still evolving.
PLAUSIBLE — “Trajectory evaluations” and path-based assessment methods are discussed in AI-agent evaluation research, especially for multi-step reasoning tasks, but there is not yet a universally accepted methodology.
TRUE — Enterprise AI deployments do raise legitimate concerns around sensitive-data leakage, authorization boundaries, and governance.
PLAUSIBLE — Agent authorization models are more complex than traditional user/service-account models because agents may act autonomously on behalf of users.
PLAUSIBLE — Applying guardrails before and after tool calls is a common emerging safety pattern in agent architectures.
PLAUSIBLE — Many practitioners currently prefer simpler single-agent architectures before moving to fully distributed multi-agent systems, due to operational complexity.
PLAUSIBLE — Agent-to-agent communication protocols are actively being explored, though no single standard has fully stabilized across the industry yet.
PLAUSIBLE — MCP (Model Context Protocol) has rapidly gained industry attention as a way to standardize tool/model interactions, but calling it the definitive “de facto protocol” may be somewhat premature given the ecosystem’s immaturity.
TRUE — AI inference cost management and token-spend predictability are ongoing operational challenges for production LLM systems.
PLAUSIBLE — Routing tasks to cheaper models or using fallback strategies is a common and sensible cost-optimization approach in production AI systems.

Verdict: The talk is broadly credible as an industry-practitioner discussion of emerging AI-agent architecture patterns, but many claims are experiential or forward-looking rather than firmly established standards, and Navan-specific production scale, tooling details, and operational success metrics remain unverified.

Read original →

From Tokenmaxxing to Trusted Throughput — Mingsheng Hong, Ironclad

Sat, 29 Aug 2026 22:30:28 +0000

Mingsheng Hong of Ironclad discussed strategies for managing the growing cost of AI token usage inside organizations. He emphasized monitoring, governance policies, and dashboards that help teams optimize spending without encouraging wasteful competition.

Narrative

Why Token Spending Became a Leadership Concern

Mingsheng Hong, VP of Engineering focused on AI at Ironclad, opens by describing a growing problem across engineering organizations: AI token usage is becoming expensive enough that companies now need real policies, measurement systems, and optimization strategies around it. He references stories from companies like Amazon and Meta where engineers began informally competing over token consumption after usage dashboards became visible internally. In one extreme example, he mentions reports of companies accidentally spending hundreds of millions of dollars on cloud infrastructure in a single month.

Hong argues that dashboards are important, but they should not function as leaderboards. At Ironclad, the team treats usage dashboards more like smoke detectors. If certain teams or individuals are barely using AI tools, that may indicate an adoption issue worth investigating. But maximizing token consumption itself is not the goal, and organizations should avoid creating incentives that reward raw usage.

He frames the discussion specifically for teams that have already crossed the initial AI adoption hurdle. For organizations still trying to get engineers comfortable with AI coding tools, strict optimization efforts may come too early. Ironclad itself only recently reached the point where cost management became a serious operational concern.

The Human Side of AI Adoption

Hong says that after leadership pushes AI adoption from the top down, teams still need direct conversations with engineers who are hesitant or dissatisfied. Some developers, he explains, feel that AI has replaced the satisfaction of crafting software with the less rewarding task of reviewing low-quality generated code.

Instead of dismissing those concerns, he believes engineering leaders need to identify the technical work that still provides growth, ownership, and craftsmanship in an AI-assisted world. The challenge is not simply increasing adoption, but helping engineers maintain a sense of meaningful contribution.

Trust as the Core Metric

Ironclad builds AI systems for legal contracting workflows, helping lawyers and procurement teams review contracts, identify anomalies, and move agreements forward more quickly while controlling risk. In that domain, trust is critical.

Hong explains that customers often begin cautiously. A lawyer might upload contracts they already understand well, then test whether the AI produces accurate search results or reliable suggestions. Only after confidence builds do they expand into more advanced workflows like redlining or anomaly detection.

He draws a direct parallel between customer trust in AI products and engineer trust in AI-generated code. The objective, he says, is not minimizing token spend or enforcing austerity. The real goal is improving return on investment. Ironclad uses the term “trusted throughput” to describe the value generated when AI-assisted output is reviewed, validated internally, and ultimately succeeds in production for customers.

Measuring Cost Without Optimizing the Wrong Thing

The first step, Hong says, is straightforward: measure token usage and cost. Teams using a single coding platform may already have rich analytics dashboards available from vendors. Ironclad uses multiple tools, so the company built its own aggregation pipelines to correlate usage across systems and break costs down by team and individual engineer.

But he warns against jumping directly from measurement to cost cutting. ROI requires understanding both cost and value. Once organizations can observe both sides, they can identify bottlenecks and optimize intelligently.

He repeatedly cautions against turning dashboards into ranking systems. To explain the risk, he compares token usage to the classic software productivity metric “lines of code.” Most engineering organizations track lines of code, but few would argue that writing more code is inherently better. In many cases, deleting code is more valuable than adding it. Token consumption, he argues, should be treated similarly: important to observe, dangerous to optimize directly.

Defining “Trusted Throughput”

Ironclad’s thinking evolved through several generations of engineering metrics. First came tracking lines of code, which Hong considers inadequate. Then the company experimented with counting open pull requests, based on the idea that AI makes code generation dramatically easier.

Eventually the focus shifted to merged pull requests, since shipped code matters more than generated code. But even merged PRs vary wildly in importance. A tiny fix for a difficult concurrency bug may create far more business value than a massive block of boilerplate code.

To capture that nuance, Ironclad began assigning complexity scores to merged PRs. Hong says the company pragmatically uses AI models with carefully designed prompts to evaluate pull requests and estimate complexity using “t-shirt sizing” style categories. The system is still evolving, but the broader goal is to approximate the real value generated by AI-assisted development.

He then describes trusted throughput as combining three categories of validation:

Objective checks like test coverage, security scans, and safe deployment practices
Subjective human judgment through code review and design review
Real-world customer outcomes, including production stability, usability, and support issues

Only when all three align does Ironclad consider throughput truly trustworthy.

AI Shifts the Bottleneck to Code Review and CI/CD

One of Hong’s central observations is that AI has made pull request creation abundant. The bottleneck has therefore moved downstream into code review and CI/CD pipelines.

He warns against one tempting workaround: combining many changes into giant pull requests to avoid repeated CI runs. While this may reduce infrastructure strain, it increases human review burden and lowers review quality because attention becomes diluted across massive diffs.

Instead, Ironclad focuses on improving the review and testing systems themselves.

Using AI as the First Layer of Review

For code review, Hong advocates treating AI tooling as the first line of defense rather than a replacement for human reviewers. AI systems should catch simpler issues like formatting problems, style inconsistencies, or missing test coverage before a human ever sees the PR.

That allows engineers to spend their time on deeper concerns such as architecture quality, maintainability, and security design. Human reviewers still hold final accountability, but their effort is concentrated where judgment matters most.

Fixing CI/CD Friction

Hong says the rise of AI-generated code has significantly increased pressure on CI infrastructure because engineers now produce many more, smaller pull requests. If CI systems become slow or unreliable, developers waste time manually rerunning flaky tests or supervising retries.

Some engineers even create AI agents to babysit failing pipelines, but Hong notes that this workaround itself consumes additional tokens and often hurts morale.

Ironclad responded by investing more heavily in developer experience and platform engineering. The company prioritizes eliminating flaky tests and improving CI reliability. They track metrics such as the elapsed time from a PR being ready for submission to actually being merged, along with how many retries are required before tests pass successfully.

These measurements help identify where developer productivity is truly being lost.

Practical Guardrails for AI Usage

Toward the end of the talk, Hong outlines a pragmatic framework for managing token spend responsibly. Organizations should establish budgets, quotas, anomaly detection, and regular reviews so unusual behavior can be investigated quickly. But he emphasizes that metrics alone are insufficient; teams also need continuous learning loops where leaders refine policies based on real usage patterns.

He shares several optimization techniques Ironclad encourages internally. Engineers sometimes create “agentic loops” that repeatedly test and refine generated code automatically. To prevent runaway costs, these loops should always include hard limits on retry counts.

He also highlights prompt caching, where model vendors optimize repeated prompt prefixes. Structuring prompts consistently — placing stable system prompts first and variable content later — can improve efficiency.

Another key habit is context pruning. Long chat sessions accumulate large amounts of context, which increases token usage and may degrade model quality. Engineers should summarize and compact context regularly, although newer tools increasingly automate this process.

Build Versus Buy Decisions

Hong says Ironclad generally buys commodity infrastructure like IDE tooling and CI systems. But the company builds internally when workflows become highly specific to its engineering context.

One example is maintaining internal prompt playbooks for generating different categories of pull requests, such as small bug fixes, UI work, or refactoring tasks. Those prompts become reusable institutional knowledge that teams continuously refine.

The company is also exploring internally built “builder agents” that wrap tools like Claude Code, though Hong notes that the boundary between buying and building remains fluid as the ecosystem evolves.

Planning for the AI Development Era

Hong closes with three broad lessons from Ironclad’s experience over the past several quarters. Teams should learn continuously, plan ahead for downstream bottlenecks created by AI-assisted development, and study the mistakes and successes of others.

As code generation accelerates, organizations must think carefully about how review systems, CI pipelines, and developer experience will scale alongside it. And throughout the process, engineering leaders need better metrics that measure not just activity or cost, but trustworthy outcomes.

For Hong, the defining challenge of the current AI era is maximizing token ROI while maintaining engineering quality and customer trust.

Fact-check

PLAUSIBLE — AI coding adoption can shift engineering bottlenecks from code generation toward code review and CI/CD capacity; this aligns with common industry observations, though the talk presents it as experiential rather than rigorously measured.
UNVERIFIED — Claims about Amazon engineers informally competing on AI token usage dashboards and similar stories at Meta are anecdotal and not independently verifiable from the transcript alone.
UNVERIFIED — The reference to companies accidentally spending “$500 million on cloud oops within a month” is too vague and unsourced to confirm.
PLAUSIBLE — Tracking token usage by team or individual through vendor dashboards is technically feasible and widely done in enterprise AI tooling.
PLAUSIBLE — Using AI-assisted dashboards and pipelines to aggregate usage across multiple coding tools is a realistic engineering practice, though the implementation details are specific to the speaker’s organization.
TRUE — Lines of code are widely regarded as an imperfect productivity metric and can incentivize undesirable behavior if optimized directly.
PLAUSIBLE — Measuring merged pull requests instead of just opened pull requests is a more meaningful proxy for delivered engineering work, though still imperfect.
PLAUSIBLE — Not all merged PRs are equally valuable; complexity and business impact can vary substantially independent of code volume.
PLAUSIBLE — Using LLMs to estimate PR complexity with prompts and “t-shirt sizing” is technically feasible, but there is no established industry-standard validation that such scores reliably measure engineering value.
TRUE — Automated checks such as test coverage, security scans, and canary deployments are standard methods for improving software quality and deployment safety.
PLAUSIBLE — AI-based code review tools can reduce reviewer workload by catching simpler issues like style problems or missing tests before human review.
TRUE — Flaky tests and overloaded CI systems reduce developer productivity and are recognized problems in software engineering.
PLAUSIBLE — Smaller, more frequent PRs can increase CI load and operational pressure compared with larger batches, especially under heavy automation.
PLAUSIBLE — Encouraging excessively large PRs to work around CI delays can reduce review quality and increase risk; this reflects common engineering guidance.
PLAUSIBLE — Autonomous “agentic loops” that repeatedly run tests and attempt fixes can consume substantial AI tokens if left unconstrained.
TRUE — Prompt caching techniques used by some AI providers can reduce repeated processing costs when prompts share identical prefixes.
TRUE — Structuring prompts with a stable system prompt followed by variable user content is consistent with how prefix caching systems generally work.
PLAUSIBLE — Context pruning or summarization can reduce token usage and sometimes improve model performance in long-running chats, though effectiveness varies by model and implementation.
UNVERIFIED — Claims that tools like “Claude Code” automatically compact context in ways that consistently improve both token efficiency and output quality depend on vendor-specific implementations not independently established here.
PLAUSIBLE — Maintaining internal prompt libraries or playbooks for recurring engineering tasks is a common emerging practice in organizations adopting AI-assisted development.

Verdict: The talk is broadly credible as an experience-based engineering management discussion about AI-assisted software development, and most technical claims are plausible or consistent with common industry practice, but many examples, metrics, anecdotes, and ROI assertions are self-reported and remain unverified.

Read original →

Guardians of the State: An Air-Gapped AI Fortress for Consumer Data — Rachna Srivastava, DFPI

Sat, 29 Aug 2026 22:00:25 +0000

Rachna Srivastava of the California Department of Financial Protection and Innovation warned that generative AI is weakening traditional forms of digital trust through impersonation and synthetic identities. She outlined efforts to build secure, isolated AI systems to support fraud investigations and protect consumer financial data.

Narrative

Trust in the Age of Generative AI

Rachna Srivastava opens with a stark observation: by the end of the presentation, somewhere in the world, a life-altering decision will have been made based on AI-generated content. She argues that modern digital systems have always depended on invisible assumptions of trust. Seeing a face, hearing a voice, or viewing a signature traditionally implied that a real person stood behind them.

Generative AI, she says, has shattered those assumptions. AI systems can clone voices, generate synthetic faces, and impersonate people at a speed and scale that traditional criminal organizations could never achieve. In this environment, “seeing is no longer believing,” and the cost of deception has collapsed while the speed of deception has exploded.

Building Systems That Can Survive Court Scrutiny

Srivastava explains that she works for the California Department of Financial Protection and Innovation, whose mission is to protect the financial identities of California residents. When fraud occurs, the department investigates it, gathers evidence, and presents findings in court.

That legal setting shapes every technical decision. A defense attorney’s job, she explains, is to attack the credibility of the system itself. Because of that, every stage of the platform must be explainable, reproducible, and auditable. The agency cannot simply produce AI-generated conclusions; it must demonstrate exactly how those conclusions were reached and reproduce them later if challenged in court.

She emphasizes three core requirements: the data must remain secure, the system must evolve as fraud tactics change, and every result must remain available and reproducible for legal proceedings.

Why the System Was Built Offline

The team’s first major decision was to build the entire solution offline, in an air-gapped environment disconnected from the internet. Srivastava contrasts this approach with common industry practices built around cloud security.

Encryption, she notes, protects data at rest and in transit, but machine learning systems still need decrypted plaintext in memory during processing. Once data is decrypted, it becomes vulnerable to prompt injection and other attacks. Private cloud endpoints also fail to eliminate risk because cloud providers still control the underlying infrastructure, and under the U.S. CLOUD Act, government agencies may access cloud-hosted data without notifying the customer.

She is also skeptical of certifications such as FedRAMP and SOC 2, describing them as paperwork that has repeatedly failed to prevent breaches. For evidence that may later appear in court, she argues, the only defensible approach is an offline system.

The First Failure: Treating AI Like Magic

Initially, the team assumed the project would be straightforward. They downloaded an open-source model, created an isolated environment, added GPUs and prompts, and pushed live data into the system.

The platform collapsed within two hours.

Srivastava says the problem was not the model itself. The real issue was conceptual: the team had treated the model like a magical black box instead of part of a data pipeline. They expected the model to clean up messy inputs automatically.

To solve this, they separated responsibilities across different technologies. Kafka handled data ingestion, Spark handled data processing, and the large language model handled reasoning.

Kafka and the Need for Replayable Evidence

Kafka became essential for several reasons. Fraud traffic arrives unpredictably, often in large spikes during coordinated attacks, so Kafka buffered incoming events and delivered them downstream at a stable rate.

Equally important, Kafka preserved event ordering. In fraud investigations, the exact sequence of actions matters: when an account was opened, when transactions occurred, and how events unfolded over time.

But Srivastava says Kafka’s most valuable feature was replayability. Kafka allows investigators to rewind to the precise checkpoint where a decision occurred and replay the sequence of events. That replay capability becomes courtroom evidence because investigators can demonstrate exactly how the system arrived at its conclusions.

Cleaning Data Before It Reaches the Model

The incoming data was highly inconsistent: bank statements in multiple formats, screenshots, audio files, and fax documents. Feeding all of that directly into model memory produced hallucinations and unreliable output.

The team introduced Apache Spark to preprocess and clean the information on CPU clusters before sending it to the GPU-powered model. Once the data was normalized and condensed, the exact same model began producing dramatically better results.

From this, Srivastava draws a broader lesson: many AI problems are actually data engineering problems “wearing an AI mask.” She encourages engineers to solve those issues with data infrastructure tools rather than expecting the model itself to compensate for bad inputs.

Protecting Sensitive Information with Hardware Security

Even after cleaning the data, another issue emerged: model memory still contained sensitive information such as credit card numbers, bank account details, and Social Security numbers.

To address this, the team implemented a cryptographic vault based on SHA-256 hashing and a hardware security module. Sensitive values are converted into cryptographic hashes immediately upon entering the system, and the cryptographic key is physically attached to the server rack.

Srivastava stresses the physical nature of the protection. Even if someone obtained the stored data, they would still need physical access to the hardware in order to interpret it. Her takeaway is direct: when the stakes are high, trust hardware over software.

Scaling an Air-Gapped AI System

Load testing exposed another challenge. Cloud systems can scale elastically by spinning up additional infrastructure, but an isolated environment has fixed GPUs, fixed compute capacity, and limited VRAM.

The team realized they were using one large, expensive model for every task, from summarization to entity extraction to fraud-ring analysis. Srivastava compares this to asking a neurosurgeon to take every patient’s blood pressure.

The solution was a semantic router, which acts as a triage layer. Incoming requests are analyzed and routed to the smallest model capable of handling the task. More than 80% of requests, they discovered, could run on smaller and cheaper models.

Without adding GPUs, the system tripled throughput while reducing per-request processing costs by nearly 70%.

Learning Without Creating a Security Hole

The hardest challenge was enabling the offline system to learn about emerging threats without exposing it to attack.

Many organizations solve this with software firewalls, but Srivastava argues that configurations can always be misconfigured. Instead of trusting software settings, the team relied on physics.

They built a one-way data diode using a physically split fiber-optic cable. One side connects to the internet and transmits data inward using a laser transmitter. The internal side only contains a laser receiver. Because there is no outward transmitter, the system physically cannot send data back out.

This architecture guarantees one-way information flow into the isolated environment.

Quarantine Zones and Time-Traveling Evidence

All incoming data first enters a quarantine zone, where Spark validation jobs inspect every input before it can move into production. Once validated, the data is stored in Apache Iceberg, which Srivastava describes as a “time-traveled queryable immutable data store.”

That capability becomes critical years later when legal challenges arise. If investigators must defend a decision in court, they can return Apache Iceberg to the exact system state that existed when the decision was made. Instead of relying on vague AI explanations, they can present the actual historical state of the platform as evidence.

Trust as a Physical Property

Srivastava closes by arguing that this architecture extends far beyond fraud detection. She sees the same pattern applying to healthcare, banking, legal systems, and other domains where AI decisions must be trusted and defended.

Her central message is that trust cannot be added later as policy or branding. It must be built into the hardware, the physical infrastructure, and the architecture itself from the beginning.

In the long run, she says, people will not remember benchmark scores or the models that organizations trained. They will remember whether those systems could be trusted when it mattered most.

Fact-check

TRUE — Generative AI can convincingly clone voices, generate synthetic faces, and facilitate impersonation scams at much lower cost and higher scale than older methods.
TRUE — AI-generated audio/video can undermine traditional assumptions that seeing or hearing evidence is inherently trustworthy.
PLAUSIBLE — Fraud detection systems used in government or regulated industries often need explainability, auditability, reproducibility, and evidentiary integrity for legal proceedings.
TRUE — Standard encryption protects data “at rest” and “in transit,” but most conventional machine learning systems must decrypt data in memory during processing.
PLAUSIBLE — Prompt injection and related attacks can expose or manipulate sensitive data inside AI systems once plaintext data is accessible to the model runtime.
MISLEADING — Saying cloud-hosted data is inherently insecure because providers “own the disk” oversimplifies cloud security; major cloud systems use strong tenant isolation, customer-managed encryption, and legal/process controls, though cloud access risks and legal exposure do exist.
PLAUSIBLE — The U.S. CLOUD Act can in some circumstances compel providers to produce stored data under lawful process, including data stored abroad by U.S.-linked providers.
MISLEADING — “FedRAMP compliant” and “SOC 2 compliant” are not “just paper.” Certifications do not guarantee security, but they do require substantial operational and technical controls and independent assessment.
PLAUSIBLE — Highly regulated organizations may choose air-gapped or offline architectures to reduce attack surface and improve evidentiary control.
TRUE — Poor data quality and preprocessing are a major cause of weak AI system performance; many “AI problems” are fundamentally data engineering problems.
TRUE — Apache Kafka is widely used for buffering event streams, preserving event ordering within partitions, and replaying events for reproducibility and auditing.
PLAUSIBLE — Kafka replayability can support forensic reconstruction and legal defensibility, though courtroom admissibility depends on broader chain-of-custody and governance procedures.
TRUE — Apache Spark is commonly used for distributed preprocessing and transformation of large heterogeneous datasets before ML inference.
PLAUSIBLE — Cleaning and structuring inputs before inference can significantly improve LLM output quality and reduce hallucination-like failures.
TRUE — SHA-256 is a widely used cryptographic hash algorithm, and hardware security modules (HSMs) are commonly used to protect cryptographic keys.
MISLEADING — A SHA-256 hash alone is not reversible encryption. The description mixes hashing, tokenization, and encryption concepts in a technically imprecise way.
PLAUSIBLE — Physically securing cryptographic keys in HSMs can materially improve resistance to remote compromise.
TRUE — Air-gapped systems have finite compute capacity and cannot elastically scale like typical cloud infrastructure.
TRUE — Routing simpler tasks to smaller models can substantially reduce inference cost and increase throughput.
UNVERIFIED — The specific claim that “more than 80%” of tasks could be handled by small models, yielding “three times more traffic” and “70%” lower processing cost, is a self-reported performance result that cannot be independently confirmed here.
PLAUSIBLE — Semantic routing or model cascades are established architectural patterns for improving efficiency in AI systems.
TRUE — Data diodes are real hardware devices designed to enforce one-way data transfer, commonly used in high-security environments.
MISLEADING — A data diode does not provide a literal “100% guarantee” of security; it can strongly reduce exfiltration risk, but overall system security still depends on software, operational controls, physical security, supply chain integrity, and human factors.
TRUE — Quarantine/validation layers for untrusted inbound data are standard security practices.
PLAUSIBLE — Apache Iceberg supports immutable-style table snapshots and time-travel queries useful for audit and reproducibility workflows.
PLAUSIBLE — Snapshotting data state can help reconstruct how a system produced a decision at a given point in time, though reproducibility of AI outputs may also depend on model versions, prompts, randomness settings, and infrastructure state.
MISLEADING — The statement that “trust is a physical property of the system” is philosophical rather than factual; trustworthy systems also depend heavily on governance, procedures, software assurance, and human oversight.

Verdict: The talk is broadly credible on modern AI-security architecture concepts, event-stream processing, data engineering, and high-assurance system design, but it overstates some security claims, simplifies cloud/compliance tradeoffs, and includes several self-reported performance metrics and architectural guarantees that remain unverified.

Read original →

The Half Life of Agent Infrastructure — Ben Kus, Box

Sat, 29 Aug 2026 21:30:22 +0000

Ben Kus of Box discussed how AI infrastructure must adapt rapidly as enterprise systems scale to billions of files, millions of users, and trillions of AI tokens. He argued that organizations should design flexible architectures that can evolve alongside fast-changing AI technologies.

Narrative

Enterprise Scale and the New AI Reality

Ben Kus, CTO of Box, frames the discussion around enterprise software at massive scale. Box manages more than an exabyte of data, serves tens of millions of users, and handles hundreds of billions of pieces of unstructured content. The newest scaling metric, he says, is tokens, with Box already operating in the range of trillions of tokens and expecting that number to climb rapidly.

He explains that most of his career has been spent building enterprise systems through several major technology shifts: the rise of the internet, mobile computing, cloud infrastructure, and now AI. In each era, large companies either adapted or faded, while startups used the disruption to challenge incumbents. Kus speaks from experience, having founded startups that were later acquired by IBM and Box.

The Traditional Playbook No Longer Holds

For years, Kus says, the standard advice for technology organizations was straightforward: choose a strong technology stack, build scalable and reliable systems, optimize them over time, and avoid unnecessary migrations because switching infrastructure is painful and risky.

That approach worked across earlier platform shifts because the underlying technologies stabilized. The internet still runs on HTTP, mobile platforms are still centered on iOS and Android, and database technologies can remain relevant for decades. AI infrastructure, however, behaves differently. Nearly every layer of the stack is changing simultaneously and at a much faster pace than previous eras of computing.

According to Kus, the problem is not that current approaches are wrong. The problem is that they become outdated quickly.

How “Best Practices” Keep Expiring

Kus revisits a presentation he gave a year earlier about graph-based agent architectures. At the time, he believed structured workflows built around large language models represented the right direction for AI agents. Many others agreed, and attendees told him the approach solved problems they were struggling with.

But since then, newer methods have overtaken that design. He uses this experience to illustrate the broader issue: AI engineering techniques now evolve so quickly that last year’s leading practice may already feel obsolete.

He walks through several examples. Model strategies shifted from training custom models, to fine-tuning frontier models, to using hosted APIs from OpenAI, Anthropic, or Google Gemini, then toward open-weight models, and now toward adaptive model selection systems that dynamically choose between models based on the task.

Agent design has changed just as rapidly. Developers first treated a single LLM call as an “agent,” then embraced chain-of-thought prompting, graph-based orchestration, planning agents, recursive agents with reusable skills, coding sandboxes that let agents execute code, and eventually systems that allow users to bring their own orchestration harness entirely.

Even retrieval systems have gone through multiple cycles. Keyword search gave way to retrieval-augmented generation using embeddings and vector search, which then evolved into hybrid retrieval approaches combining lexical and semantic search. Kus says some teams now believe intelligent agents themselves may outperform traditional retrieval systems because agents can reason about how to locate information.

The Half-Life of AI Infrastructure

Kus compares AI infrastructure to more traditional systems like databases or cloud storage. In older infrastructure domains, organizations might reevaluate technology every three to five years. With AI systems, he argues, the “half-life” may be measured in months.

That acceleration creates pressure everywhere. Engineers dislike seeing newly learned systems become outdated almost immediately. Startups that bet heavily on a single approach may find themselves overtaken by newer methods. Enterprise buyers risk locking into vendors or architectures that could become irrelevant before long-term contracts expire. Even venture capital firms can see entire categories disrupted within a year.

Kus says this pace of change is unlike anything he has seen before.

The Human Cost of Constant Rebuilding

Much of the challenge, he argues, is organizational rather than technical. Kus describes conversations with engineers who successfully implemented one generation of agent architecture, only to be told weeks later that the team would rebuild everything around a new approach.

One engineer completed a graph-based “deep research” system only to hear that the company wanted to move toward looping agent architectures instead. Later, after another rebuild and just before shipping the product, Kus informed the team that another redesign was coming.

The reactions were predictable: frustration, skepticism, and exhaustion. Engineers questioned whether any architecture choice would remain valid long enough to justify the effort. Kus acknowledges that this instability can damage morale and erode confidence if leaders do not handle it carefully.

Preparing Teams for Continuous Change

His first recommendation is cultural. Teams working in AI need to expect instability as a normal condition rather than a sign of failure. Kus repeatedly tells engineers that changing direction does not mean their earlier work was wrong. Nobody can accurately predict what the best approach will be six months from now.

At Box, the company now reevaluates AI technologies every six months regardless of how successful the current implementation appears. Kus admits this would sound irrational in most other areas of infrastructure, where systems are expected to remain stable for years.

He also advocates building abstractions that isolate changing components. Box created an internal agent abstraction layer so underlying models or orchestration systems can be swapped without disrupting the customer experience.

Use Evaluation Systems to Decide What Actually Matters

Although Kus encourages adaptability, he warns against chasing every new trend or research paper. Organizations need clear criteria for deciding when a change is worth the cost.

His answer is evaluation sets, or “evals.” Teams should create systems that repeatedly test the same inputs and measure outputs against metrics like quality, speed, cost, and capability. If a new architecture materially improves the results customers care about, then switching may be justified. If it does not, organizations should resist unnecessary migrations.

This provides a grounded way to navigate the constant flood of new techniques.

Choosing Vendors That Adapt Well

Kus’s final recommendation focuses on platform and vendor selection. Since no team can track every development in AI, organizations inevitably depend on outside providers.

Historically, he says, buyers mostly evaluated vendors based on their current capabilities and future roadmaps. Now he believes companies should also examine how vendors handled past waves of change. The best AI infrastructure companies, in his view, have already reinvented themselves multiple times in a single year.

That adaptability signals that the vendor understands agent architectures, evaluation systems, and observability tooling well enough to continue evolving as the field shifts again.

Adaptability as the Real Competitive Advantage

Kus closes with a prediction: many of tomorrow’s dominant AI companies already exist today, but the technologies they currently rely on will almost certainly change several times before they become market leaders.

The enduring advantage, he argues, is not commitment to any specific AI architecture. The real moat is the ability to adapt continuously as the landscape evolves.

Fact-check

PLAUSIBLE — Box reportedly operates at extremely large scale, and claims of “over an exabyte of data,” tens of millions of users, and massive token usage are directionally believable for a large enterprise content platform, though the exact figures are self-reported and not independently verifiable here.
TRUE — The internet still fundamentally relies on HTTP-based protocols, and mobile ecosystems are still dominated by iOS and Android.
PLAUSIBLE — The AI infrastructure ecosystem has been evolving unusually quickly compared with many prior enterprise technology waves; this is a broadly accurate industry observation, though not something measurable in a strict scientific sense.
PLAUSIBLE — Early agent systems often used chained prompts or graph/workflow orchestration approaches, while newer systems increasingly emphasize planning loops, tool use, recursive execution, and coding sandboxes.
PLAUSIBLE — Frontier models from companies like OpenAI, Anthropic, and Google Gemini often outperform smaller or self-trained models on many tasks, though open-weight models can be cheaper and competitive for some use cases.
PLAUSIBLE — “Adaptive model selection” (routing requests to different models based on cost/performance needs) is a real and increasingly discussed engineering pattern.
MISLEADING — The claim that embedding-based retrieval “almost mimics randomness as you keep going” overstates the limitations of vector search. Retrieval quality can degrade at scale or with poor embeddings/indexing, but modern vector databases and hybrid retrieval systems remain effective in many large-scale applications.
PLAUSIBLE — Hybrid retrieval combining lexical search and semantic/vector search is widely regarded as effective in production RAG systems.
PLAUSIBLE — Agentic retrieval/search systems can sometimes outperform simple RAG pipelines because iterative reasoning and tool use may improve retrieval quality, but this is still an active area of experimentation rather than settled best practice.
UNVERIFIED — References to “Opus 40 to Opus 45” as a pivotal technical transition are unclear and cannot be confidently mapped to established public model naming conventions from known vendors.
PLAUSIBLE — Improvements in model instruction-following and reasoning over the last 1–2 years have materially improved the viability of autonomous or semi-autonomous AI agents.
TRUE — GPU hardware has generally become more capable over time, and AI token consumption has increased dramatically industry-wide.
PLAUSIBLE — Many enterprises are experimenting both with centralized “one agent” approaches and with multi-agent/vendor ecosystems.
TRUE — Core infrastructure technologies such as relational databases, identity systems, and cloud storage architectures typically evolve more slowly than the current generative AI tooling ecosystem.
PLAUSIBLE — Migration costs in software infrastructure are often high and can introduce operational risk.
PLAUSIBLE — The “half-life” of AI agent infrastructure being measured in months is rhetorical but broadly captures the rapid iteration cycle in the current AI tooling landscape.
PLAUSIBLE — Building abstraction layers around AI providers and models can reduce vendor lock-in and ease future migrations.
TRUE — Evaluation datasets (“evals”) are widely considered important for comparing AI systems across dimensions like quality, latency, and cost.
PLAUSIBLE — Many AI tooling vendors have significantly changed or repositioned their products multiple times over the past year in response to rapid advances in the field.
UNVERIFIED — The prediction that future dominant companies already exist but will radically change their technical stack over time is speculative business forecasting, not a verifiable factual claim.

Verdict: The talk is largely credible as an industry strategy perspective on rapid AI infrastructure change, and most claims align with real trends in enterprise AI engineering, though many specifics are anecdotal, self-reported, or speculative rather than independently verified facts.

Read original →