Yesterday a builder shipped something after admitting the uncomfortable truth about production agents: some rules just won’t stay in a system prompt.
u/johnnaliu spent months iterating on prompts for production agents. Rules that held perfectly under one model silently dropped under another. Think about what that actually looks like in production: you have an agent that must always return a response in a specific JSON schema. You’ve told it this in the system prompt seventeen different ways. It works fine in testing. You upgrade the model, or you start sending longer conversations, and somewhere around turn forty the rule just stops. The agent returns plain text. Or it returns JSON but drops the “confidence” key you required. Or it includes extra fields that break your downstream parser. No error thrown. No warning. Just silent drift. The same model started losing rules it followed fine with a fresh context window once that window started filling. Every model swap triggered another round of prompt rewrites just to get back to baseline. You’d think you solved it, ship to production, and find out three days later from a broken integration that you were back at square one.
The pattern became impossible to ignore: anything that has to be true regardless of which model is in the loop probably doesn’t belong in the prompt. Prompts shape behavior. They don’t enforce it. This is not a new insight in software. We learned a long time ago that documentation is not a substitute for validation, that comments are not a substitute for types, that telling someone to do something is not a substitute for making the opposite impossible. The same logic applies here. An LLM reading your system prompt is not checking a constraint. It is being influenced by one. And influence degrades under pressure: longer contexts, model upgrades, temperature drift, subtle changes in input distribution. Influence is probabilistic. Enforcement is not.
So they built Sponsio.
A contract layer that sits at the tool boundary. Declare your invariants in YAML. The runtime evaluates them deterministically before each tool call. Same contract holds across every model swap, no rewriting required. Here is what this looks like in practice: you define a contract that says the response must be valid JSON, must include the keys “result”, “confidence”, and “source”, and must not include any key prefixed with an underscore. That contract lives outside the model. It does not care what’s in the context window. It does not care whether you switched from one frontier model to another. Before the tool call fires, the runtime checks the contract. If it fails, the call doesn’t go through. You get a structured error, not silent breakage you discover on a Monday morning.
Here’s how the workflow looks:
- 🔧 Identify rules that must hold no matter what (exact JSON keys, required fields, format constraints). A useful heuristic: if you’d write a unit test for it, it belongs in a contract, not a prompt. If you’ve explained it to the model more than twice, it definitely belongs in a contract.
- 📋 Declare them as invariants in a YAML contract file. Keep contracts narrow and specific. One file per integration boundary works well. You want to read a contract and understand every rule in under two minutes. If you can’t, split it.
- ⚙️ Sponsio evaluates them deterministically before each tool call fires. Deterministically means the same input always produces the same pass/fail result. No probability. No “usually.” No “it worked in testing.”
- ✅ Swap models freely. The contract follows. This is the actual unlock. Your upgrade path from one model to the next becomes a performance and capability question, not a prompt archaeology project that eats two sprints.
Pro tip: Start with format invariants. The community reaction that landed hardest: rules like “always return JSON with these exact keys” decay fastest as the context window fills. They break silently and blow up downstream. Those are the first things to move out of your prompt and into a contract layer. After format is locked down, look at business logic invariants: required field values, allowed ranges, enum constraints on categorical outputs. Then look at safety invariants: things the agent must never include in a response, patterns it must never generate. Each category you move out of the prompt makes your system more robust and your debugging dramatically faster. When something breaks, you know which contract failed and exactly why, instead of spending two hours reading prompt traces trying to figure out where the model started going off-script.
Repo is live at github.com/SponsioLabs/Sponsio. If you’re running production agents and tired of prompt archaeology every time you upgrade a model, this is worth 20 minutes. 🔗
Frequently Asked Questions
Q: Why do prompts fail to enforce rules as context fills up?
As the context window grows, models get stretched thin, they have to process more tokens and can lose focus on less critical instructions. Rules like “always return JSON with these exact keys” break down first in smaller models, and even large models start slipping once the window fills. The system prompt becomes background noise. Sponsio sidesteps this by moving validation from the prompt to the tool boundary, where it runs deterministically regardless of context size.
Q: How is Sponsio’s contract layer different from just validating output?
Traditional validation checks if output is valid after the model generates it. Sponsio enforces invariants at the tool boundary before each call, preventing invalid states from ever reaching your system. You’re not asking “did the model follow the rules?” but rather “does my system enforce these rules?” It’s declarative and reusable, one YAML file instead of custom parser logic scattered through your codebase.
Q: What types of invariants should go in the contract vs the prompt?
Keep style, tone, and approach in the prompt, those benefit from the model’s reasoning and flexibility. Put hard requirements in Sponsio: format constraints, mandatory fields, value ranges, anything that must be true regardless of context or model. The rule of thumb: if it has to hold true no matter what, it doesn’t belong in the prompt. Prompts shape behavior; contracts enforce it.
Q: Will I need to rewrite Sponsio rules when I switch models?
No. That’s the core promise. Whether you move from Claude to Gemini or swap model versions, the same YAML contract holds. You won’t hit the prompt-rewriting treadmill that comes with model migrations. The contract is model-agnostic by design.
After months of prompt iteration, I admitted some rules can’t be prompt-engineered into stability.
by u/johnnaliu in PromptEngineering