Latest / Braid / When the Website Starts Offering Tools

Transcript

When the Website Starts Offering Tools · Braid

• 0:04
  lenar: A website today mostly waits for a person to understand it. You look at the page and infer what the button does. You fill out the form. If something goes wrong, the browser gives you cues: disabled states, validation text, layout, and maybe a suspicious spinner. Now put an agent in that seat. It can scrape the DOM, read the accessibility tree, look at screenshots, and click coordinates, but it’s still guessing its way through a surface designed for human eyes. Tara Agyemang’s AI Engineer talk for Google Chrome is about WebMCP, a proposed way for a site to say, more directly, here are the actions I support.
• 0:40
  damra: That’s a much more concrete starting point than another generic agent demo. The interesting part isn’t that an agent can click a button. We already know it can click the wrong button with great confidence. The change is that the website might expose a structured action surface, closer to a tool contract, so the agent doesn’t have to reverse-engineer intent from pixels.
• 1:01
  lenar: Right. And the caution from the agenda matters here: this is an early preview, not an adopted web standard. Tara’s LinkedIn post about the talk says the API is still in early preview and subject to change. So I don’t want to narrate this as the web turning into MCP overnight. The immediate developer question is smaller and more useful: if your product expects agents to use it, do you keep making them pretend to be clumsy users, or do you give them explicit affordances?
• 1:30
  damra: And once you do that, the product boundary changes. A checkout page, a support console, or a deployment dashboard stops being only a visual interface. It becomes a set of actions with names, parameters, and permissions. That helps automation, but it also forces teams to decide which actions are safe to expose and what the agent is allowed to know before it calls one.
• 1:53
  lenar: That’s the bridge into the rest of today. We have WebMCP on the interface side. We have Moonshot’s Kimi K2.7-Code release on the model side. We have same-day papers arguing that agent frameworks need their own containment tests. And then we have reminders from outside the model layer: Nvidia’s China-facing hardware story, humanoid robot supply chains, a court sanction over hallucinated legal citations, and an AUR package compromise. Friday, June 12, 2026, brings a set of practical boundaries into clearer view.
• 2:26
  damra: The WebMCP boundary is the most direct one. If the browser can ask a site for tool-like actions, builders get something better than screen scraping. But the moment you turn a website action into an agent-callable capability, you inherit all the old API questions: authentication, rate limits, audit trails, irreversible actions, and whether the agent is acting for the user or merely near the user.
• 2:51
  lenar: And there’s one subtle product effect here. A lot of web apps have hidden policy in the interface. The button is gray until three other fields are valid. The dangerous action is buried behind a confirmation. The page copy tells a human, in context, what they’re about to do. A structured tool surface can’t rely on that same spatial friction. It has to carry the policy in the action contract or in the runtime around it.
• 3:16
  damra: That’s where I’d get nervous as a builder. If the WebMCP layer only says, here are the actions, it may make the happy path cleaner while moving the risky path somewhere else. You still need to answer what happens when the agent asks for a refund, changes account ownership, exports a customer list, or schedules a wire transfer.
• 3:37
  lenar: Exactly. The best version of WebMCP isn’t agents clicking faster. It’s the web becoming more legible to software acting with a user’s authority. But legibility isn’t permission, and this is where today’s research cluster pulls against the excitement a little.
• 3:52
  lenar: Moonshot’s Kimi K2.7-Code showed up on Hugging Face today, and the Hacker News item around it presents the release around open-source coding performance and better token efficiency. I’m being deliberately plain about that because this isn’t a clean open-versus-closed scorecard. Open coding models are now good enough that developers compare them against paid coding agents on cost, reasoning tokens, latency, and local control.
• 4:18
  damra: The token-efficiency claim matters in practice. A coding model doesn’t only charge you for the final patch. It charges you for the plan, the failed attempt, the test output, the retry, the file reads, and all the invisible reasoning around the edit. If a model can reach a similar result with fewer thinking tokens, that’s a product feature, not a benchmark footnote.
• 4:40
  lenar: Yes, with the usual caveat: I wouldn’t take launch-adjacent benchmark claims as a buying decision by themselves. The Reddit item in today’s source set claims a 31.5 percent improvement on MLS Bench Lite, but it has no comments and isn’t community consensus. The safer read is that Moonshot wants this model judged on coding efficiency, not just raw benchmark rank.
• 5:03
  damra: And efficiency is where open models become annoying to incumbents. Not because every shop will run Kimi locally tomorrow, but because open artifacts give developers something to measure against. If your hosted coding agent is expensive, slow, or wasteful with context, a credible open model changes the negotiation.
• 5:22
  lenar: There’s also a workflow difference. A closed coding agent can bundle model, runtime, permissions, repository access, and review tools. An open model page gives you the model and leaves you to assemble the operating environment. That’s good if you want control. It’s less good if you need the system to remember which files it can touch, how it should run tests, and when it must stop.
• 5:44
  damra: Which is why I’d separate model capability from engineering utility. A strong open coding model can be valuable even before it replaces a packaged agent. It can sit in code review, local search, test generation, or offline repair loops. But when people compare it to Claude Code or Codex-style workflows, the runtime handles the parts users actually notice: file access, shell access, diffs, approvals, and recovery from failed tests.
• 6:13
  lenar: That’s the path from Kimi back to WebMCP. More capable models make agent interfaces more tempting. Cleaner interfaces make agent runs more reliable. But the surrounding system still decides whether any of this helps next week: what the model can touch, what it can remember, what it can spend, and what evidence it leaves behind.
• 6:32
  damra: And I’d add one more ordinary constraint: hardware. If Kimi is open but not practical on the machines a team actually controls, the comparison moves back to hosted inference. If it’s practical enough, then the cost conversation changes from API price to ops cost, throughput, and whether anyone wants to be on call for their own coding model.
• 6:53
  lenar: [chuckle] The glamour of local inference eventually becomes someone reading GPU utilization at midnight. But that’s a fair trade for some teams. The Kimi release is a reminder that the coding-agent market isn’t only a product race. It’s also a packaging race around models that keep getting easier to substitute.
• 7:12
  lenar: The lead agent-safety paper in today’s sources audits LangChain, AutoGPT, and the OpenAI Agents SDK against six containment principles. Its abstract says the authors don’t observe native compliance in any of the three frameworks. The concrete experiment is a simulated government benefits agent, where one poisoned memory write pushes targeted wrongful denials to 88.9 percent in the tested setting.
• 7:39
  damra: That’s a sharp claim, so it needs the paper’s own limits beside it. The empirical validation is on a LangChain simulation, while the framework audit covers three systems. The authors also say their lightweight validator is fragile against adversarial natural language and that compound attacks still need trajectory analysis. So this isn’t a universal indictment of every deployment. It’s a useful warning about where the breakage sits.
• 8:05
  lenar: The breakage sits between the model and the world. The paper’s six principles are reasoning-execution separation, capability scoping, memory integrity, validation at layer transitions, authenticated communication, and runtime monitoring. Spoken more plainly: the agent shouldn’t execute every plan it can imagine, shouldn’t have unbounded tools, shouldn’t write untrusted content into long-term memory, and shouldn’t rely on one input filter at the front door.
• 8:32
  damra: The memory part keeps pulling my attention back. Persistent memory is marketed as continuity, personalization, and less repeated context. But for an attacker, it’s also a write path into future behavior. If the agent retrieves a poisoned memory later, the user may never see the original injection that changed the answer.
• 8:53
  lenar: The supporting paper on Signed Memory with Smoothed Retrieval makes that threat model more formal. It calls the attack multi-session memory poisoning: a normal interaction writes something that persists, and later queries retrieve it as if it were trusted context. The proposed defense has two pieces. First, HMAC-SHA256 provenance tags at write time, so unsigned injection can be rejected. Second, randomized memory ablation with verdict-based majority aggregation, so one signed but adversarial memory has bounded influence.
• 9:27
  damra: That sounds more like security engineering than prompt engineering, which is the point. The paper reports unsigned attack success dropping from the 93 to 100 percent range to zero under the signing component. For authenticated attackers, the randomized retrieval component reduces attack success in their production-scale setup to 8 percent, with a stated bound of 10.4 percent for the evaluated setting.
• 9:54
  lenar: And there’s a practical lesson in their aggregation result. They argue that string-based majority vote can be gamed because malicious answers may be textually consistent while clean answers vary in wording. So the majority has to be on verdicts, not exact strings. That small implementation choice changes the behavior of the defense.
• 10:13
  damra: It also maps back to WebMCP. Suppose a site exposes a structured action surface and your agent has persistent memory. The clear interface reduces one class of brittleness, but it may make the memory problem more consequential because the agent can now act more reliably on bad remembered context.
• 10:33
  lenar: That’s the caution I’d put on today’s agent-web excitement. Cleaner tools are good. Explicit contracts are good. But the framework still needs to prove that a memory write, a tool call, and an action boundary are controlled separately. Otherwise the agent gets a better steering wheel without a better braking system.
• 10:51
  damra: And the multi-agent counterpoint in today’s sources belongs here too. One of the same-day papers challenges assumptions about multi-agent systems versus single-agent systems on performance and cost. I wouldn’t make that a main story without reading it deeply, but it fits the engineering mood: adding more agents or more framework layers doesn’t automatically buy you safety, quality, or lower cost.
• 11:14
  lenar: Yes. The deployment lesson isn’t anti-agent. It’s pro-measurement at the framework layer. If a team is building a public-facing agent, the model eval is only one test. They also need memory-write tests, tool-scope tests, policy-gate tests, and failure-path tests that show what the runtime does when the model is confident and wrong.
• 11:36
  lenar: Techmeme has two China-facing infrastructure items today. One says Nvidia is telling Chinese customers that Vera CPUs for AI data centers could be available as soon as August. Another points to Chinese manufacturers’ dominance in the humanoid robot supply chain. I’m keeping those as reported availability and supply-chain position, not as proof of demand or a single national plan.
• 12:00
  damra: That distinction matters. Chips, models, and robots are related, but they aren’t the same story. A CPU availability claim affects data-center buildouts. A humanoid robot supply-chain story affects motors, sensors, contract manufacturing, and whether anyone can make these systems at useful cost. The overlap is physical capacity, not a guaranteed product outcome.
• 12:25
  lenar: The Nvidia item is especially interesting because it comes after so much export-control and China-market pressure. The source frames it as Nvidia telling customers about Vera CPU availability. That’s not the same as confirmed shipments, and the policy environment can change quickly. But it’s still a reminder that AI infrastructure isn’t only GPUs. CPUs, networking, memory, power, and local availability all decide what can actually be deployed.
• 12:52
  damra: And the humanoid robot item is a useful counterweight to model-only thinking. A robot demo can be impressive, but the ability to source actuators, batteries, sensors, frames, and assembly capacity decides whether the demo becomes a product. China’s manufacturing base gives companies a different starting point there.
• 13:10
  lenar: Today’s sources also include a Reddit report about Huawei’s Open Pangu 2.0, with claims around a 512 thousand token context window and future open sourcing on June 30. I’d use that only as background today. It’s a Reddit gallery with no comments, and I don’t want to treat it as a primary release without a better artifact.
• 13:31
  damra: That restraint helps because the China-stack story can get over-smoothed very quickly. Chip access constraints, domestic model efforts, robot manufacturing strengths, and geopolitical incentives are related. Each one still has its own evidence standard.
• 13:47
  lenar: The practical question for developers is simpler than the geopolitics. Where will the cheap, available, well-supported compute and robotics capacity be? If Nvidia has a China-facing CPU path, if domestic models keep improving, and if robot hardware supply chains are concentrated in China, then product teams building embodied AI will make different assumptions about cost and sourcing.
• 14:09
  damra: And for software teams, this also affects the abstraction boundary. A robotics agent isn’t only a model plus a policy. It’s a model plus a device, parts suppliers, firmware, safety checks, repair loops, and a factory that can build version two after version one fails in the field.
• 14:27
  lenar: That’s why I like pairing this after the agent-safety papers. The papers ask whether the software framework can contain an agent. The infrastructure stories ask whether the physical system can be made, shipped, maintained, and restricted. Both questions decide whether AI leaves the demo environment.
• 14:44
  lenar: Forbes has a legal story today about a federal judge removing attorneys from both sides of a lawsuit after AI-generated legal citations appeared in court filings. Secondary reports say the case involved fines, two-year bars for two attorneys in that district, and a 60-day pause so the parties could find new representation. I’m taking those specifics from the reporting, not from the underlying order.
• 15:07
  damra: The careful version is that this isn’t a story about AI being useless for legal work. It’s a story about professional accountability when generated text crosses into a filed document. Courts don’t care that the citation looked plausible in a chat window. They care whether the authority exists and supports the claim.
• 15:26
  lenar: Exactly. And the supporting biomedical paper in today’s sources gives a better engineering answer than please be careful. The MedSci Skills paper argues that clinical manuscript generation needs verification gates: deterministic checks where possible, prose-level probes only where interpretation is unavoidable, and halt-on-failure transitions between stages.
• 15:47
  damra: Their seeded-defect result is the useful number. The deterministic gates caught all 27 injected defects with no false positives on matched clean fixtures. A generic single-prompt large language model reviewer caught 11 of 27. That doesn’t prove the toolkit writes great manuscripts. The authors say it’s feasibility and reproducibility evidence. But it does show why self-critique is the wrong tool for defects that require external checking.
• 16:15
  lenar: That’s the same pattern as the legal citation problem. A model can produce a citation-shaped sentence. It can’t, by fluency alone, prove that the citation exists, that the author list matches, that the quoted proposition is accurate, or that the filing satisfies the court’s duty of candor.
• 16:32
  damra: And in medicine the parallel is table-to-prose drift. A model can restate an effect estimate in a paragraph, but if the number no longer matches the source table, the prose may still sound authoritative. The paper’s architecture treats that as a checkable integrity question rather than a vibe for another model to review.
• 16:51
  lenar: There’s a nice phrase in the abstract: generation to verification. A lot of professional AI use is moving there. The first wave asked whether AI can draft. The second wave asks whether the draft can survive an audit, a judge, a journal reviewer, a compliance officer, or a patient-safety process.
• 17:09
  damra: And the audit doesn’t have to be fancy everywhere. Sometimes the best AI system is the one that uses no model for the boring check. Sorry, the ordinary check. [chuckle] Hash the table, look up the DOI, compare the number, verify the checklist item, and stop if the value drifted.
• 17:27
  lenar: That correction is exactly the house rule. The work isn’t important because we call it ordinary or unglamorous. It’s important because when it’s missing, the wrong case goes into a filing or the wrong number goes into a medical claim. The consequence carries the point.
• 17:42
  damra: And it makes the developer job more interesting, not less. The valuable system isn’t a wrapper that says write me a brief. It’s a workflow that knows which parts can be generated, which parts must be checked against an external authority, and which failures stop the process before a human inherits a polished mess.
• 18:00
  lenar: That’s a good place to put the court story. The sanction is the visible consequence, but the engineering lesson is upstream: high-stakes AI systems need proof paths that are boring only until you’re the person explaining a fake citation to a judge.
• 18:14
  lenar: The last item is outside the AI stack, and that’s why it belongs. A Hacker News story points to a report that hundreds of Arch User Repository packages were compromised with an infostealer and rootkit. The HN discussion is already doing the familiar Arch thing: reminding people that the AUR is user-maintained and that PKGBUILDs deserve inspection.
• 18:35
  damra: That’s a good reminder for agentic coding, because agents don’t run in a magic separate universe. They install packages, execute scripts, read tokens, touch dotfiles, and inherit whatever trust model the developer machine already has. If the local package path is compromised, the agent may simply become a faster way to exercise the compromise.
• 18:57
  lenar: Today’s sources also include a Techmeme item about a reported critical Oracle PeopleSoft flaw and breach claims. That’s a different security surface: enterprise applications rather than developer package helpers. But the shared lesson is that software risk keeps arriving through old doors while the AI world is staring at the new door.
• 19:18
  damra: And this connects back to Wednesday’s and yesterday’s agent-governance stories without repeating them. If an agent has shell access, browser access, repository access, and maybe credentials for cloud tools, then package provenance and enterprise patching are part of the agent’s safety environment. A model policy can’t compensate for a machine that already trusts the wrong install script.
• 19:40
  lenar: This is where I think developers should keep the altitude right. The AUR report isn’t an AI turning point. It’s a security incident in a developer ecosystem. But it changes the practical checklist for anyone letting agents operate on their machines: know where packages come from, isolate risky work, keep secrets away from broad shell sessions, and treat install steps as privileged actions.
• 20:03
  damra: The install step is a great example. A human may pause before piping a script into a shell. An agent may not, unless the runtime forces that pause. And if the runtime has learned that successful completion means make the tests pass, it may optimize straight through the moment where a human would read the package recipe.
• 20:22
  lenar: So the day ends with a stack of boundaries. WebMCP asks websites to expose clearer actions. Kimi asks whether open coding models can do more work with fewer tokens. The safety papers ask whether memory and tool calls are contained. The court story asks whether professional outputs can be verified. The package compromise asks whether the developer machine is trustworthy before the agent ever starts.
• 20:46
  damra: And none of those boundaries cancels the others. A better model doesn’t remove the need for a safer runtime. A safer runtime doesn’t remove the need for package hygiene. A structured web action doesn’t remove the need for audit logs. The systems that work will probably be the ones that make those separations visible instead of hiding them behind a single assistant button.
• 21:08
  lenar: That’s the specific thing I’d take into the weekend. If you’re building for agents, don’t only ask whether the agent can complete the task. Ask where the task becomes a tool call, where the memory gets written, where the human can inspect the evidence, and which part of the machine you’re trusting when the agent says it’s done. Lenar Kess.