Reliability Engineering

The most challenging aspect of software development is creating a complete, detailed specification of what is desired. Once this specification is established, the building and maintenance of reliable implementations are expected to become increasingly automated (00:32:14).

Analyzing thousands of postmortems teaches engineers a 'deep sense of humility' regarding system failures and highlights the need to understand complex failure modes like metastable failures (00:11:23).

Classic authorization models are insufficient for autonomous agents. Agentic policy requires a specialized language (like Dogwood) to deterministically define what an agent is allowed to do, and in what order, providing necessary boundaries for trust (00:20:14).

Agents can be trained to learn from postmortems by using tools to semantically search historical incidents and build procedural memory, allowing them to anticipate and circumvent past failures (01:14:32).

Unlike traditional deterministic workflows that follow a predefined decision tree, AI agents act as probabilistic coordinators. This variability necessitates strong external controls (e.g., circuit breakers, spending ceilings) to ensure determinism and prevent severe consequences.

A timeout does not mean failure; it means unknown. To prevent unsafe side effects (like double refunds), agents must utilize request IDs and idempotency keys, allowing for status lookups to confirm if an action already succeeded.

Context that influences an action is state. This state can become stale or conflict with the authoritative source of truth, requiring explicit invalidation and provenance tracking, much like managing a cache.

Agents must operate with scoped credentials (separate read/write permissions) and limited tool access. Furthermore, human approval should be bound to specific actions, actors, and expiry times, not blanket privileges.

An LLM gateway must manage a permanent fight between availability, latency, guardrails, and cost. Degradation forces the system to sacrifice one of these four elements (1:21).

Instead of blind retries or circuit breakers, implement per-request fallbacks (trying Model A, then B if A fails) or parallel requests for low-latency needs. This prevents multiplying cost and tail latencies (2:33).

Do not measure gateway-wide latency; instead, track P99 per model and per route. Setting timeouts on a per-model/per-route basis is critical to preventing silent outages (7:08).

Treat guardrails (e.g., toxicity filters, PII checks) like any other service that can fail. Teams must decide in advance whether the system should 'fail open' (serve request despite failure) or 'fail close' (block request) (10:40).

While many teams seek a central gateway, the underlying need is often centralized governance (e.g., cost tracking, rate limiting), which can be achieved by decentralizing traffic while centralizing policy enforcement (13:02).

Current agents struggle with end-to-end workflows because the 'real work' lives within the seams of multiple applications. While they can perform individual steps, they cannot manage the full process reliability required for critical tasks (e.g., deleting a database).

Unlike code, which is verifiable through unit tests, most knowledge work is 'messy' and lacks easy verification methods. This lack of verifiability is the primary hurdle to building trust in agents.

A perception agent must perceive the screen (rendered layout, state) like a human, not just scrape code. They must complete the loop by observing results to confirm if actions succeeded, rather than simply firing off commands.

Perception is more than just visual input; it includes understanding context from sources like audio transcripts. The goal is to build agents that react in real-time, similar to human collaboration, without the back-and-forth of prompt/response cycles.