Principles and Playbooks

For an agent, a deployment pipeline, or an on-call process, I want observable state, explicit checks, and bounded retries. Those controls make the work easier to inspect and recover.

The smallest useful version of the loop is: produce an artifact, verify it against explicit criteria, revise until acceptable, or fail loudly with a reason. Everything else — prompts, models, tooling — is supporting machinery around that shape.

When results drift, inspect the inputs, checks, retry behavior, and ownership alongside the model or tool. A better model will not repair a missing escalation path.

Before I change GPU allocation, inference settings, or an integration workflow, I establish the baseline: what is measured, how, over what window, and under which workload.

I apply the same standard to my writing. Measurements need context; implementation claims need code, tests, or a concrete example. Where that evidence is incomplete, I say what I cannot establish.

Use the baseline to choose a change and define how to evaluate it. Include measurement gaps and costs that the main metric leaves out.

Partner messages can omit fields, APIs can return unexpected shapes, and models can generate malformed tool calls. Classify each deviation by its consequence before deciding whether to continue.

Carry recoverable warnings with the record. Quarantine unsafe or unusable input with enough context for investigation and replay. Keep unaffected work moving only when isolation is reliable.

This is the same pattern as circuit breakers, bulkheads, and bounded retries — applied one layer up, at the shape of the data itself. The guiding question is: what is the minimum that must be true for this record to be useful downstream, and what should we log but tolerate?

I use shared configuration where several consumers need the same facts: fi-fhir Source Profiles, the Loom MCP registry, and GitOps manifests. Each has explicit schemas and consumer-specific transformations.

A shared source reduces duplicated settings. Some additions still need code, adapters, and tests; the benefit is knowing which configuration governs each consumer.

This pattern also surfaces a useful question when new complexity shows up: is this a new feature of the config, or is it the signal that a new surface needs its own generator? That question has saved me more refactors than any tool.

An integration becomes harder to support when the documented contract differs from production behavior. I turn important assumptions into schemas, examples, and tests so reviewers can see and challenge them.

For agent output, check the task requirements as well as its shape: valid JSON can still contain the wrong decision. Combine structural checks with domain tests, source checks, and human review where needed.

Contracts are also the vehicle for institutional memory. A new engineer on the team does not need to re-derive the patient matching behavior from eight ticket threads — they read the schema and the test, and the system tells them what it actually does.

Once a team depends on a platform, deployment and recovery need to be repeatable. I pin images, declare resources, reconcile from Git, and document emergency changes.

Flux overlays show intended state and its change history. Operators still need runtime observations, backups, and tested recovery procedures to understand what is actually running.

The practical test is whether another operator can deploy, diagnose, and restore the service using the repository and runbooks.