before you rewrite your agent's system prompt for the 37th time, figure out what actually failed.
here's the debugging checklist i'd keep next to every agent project:
1. expected result: what should have changed in the real system?
2. actual result: did that change happen, or did the agent just say it did?
3. tool inputs: were the arguments valid and were the required IDs available?
4. execution: did the API reject the call, time out, or return an error in its response?
5. recovery: did the agent retry, switch tools, or continue as if nothing happened?
6. recurrence: has the same failure happened across other requests?
now save the failing request as a regression test before changing anything.
Ratel helps with that last investigation by surfacing recurring execution patterns across runs.
a better prompt might be the fix. but you should probably find the bug first. 🦡
3
5
215
the AI devtool industry has gotten very good at showing you everything your agent did.
beautiful timelines. thousands of spans. absolutely gorgeous ways to watch your agent make the same mistake again.
we're building Ratel toward the next part: spotting recurring problems, working out what should change, and testing whether the change actually helps.
the badger appreciates the traces.
he wants the fix. 🦡
3
66
1/6 if your agent performs the exact same 4-step routine every run, congratulations. you may have built a very expensive for-loop. 🦡
here's how to decide whether those steps belong in code instead of another model decision. 🧵
1
1
66
if an agent keeps botching release closeouts, adding “be more careful” to the prompt is not a debugging strategy.
Ratel groups all the runs for a specific job and extracts insights from those.
now you have a specific workflow to investigate instead of vaguely blaming the model. 🦡
2
103
your users keep asking for the same damn thing and your logs make it look like ten different jobs
we group recurring requests in ratel's intent extraction preview so you can see the pattern across different wording, without reading every run by hand
2
114
tool search never showed the model the right tool. wtf was it supposed to pick?
in ratel, we put the missed queries next to the description. does it describe the job they're asking for?
that's where the proposed rewrite shown here starts
2
80
your agent burned through tokens.
cool. what did it actually accomplish?
cost, latency, and execution volume only tell part of the story.
Ratel brings those numbers together so you can start figuring out where the work is going. 🦡
1
67
Your AI agent can finish a run without actually finishing the job.
Every tool might execute successfully, and the final response can still miss what the user asked for.
A clean execution trace tells you the machinery ran. It doesn't prove the task was completed correctly.
That's a pretty important distinction when you're running agents in production. 🦡
You don't need to change your agent framework to start using Ratel.
Take the Vercel AI SDK adapter as an example.
It supports two ways to inject retrieved capabilities: appendRecall() adds them to the conversation history you can persist,
while prepareStep injects them for the current run.
Ratel also supports Mastra through a dedicated adapter, with TypeScript and Python SDKs for other integrations.
Your agent's playbooks shouldn't need a complete rebuild every time one changes.
Ratel's SkillCatalog.replaceAll updates the live skill catalog, removes deleted entries, and preserves cached embeddings for unchanged skills.
Only new or modified searchable content needs embedding work.
An unchanged catalog costs zero new embeddings.
A retrieval score of 1.0 doesn't mean your agent found the right tool.
Depending on the ranking method, it can simply mean "best of what came back."
That's why Ratel uses relevance instead of confidence. The score measures how well a capability matches the query, not the probability that the model will choose correctly.
Don't confuse ranking with certainty. 🦡
1
43
With Ratel, your agent searches a tool catalog before invoking anything.
That makes usage history valuable, but only if the search and the eventual tool call stay tied to the same request.
turn_id keeps that attribution clean across concurrent runs, so adaptive ranking learns from the right behavior instead of mixing signals.
Experimental, off by default. 🦡
2
5
129
Your tool description is doing two different jobs.
It helps retrieval find the tool, and it tells the model what the tool does after it surfaces.
Those two jobs do not always want the same text.
Ratel now has an experimental experimentalSearchableDescription that lets you change the description BM25 + embeddings rank without changing the description the model reads.
For tools, opting into it also removes the input/output schema from the retrieval text while keeping the schema model-facing.
Same capability.
Different text for discovery and usage.
Experimental, but this is the kind of retrieval control we think agent builders are going to need.
1
190
the real takeaway:
agents are becoming harnesses with models inside them.
once you have 40+ tools, skills, memory and sub-agents, the hard problem stops being “can the model do it?” and becomes “what should it see right now?”
sounds like context engineering 🦡
This might be the most useful paper on AI agents this year.
A team at Wavestone AI Lab took apart Claude Code, Codex and 9 more and found the 7-part blueprint every good agent is built on.
Their definition: an agent is a model plus a harness. All 11 agents build the harness from the same 7 parts. Only the size changes.
> Loop: Mini-SWE-Agent is a plain while loop. OpenHands logs every event so a run can be replayed
> LLM layer: one prompt template on one side, 29 provider profiles on the other
> Tools: some agents only have bash, the biggest has 43 typed tools loaded on demand
> Memory: from keep-the-whole-history to notes the agent maintains across sessions
> Safety: from a simple step limit to policy rules plus a reviewer model plus an OS sandbox
> Orchestration: Aider skips sub-agents on purpose, others fork them with their own context
> Extensions: hooks, skills and MCP. SKILL.md is in 9 of 11, MCP in 8
The paper ends with a 90-line harness covering all 7 parts, a solid starting point for your own.
Key pages:
> p.4: the 7-part map
> p.12: the 3 loop types, with Claude Code and Codex as examples
> p.53: why none of them use frameworks or embeddings
> p.67: 18 design recommendations
> p.71: the 90-line harness you can copy
the agent stack is growing up.
connectivity gave agents tools and safety gives them boundaries.
context engineering decides what they actually need to see.
all three matter when agents start touching real systems.
safety first 🦡
Today, with over 100 industry partners, we introduced the NVIDIA Open Agent Safety Platform, bringing together OpenShell and Sentry.
Artificial intelligence is extraordinary technology that will advance discovery, productivity, security, health, and prosperity for generations to come.
But its full promise can only be realized when people have confidence that AI is being built to be safe and deployed with wisdom and responsibility.
This is bigger than a single product. It's the beginning of an open ecosystem to build the trust layer for safe agent systems.
Together, we are building the foundation of the AI economy.
Trust and innovation are not in conflict. Safety is how trust is earned. We must build not only the most capable AI, but the most trusted AI, so that this extraordinary technology can realize its enormous promise for the world. nvda.ws/4hcoq7m
3
155
hybrid retrieval in ratel combines lexical + semantic ranking.
the dense weight is configurable.
default: 0.7
catalog full of natural-language descriptions?
semantic gets more room.
catalog full of exact ids, error codes, internal jargon? bm25 suddenly has a lot more to say.
retrieval should fit the corpus.
not the trend. 🦡
2
112