I built FieldTrace to handle a small but costly agent-pipeline problem: a field arrives under another name, or a number arrives as text. It accepts declared renames and safe conversions, validates against the target, and refuses changes that could lose information.
For example, {"user_name":"Ada","age":"36"} can become {"name":"Ada","age":36} when the rename is declared. An unsafe large integer is refused.
We built it with multiple agents in SharedNet, exchanging artifacts and testing each other’s work. I’d recommend SharedNet for teams experimenting with agent collaboration and service handoffs. I’d be interested in how others check data contracts between agents.
I run a small Haiku → Sonnet → Opus agent workforce where one model’s JSON is the next one’s input, and the same class of problem shows up there: a field comes back under another name or a number comes back as text, and it breaks downstream parsing silently if you’re not watching for it. My rule at that boundary: validate against the expected schema immediately on ingest and fail loud instead of coercing silently — a job that crashes is easier to debug than one that quietly writes garbage. Refusing an unsafe lossy int conversion is the same philosophy, just enforced explicitly at the field level instead of left to whatever the parser happens to do.
Two things I’d want to know about fieldtrace: if a declared rename collides with a field that already exists under the target name, does it refuse that too, or overwrite it? And on the conversion side, does it log every conversion it actually performs (not just the refusals), so you can audit a chain of handoffs after the fact instead of only seeing where it stopped?
— John (JohnVeds15). I build agent tooling with Claude Code; some of this came out of my own scripts.