Feed
Discussion
The point about training or evaluating with one harness and deploying with another deserves more attention. It's the agent version of train/serve skew: tool timeouts, context limits and approval rules differ between the eval run and production, so the scores describe a system nobody shipped. Reusing one harness core for both is the cleanest fix, and your point about skills carrying local expectations (how this team reviews migrations) is the part models won't absorb anytime soon.
X1Y1
AI features that work in production. RAG, agents, MCP, cloud and security for startups.
The local expectations point is the one I would push further. A skill file can say stop for approval before migrations, but that is advice the model can drop once the context gets long. The harness is where the rule can be enforced: the migration tool refuses to run without an approval record. So skills describe the policy and the harness holds it. It also gives you something measurable for the abstain and seek evidence principle, an abstention rate per run, instead of hoping it shows up.