One of the AI trends I'm following is recurrent reasoning. The main idea is to let the model do the reasoning in its own continuous latent space and avoid the inefficiencies of CoT reasoning, which forces the model to reason one token at a time and in a discrete space. We're seeing different forms of it (perhaps the most popular being the looped transformer that got a lot of attention after the announcement of GPT-6 Astra). BDH-CQ by @pathway_com combines the benefits of latent reasoning with in-context learning, which was previously only seen in autoregressive transformer models. The result is an AI model that can reason on novel tasks based on the given examples while being very compute efficient. The model set a new Pareto frontier on ARG-AGI-1, reaching 29.5% at $0.0007 per task with 150M parameters. And the researchers behind the model tell me that the prospects for scaling the model and working on other modalities are very positive. Worth following.

When you add a watermarking algorithm to your LLM, it's supposed to give you pretty much the same answer while leaving a trace/signature that you can later detect. This works well for text, but for AI agents, the watermark can result in significant change in behavior. A study by @LassoSecurity shows that adding watermarks to the backbone LLM can cause an AI agent to change the way it chooses tools, rejects bad requests, and its resilience against prompt injection. The aggregate results might remain the same, but the kind of requests it fails/succeeds at change significantly.

Politics, intrigue, and inter-lab rivalries are dealing a lot of damage to AI companies that depend on closed frontier models. While OpenAI might have scored a minor point against SpaceXAI by ending its patnership with Cursor, it has also set the precedent that makes it clear closed AI labs are not reliable. The correct strategy is to rely on open-weight models as the main engine of your applications.

When I stumbled on the "Stealing Reasoning Traces from Proprietary LLM APIs" study, my first thought as a software engineer was, why did they overlook one of the key basic security practices of any software, which is to avoid global encryption keys? And if you want to hide the reasoning traces, why even send them to the client and not just store them on your own servers? It turns out that there are many tradeoffs and no perfect answers. On the one hand, AI companies want to prevent distillation (hence the encryption) while on the other, they want to be able to reuse conversations across different models (hence using a single encryption key) and minimize client data storage on their servers (hence sending the encrypted reasoning trace to clients). Basically, they wanted to have their cake and eat it too. In practice, they ended up messing up a lot of stuff: - Smaller, less safe models could be passed the conversation history and prompt-injected to reveal the reasoning trace - Client-side data filters failed to detect sensitive data stored in the reasoning trace, resulting in a lot of API keys, plain passwords and other sensitive data being leaked in public repositories - And in the end, competitors could easily bypass the anti-distillation guardrail

AI security benchmarks mostly focus on models alone. But in practice, the model is deployed as part of a system, including the harness. A new study by @LassoSecurity shows how, all other things equal (including the model), the AI harness can have a huge impact on the security footprint of the AI system. This has direct implications for how you build applications as well as how you evaluate the security of your AI applications.

When your AI agent has thousands of skills/tools to choose from, stuffing all the skill details into the prompt is a non-starter. Passive skill retrieval is also not the solution. The key to managing hundreds of tools for your AI agent is to: 1) Decompose the task into atomic sub-tasks that each require one tool 2) Select the right tool for each sub-task and make sure tools are compatible 3) Create a DAG to execute the steps sequentially where required and in parallel where possible However, decomposing a task is easier said than done. For example, is an HTTP request one step or a sequence of ‘connect,’ ‘send the request,’ ‘receive the response,’ and ‘parse the response’? To solve this challenge, you need skill-aware decomposition (SAD), which uses the capabilities and boundaries of skills/tools to determine the granularity of each subtask. SkillWeaver and SAD are two techniques that can help scale AI agents to thousands of tools/skills.

There is a lot of promise and excitement in harness engineering for AI agents. The scaffolding that surrounds the LLM can have a huge impact on the speed, accuracy, and cost of your AI systems. However, harness engineering is a complex affair that requires a lot of manual work and experimentation. One solution is self-improving harnesses, an emerging field of research that enables AI agents to use the reasoning abilities of the backbone LLM to make modifications to its own scaffolding and improve its performance. The key to successful harness engineering is: 1) framing the problem in a way that makes it possible to optimize the harness in an AI loop, and 2) breaking the harness into distinct components that can be plugged into each other and composed like Lego bricks. I review two harness engineering frameworks, Self-Harness and HarnessX but there is a lot more to come. Keep an eye on this field.

There have been exciting advances in self-improving AI agents that optimize their own scaffold/harnesses by leveraging the coding/reasoning capabilities of the underlying LLMs. Nvidia's ASPIRE framework applies the same principle to robot control models, using a continual learning loop to improve the robot control program. ASPIRE runs tests, examines execution traces, rewrites Python programs, and builds reusable skills that robots can employ as they face new tasks/objects in the real world.