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. 🦡
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. 🦡
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. 🦡
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.
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
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. 🦡
bm25 knows what your capability definitions say.
it does not know which capability the agent actually ended up using.
ratel’s experimental adaptive ranking adds that signal. search → invoke becomes usage history.
future similar searches can use that history to rerank results. experimental. opt-in.
very interesting.
🦡
one of the worst agent debugging loops:
wrong tool call
→ rewrite prompt
→ retry
→ still wrong
→ change model
without checking retrieval once.
sometimes the prompt is fine.
sometimes the wrong capability won before reasoning even started. 🦡
ratel search tells you what the agent looked for.
tool execution tells you what actually ran.
ratel.skill.load tells you which playbook entered context.
that means “the agent behaved weird” can become an actual trace.
search → surface → invoke → load
way easier to fix something you can see.
🦡
your agent picked the wrong tool.
cool.
now find out where the decision actually broke.
did search_capabilities surface the wrong candidates?
did the right tool rank too low?
did the agent invoke the wrong result?
ratel gives you the path.
debug the retrieval.
not the outcome.
🦡
