Reliability on dplabs — Software Engineering & Technology Consultancy

Building Reliable AI Agents: Beyond the Demo

Mon, 23 Mar 2026 00:00:00 +0000

AI agents are compelling in demos. A language model that can use tools, retrieve information, take actions, and chain multiple steps together appears to solve problems that weren’t solvable before. Then you try to ship one and discover that the demo success rate was 80%, which means 1 in 5 operations fail silently.

Production agents require the same engineering discipline as any other distributed system. The failure modes are different, but the principles — observability, error handling, testing, graceful degradation — are the same ones you apply everywhere else.

AI Engineering Is Software Engineering

Mon, 09 Mar 2026 00:00:00 +0000

There’s a tendency to treat AI features as different from other software. Different enough that normal engineering practices don’t apply, or apply differently, or can be deferred. This tendency produces AI systems that are unreliable, unobservable, expensive to operate, and difficult to improve.

AI systems built with the same engineering discipline as other distributed systems are more reliable, cheaper to operate, and easier to improve. The disciplines aren’t different. The application is.

Building Resilient Spring Boot Services

Mon, 09 Jun 2025 00:00:00 +0000

Resilience patterns exist to handle the failures that are guaranteed to occur in distributed systems. Downstream services become unavailable. Networks time out. Databases become overloaded. These are not exceptional events — they’re normal operating conditions that a production service must handle correctly.

The mistake is adding resilience patterns everywhere as a precaution. A circuit breaker on a service that never fails adds overhead without value. A retry on a non-idempotent operation can cause duplicate side effects. Resilience patterns should be applied deliberately, to specific failure modes that matter for your system.

Distributed Systems: The Problems You Get for Free

Mon, 28 Oct 2024 00:00:00 +0000

Every system that communicates over a network is a distributed system, and distributed systems fail in ways that single-process applications don’t. This is not opinion — it’s physics. Networks drop packets. Clocks drift. Services restart. Disks fail. These things happen regardless of how carefully you write your application code.

The teams that get distributed systems right don’t eliminate these failures. They design so that their systems remain correct despite them.