AI ENGINEERING / PRODUCTION & GOVERNANCE
Production & Governance
Shipping and operating AI: cost, latency, guardrails, PII and safety, human-in-the-loop, accountability, and deployment. The gap between a demo and an AI that runs on Monday morning.
Foundation · 2
Production note
Production gotchas: what the demo never showed you
A demo proves an AI system can work once. Production proves it works on Monday morning, under load, on the inputs nobody scripted, when the token bill is real and the agent can delete things. The gap between the two is where AI systems break — not on capability, but on the cost ceiling nobody set, the latency nobody budgeted, the prompt injection nobody screened, the PII that walked to a third party, the irreversible action with no approval step, and the kill switch that didn't exist when it mattered. Ten gotchas that separate a demo from a system you can run, each with the trap, the fix, and the question to answer before you ship.
Decision framework
Production Style Guide: the gate an AI clears before it runs unattended
The opinionated rules Cleon applies before an AI system runs on real traffic — the pre-ship gate as a binary checklist (cost ceiling, latency fallback, input guardrail, PII masked, a human on irreversible actions, the audit trail, a rollback ready, the eval gate passed), and the in-platform-versus-build-it matrix that says what Agentforce and the Einstein Trust Layer give you by construction versus what you assemble off-platform, dimension by dimension. The discipline document that turns the production gotchas into rules and the production-readiness principles into a checklist: an unmet row blocks the ship. And because this is the last page of the AI Engineering catalog, it ties the five subcategories together — agents, grounding, prompting, evaluation, production — into the single arc the whole discipline traces.
Reference · 5
Reference
What is production readiness? The gap between a demo that works and an AI that runs on Monday
Production readiness is the discipline of closing the gap between a demo that worked in the room and an AI that runs unattended on real traffic. Principle 1: a demo is not a product — the demo never sees the long tail, the adversarial input, the cost at a million calls, or the irreversible action. The six dimensions production demands, each as a what-it-means and a what-fails-if-you-skip-it: cost, latency, safety and guardrails, governance, reliability, accountability. The spine the rest of this subcategory composes by where the system runs — Agentforce plus the Einstein Trust Layer, where governance is built in, and the off-platform stack, where you build each dimension yourself — with the evaluation discipline as the deployment gate. This page is the map; each dimension gets its own page.
Reference
Cost and latency: the levers, in order of force
A demo runs once and the bill is rounding error; the same system at production volume turns cost and latency into line items someone has to answer for. This page is the lever board, ordered by force. Model selection is the biggest single lever on both — Haiku, Sonnet, or Opus is the first decision, and a real table lays out what each fits. Then prompt caching (up to 90 percent off a reused prefix, up to 80 percent faster), batch processing (about 50 percent off, asynchronous, most batches under an hour), max_tokens as a hard output cap and runaway guard, and streaming — which doesn't lower cost but cuts perceived latency. Underneath it all: a token budget and the Usage and Cost API, because you can't hold a ceiling you don't measure. These are the off-platform Claude API levers; Agentforce abstracts some, but the discipline is identical.
Reference
Input and output guardrails: the safety layer around a shipped agent
A model that can act is a model that can be attacked, and a model that answers freely is a model that can be wrong out loud. Guardrails are the two-sided safety layer you wrap around it: input guardrails screen what reaches the model, output guardrails screen what leaves it. The four threats and their mitigations as a matrix — direct jailbreak / prompt injection (the user is the adversary), indirect prompt injection (the adversary hides inside retrieved content), hallucination, and toxic output — each mapped to Anthropic's named defense. Claude is inherently resilient but you strengthen guardrails for Terms-of-Service compliance; the Haiku harmlessness pre-screen; treating retrieved content as data, not instructions; the I-don't-know permission and quote-first grounding for hallucination; output screening for toxicity. And the Einstein Trust Layer as the same job done by construction when the agent lives in Agentforce — toxicity detection and scoring on every response — with the off-platform equivalent you build yourself.
Reference
PII and data governance: masking, retention, and the audit trail
The moment an AI system reaches a model, customer data leaves your boundary and lands inside a third-party provider. Governance is the discipline that bounds what that exposure costs you: data masking so the PII never reaches the provider in the clear, a zero-retention guarantee so what does reach it isn't kept, and an audit trail so you can prove after the fact what happened. The Einstein Trust Layer gives you all three by construction for an agent in Agentforce — named-entity masking, zero-retention agreements with the LLM providers, toxicity scoring, and a timestamped audit record of the original prompt, the safety scores, and the original response. Off-platform you assemble the same three controls yourself: mask before the call, sign a zero-retention provider agreement, write your own audit log. No 'vs' — the same governance job, by construction in Agentforce or assembled by hand off-platform. And a real per-feature nuance: not every API feature is zero-retention-eligible (Anthropic's Message Batches API is not), so the guarantee is checked per feature, not assumed for the provider. The audit trail is what an auditor reads, and it's the same runtime record observability captures.
Reference
Human-in-the-loop and accountability: who is on the hook when the agent acts
An autonomous agent will eventually take an action it shouldn't — the question production answers is whether a human was in the loop before it did, and who owns the outcome after. The rule that sizes the gate: the cost of a wrong autonomous action sets the bar for requiring approval. The five situations that demand a human in the loop as a real decision table — irreversible action, low model confidence, high blast radius, sensitive or compliance-bound decision, an action outside the verified scope — each mapped to why and to the gate it requires. Escalation: the agent hands the human the full conversation context and the human's decision is logged. Verification before sensitive actions: a verification step gates the act — verify the customer before the refund — tied to the tool discipline. And accountability as the through-line: a person owns the outcome, not the model; the trace is the record that proves what happened. Composed by where the system runs — Agentforce builds escalation and verification into the platform and logs the interaction; off-platform you build the approval step and the log yourself. Same discipline, decided by where the system lives.