Config on disk, JSON on the wire
Your agent definition lives in YAML because people edit it. The API takes JSON because machines read it. This is the boundary between those two, and it is a place where errors are easy to introduce by hand.
It is also where you find out what your configuration costs. The token count on the converted JSON is what gets sent on every single request, before the user has typed anything.
What this parser handles
The subset that agent and skill configuration actually uses: plain keys, nested maps, simple lists, and scalar values with type inference. That covers essentially every config file of this kind.
It deliberately does not handle anchors, aliases, multi-document files, flow style or multi-line block scalars. A full YAML implementation is a large dependency, and this site keeps its dependencies minimal on purpose.
Reading the token count
Tool definitions are the surprise here. Each tool contributes its name, its description and its full parameter schema to every request, and a verbose description can cost more than the user’s actual question.
If the converted JSON runs past a few hundred tokens, the agent builder breaks that down by component and multiplies it by your iteration limit, which is where the real number lives.