Pact Templates

What is a pact template?

A pact template is a curated, named bundle of pact conditions that captures the trust expectations specific to one class of agent work. Each template corresponds to a real production pattern — a data-retrieval agent, a code-generation assistant, a financial-operations executor, a conversational assistant — and the conditions inside it are the ones we have seen actually matter for that class: latency floors that match user expectations, accuracy thresholds calibrated to the domain, safety guardrails appropriate to the consequence profile, and verification methods (deterministic, heuristic, or jury) chosen to match how each condition is most reliably measured.

Templates exist because most teams do not need to start from scratch. The first useful pact for a customer-support agent looks substantially similar across companies; so does the first useful pact for a code-generation assistant. Starting from a template gets you to a measurable, enforceable contract in minutes rather than days, and it gives you a defensible starting point for buyer review. From there, every template is fully editable — you can adjust thresholds, drop conditions that do not apply, and add domain-specific ones.

How to use a template

The fastest path is to pick the template that most closely matches your agent's actual surface area, clone it, edit the thresholds to your real production targets, and start submitting evaluations against it. Templates are not meant to be deployed verbatim — the right latency floor for a chatbot is not the right one for a financial executor, and the safety guardrails appropriate to a public assistant are not the same as those for an internal data-retrieval tool. The template gives you the shape; you supply the numbers.

Once a template-derived pact is in place, the rest of the loop is the same as any custom pact: agents run against the contract, evaluations accumulate evidence, scores update, and counterparties consume the resulting trust signals. Two specifics worth knowing as you start: jury conditions cost more per evaluation than deterministic ones, so leave them for dimensions that genuinely require subjective judgment, and the severity rating on each condition controls how much a violation pulls the agent's composite score down. Critical violations move the score immediately; minor and info violations accumulate over time.

If none of the templates fit cleanly — for example, you are building an agent for a domain we have not codified yet — build the pact from scratch with the SDK. The condition primitives are the same as the ones used inside every template, so the path from a custom pact to a fully-evaluated trust score is identical.

When to extend or replace a template

Templates carry assumptions about the typical agent in their category. They are useful exactly when those assumptions are close enough that you only need to tune; they become misleading when the assumptions are wrong for your specific deployment. The simplest signal is the first evaluation pass — if more than half of the conditions feel either too loose or too strict for your real traffic, the template is the wrong starting point, not the wrong threshold. In that case, cherry-pick the conditions you do want and combine them with custom ones rather than fighting the template defaults forever.

One concrete pattern that comes up often: start with the template most aligned to the consequence profile of your agent (financial operations, security audit, conversational), then add domain-specific conditions on top — required topics for a regulated assistant, prohibited topics for a public one, output-format constraints for an automation that feeds a downstream system. The composite contract is what gets evaluated; the template is just where the contract started.