The Invariant when agents leave the chat box

Start with a term that keeps coming back. A proof assistant is a peculiar kind of programming language: you write not only code, but also a mathematical proof explaining why that code satisfies a specification, and the machine checks that proof line by line. Lean 4 is one of the most watched systems in this category right now. Its logic is unforgiving: if a proof checks, the claim is not "I tried many cases and nothing broke." It is "for every input covered by the specification, this conclusion holds."

The difference from testing is not a difference in diligence; it is a difference in worldview. Testing is like shining a flashlight through a warehouse: the spots you illuminate look clean, but the dark corners are still unknown. Proof is more like formalizing the floor plan, walls, locks, and every possible passage, then asking an uncompromising checker to say: this path cannot exist.

Formal verification used to be expensive. How hard is it to write Lean proofs? Many mathematicians and engineers can read a theorem or an algorithm, yet still struggle to turn it into a proof the machine will accept. Mistral's March release of Leanstral positioned it as the first open-source coding agent for Lean 4, aimed at proof engineering: not just generating code, but building formal proofs around strict specifications. Mistral named the bottleneck plainly: in high-stakes mathematics and critical software, manual verification has become impedance against engineering speed.

DeepMind's AlphaProof work follows the same line: it treats Lean as a verifiable environment in which an agent searches for formal proofs. AlphaProof Nexus, released in May 2026, pushes the work toward an open research problem; the report says a full-featured agent solved 9 of 353 formalized Erdos problems and released the Lean proofs.

What matters to me is not the scoreboard; it is the role problem those systems expose. A coding agent wrapped in a harness that can read and write files, run commands, and iterate through errors is genuinely better at pushing work forward. But pushing forward carries its own danger: it wants closure too badly, wants the red light to turn green. Give it an incomplete proposition and it may hide the hole inside an elegant structure, as if the job were done.

"Can do the work" and "can judge whether the work is valid" are separate abilities. Putting both inside the same agent that wants to finish is like letting the defendant serve as the judge.

Imagine a simple-looking request: build a weekly-report agent that automatically summarizes sales, customers, inventory, meeting notes, and produces a one-page report for management every Friday. The boss thinks this is just connecting a model to email, CRM, the warehouse, and the document library. Anyone who has built it knows it hits a wall in week one.

The customer is ACME China in the sales system, ACME CN Ltd. in contracts, and a translated name in finance. In meeting notes, sales says "that major account," customer success says "the East China renewal," and the boss says "that risk you raised last time." This is not model stupidity. Corporate reality is made of aliases, permissions, historical baggage, and lazy human shorthand.

Make it concrete. At 4 p.m. on Friday, the sales VP drops a request into chat: "Put ACME's renewal risk into the weekly report, and add the price resistance raised in the customer meeting." The agent works hard. It pulls the ACME China pipeline from CRM, finds the ACME CN Ltd. renewal date in the contract repository, extracts "East China pilot paused" from Teams notes, and pulls a group-level payment-term extension from finance. Ten minutes later, it writes a polished but dangerous sentence for management: "ACME Group renewal risk has increased; the East China pilot is paused; pricing negotiation is blocked."

What is missing is not writing ability. It is a company map: who is the parent company and who is the subsidiary; which project name maps to which account; which meeting note belongs to which opportunity; which financial fields can enter a management report under which permissions; whether a shorthand refers to a customer, a project, a region, or a sales person's pet phrase. Humans fill those holes with experience and gossip. Agents do not.

Microsoft's Work IQ is worth watching not because it adds a few APIs, but because it treats company context as agent infrastructure. The official framing is a workplace intelligence layer that lets agents access and reason over organizational data, context, and tools, with permission-aware governance built in. It puts chat, context, tools, and workspaces into one layer, giving long-running work a persistent space.

The most engineering-flavored design choice is that Work IQ MCP narrows the operation surface to roughly ten general tools, using getSchema at runtime so the agent can understand data structure. Permissions are not a pile of static OAuth scopes; a Rego-based policy engine evaluates each request by resource path, method, user identity, and data content, while recording every tool call.

A good agent is not one that can access everything. A good agent knows what it should access now, and which doors must never open.

Now a more dangerous composite case. A data-analyst agent receives a request: "Analyze complaint rates among high-value customers and identify the riskiest regions." It generates SQL and returns a result. The syntax is correct. The numbers are correct. Everyone thinks the job is done.

But to assemble the analysis, that SQL joins the customer transaction table, complaint table, health-rider fields, support notes, and an internal risk label. Taken separately, the agent has permission for each table. Combined, they become a sensitive profile ordinary business users should not see.

Put the scene inside an insurance operations team. A regional manager asks: "Among high-net-worth customers, which cities have abnormal complaint rates recently?" The agent's query is not absurd: filter the highest lifetime-value customers, join support tickets for complaints, join policy rider data to distinguish product type, then join an internal risk-label table to rank customers likely to escalate into public-relations issues.

The trouble is not syntax. First, health_rider exposes sensitive health-adjacent attributes. Second, post_claim_label is generated after claims, so using it to explain pre-claim complaint risk leaks the future. Third, slicing the report by city and product line creates cells with only two or three people; even without names, a frontline team may infer who they are. A regional complaint-rate report quietly becomes a mixture of health profiling, timeline leakage, and small-cell reidentification.

Traditional permission systems usually ask: "May you see this table?" The harder question in the agent era is: "You may see A and you may see B, but may you combine A and B this way? May the combined result be sent to this audience?"

That is the core of Data Flow Control: Data Safety Policies for AI Agents. The authors argue that agents increasingly generate SQL, orchestrate data pipelines, and run analyses automatically; a query being correct is not the same as being safe. Their DFC approach pushes policy down into the DBMS query layer and constrains record-level data flow. Passant, a portable query-rewriting layer, was tested on DuckDB, Umbra, PostgreSQL, DataFusion, and SQL Server, with the paper reporting roughly zero overhead.

Do not make the prompt responsible for all safety. If a rule can move down into the database layer, do not leave it inside a prayer that says "please do not leak private data."

Many agent projects go through an immature phase: the model makes a mistake, so someone adds a rule to the prompt. First: "Be careful with null values." Second: "Check grain before aggregation." Third: "Confirm the fiscal calendar when the user asks about fiscal year." A month later, the prompt looks like a refrigerator covered in sticky notes: "note," "be careful," "must ensure." Every sentence has a history, but the model does not know when to use which one.

I prefer turning experience into skills. A skill here is not mystical. It is a callable process card: when it applies, what tools to call, which preconditions to check, what common failures look like, and how to verify the result.

DataCOPE works on unsupervised skill discovery: letting a data-analysis agent discover reusable skills from its own exploration traces. Report-style analysis uses an Adaptive Checklist Verifier, while reasoning-style analysis uses an Answer Agreement Verifier. Averaged across four model settings, the paper reports a 9.71% improvement on report-style tasks and 32.30% on reasoning-style tasks.

SciVisAgentSkills moves the idea into scientific visualization: ParaView, napari, VMD, and TTK are not usable just because an agent can name them. The paper packages environment assumptions, tool-use patterns, and domain heuristics as skills, evaluates them on 108 expert-designed multi-step tasks, and emphasizes that skills must be evaluated together with the harness. In other words, skills are not magic words. They have to be loaded, cached, executed, and recovered correctly.

A prompt is a sheet of paper; a skill registry is an archive room. One gets stale. The other can file, promote, deprecate, and reuse.

Hugging Face adding MCP remote tools to Reachy Mini looks, at first, like a small piece of news: a desktop robot can now call remote tools such as weather and search through Hugging Face Spaces without changing the local app. The real story is the permission structure.

Reachy Mini's body tools, such as head turns, dancing, expressions, camera, and head tracking, stay local. Remote tools are installed into a profile as optional capabilities and enabled through tools.txt. The article has one very engineering sentence: tools.txt is the gatekeeper. In other words, the robot does not get to use a tool just because it sees one. It first passes through an explicit capability list.

Once this moves from the chat box into a robot, it becomes physical. A chatbot that misuses a weather tool gives a wrong answer at worst. A physical robot that misuses motion tools can knock over a cup, scare a child, or pinch a finger. The Hugging Face article is candid: a prompt can encourage parallel weather and search calls, but it cannot guarantee parallelism. If deterministic orchestration matters, move that logic out of the prompt and into code.

Holo3.1 and LeRobot Humanoid sit on the same line. Holo3.1 pushes computer-use agents toward local and mobile deployment: on AndroidWorld, the 35B-A3B model moved from 67% to 79.3%, with FP8, Q4 GGUF, and NVFP4 quantized weights for local inference. LeRobot Humanoid releases a low-cost, 3D-printable humanoid robotics learning platform; the current biped platform has a bill of materials around $2,500 and includes hardware, assembly documentation, runtime, recognition tools, and training environments.

Once AI leaves the screen, capabilities must be installable, disableable, auditable, repairable, and replaceable. Otherwise it is not a platform. It is magic.

Finance is one of the easiest domains for AI hallucination to seduce, because financial language already sounds like reasoning. A model says, "This factor captures the lagged response of earnings recovery and exhibits cross-sectional discrimination in low-volatility regimes." It sounds like investment research. It may also be high-end fortune telling.

Several financial-AI threads this week assemble the requirements for stage two. YouZhi-LLM focuses on high-concurrency financial reasoning. The paper argues that KV-cache memory costs limit deployment concurrency and cost for financial LLMs; YouZhi-7B improves average financial benchmark scores by 12.3% while raising maximum concurrency by 2.69x, and YouZhi-14B improves accuracy by 7.0% with 2.43x concurrency.

AlphaEval focuses on evaluating alpha signals. It is not satisfied with backtests and correlations alone; it evaluates generated alphas across five dimensions: predictive power, stability, robustness to market perturbation, financial logic, and diversity. FinBloom enters through real-time information: financial LLMs must handle news, prices, and filings that change constantly. It introduces a Financial Context Dataset with more than 50,000 financial queries and uses subsets of 14 million financial news items and 12 million SEC filings as training material.

A composite investment-research case: an automated alpha-mining system discovers a new signal, and the 18-month backtest curve looks like advertising. A real audit does not applaud first. It asks: was this order-flow field really available before the trade? Is the news-sentiment timestamp delayed? Is there enough small-cap volume? Were turnover costs counted? Why does the signal have economic meaning? Does it only work in one strange market regime?

The most dangerous thing in finance is not that the model cannot speak finance. It is that it speaks finance so well that you forget to force it to explain the timeline and mechanism.