TechTalks

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.

There's a lot of excitement around loop engineering for AI agents. But there is a clear difference between loop engineering and loopmaxxing. Loop engineering happens when you give your AI agent a clear, verifiable, and measurable goal, and let it iterate on its own output, analyze the feedback and adjust course to reach the goal. It usually results in increased productivity and visibility into how the AI agent works. Loopmaxxing happens when you don't put energy into designing the loop, give the AI agent a very vague and unverifiable goal, and hope that the underlying LLM will figure out how to do it. It usually results in the agent spiraling out of control and not achieving anything meaningful. Embrace the AI loops. Avoid the loopmaxxing.

This is something I've been thinking a lot about lately: Chain-of-Thought (CoT) is the wrong direction to focus on. We spend billions on training LLMs to generate CoT tokens, hoping that they learn to reason like humans. In reality, there are multiple problems with CoT: - It is not a proper reflection of the human thinking/reasoning process (@rao2z has some interesting papers on this) - It slows down inference and forces the model to "reason" (if that is what we should call it) one token at a time - It raises the memory/compute costs of inference on long-horizon tasks What is the right direction? I think the model should reason in latent space and only use text tokens when it needs to communicate with humans or document its artifacts. Some interesting directions: - HRM and HRM-Text by @Sapient_Int reduce the costs of training and inference on reasoning tasks. - RecursiveMAS by researchers at UIUC shows how multi-agent systems can increase speed and reduce costs by passing information in latent space. Latent space reasoning is not without its challenges, namely the lack of interpretability. My suggestion is hybrid systems that use causal models to create a step-by-step plan for solving a problem, expressed in textual tokens, and recursive reasoning models that carry out those steps. Read the full article below.

If you're using Cursor's Composer 2.5, you should know about one key limitation. The LLM was trained through self-distillation, where the same model acts as both the teacher and the student. Both models get the same prompt with the difference that the teacher gets additional context. This is a very effective and cost-efficient method for fine-tuning LLMs without the need to distill from expensive and larger teachers (e.g., Opus 4.7). However, one key limitation of self-distillation is that it trades efficiency for flexibility. A non-distilled model has more tendency to explore different solutions when it generates tokens that indicate uncertainty. Self-distillation, on the other hand, forces the model to create a highly confident answer in one go. What does it mean in practice? This works well for around 80% of everyday tasks, which are within the distribution of the model's training distribution. For edge cases and especially very complex planning tasks that are unique. For those tasks, frontier AI models (e.g., Opus 4.7 and GPT-5.5) are more suitable. This matches the experience of other developers who have been using Composer 2.5 in the past week. Very good model, but with tradeoffs.