The Pipeline and
the Cache: Forces 05–06

Forces 03 and 04 cover what happens before the commit — how code is structured across tracks, and how data is stored and retrieved. Forces 05 and 06 start after the commit. Force 05 governs how five different artifact types move from developer to production — and names the cross-artifact coordination problem that is genuinely unsolved in 2026. Force 06 governs the middleware layer carrying AI task payloads — where, in deployments I have seen, the difference between designing it well and ignoring it can be close to half the inference bill.

For most of the last decade, "shipping" meant one thing: a container image went through CI, tests passed, and it landed in Kubernetes. One artifact type, one portable pipeline pattern — a largely solved problem. In 2026 a single feature routinely spans five artifact types with different build tools, test frameworks, deployment mechanisms, and rollback strategies — and the coordination between them is where engineering time now disappears.

The Five Artifact Types

One Feature, Five Builds

The practical consequence of five artifact types becomes visible the moment a feature crosses track boundaries — which AI features almost always do. Consider a common request: "Add semantic search to the product pages."

What You Can Control Now

The coordinated release problem is genuinely hard. Three practices compress delivery today, without waiting for the tooling to catch up:

Define the dependency graph explicitly. Even without tooling that enforces it, documenting which artifacts must be valid before others are promoted turns an implicit failure mode into an explicit checklist. Most post-incident reviews reveal that everyone assumed someone else was checking the dependency order.

Treat the data pipeline as a first-class artifact. It has its own CI (dbt Cloud with data lineage), its own tests (Great Expectations, dbt tests), and its own deployment gate. The AI/ML pipeline should have an automated check: "is the upstream data pipeline artifact passing?" If not, the AI pipeline should not promote. This single constraint eliminates the largest category of silent AI correctness failures.

Feature flags for coordinated cross-track releases. The mobile review wall does not go away. But you can ship the backend and AI pipeline first, ship the web frontend with a flag, submit the mobile build, and flip the flag when the mobile review clears. The coordinated release is assembled in production rather than in the pipeline. This is not elegant — it is the pragmatic answer to a constraint that has no tooling solution yet.

The Foundation Pipeline: Cloud Infrastructure

Before the first container can be deployed and before the first Kafka topic can be created, cloud infrastructure must exist. Most teams treat this as a one-time setup done by a senior engineer clicking through a cloud console. In 2026, infrastructure is a pipeline artifact with the same CI rights and responsibilities as application code — version-controlled, peer-reviewed, and applied through automation.

Force 06 is the most underrated force in the series — less discussed than vector databases and agent orchestration, and rarely on the architecture diagram in early design sessions. Yet at meaningful scale, the middleware design decision is worth more than any model optimisation you will do.

The 40–70% Lever

TTL Cache vs Semantic Cache

The invalidation challenge is real. A semantic cache entry is not stale based on time — it is stale when the underlying data that informed the response changes. For static content (documentation, policies, product specs), invalidating on document update is enough. For dynamic content, the invalidation logic is part of the cache design and must be defined upfront — teams that defer it consistently get it wrong in production.

Queue Design for AI Workloads

The second half of Force 06 is less visible but equally structural. When queues carry AI task payloads — not just simple message bodies, but agent instructions, conversation context, tool call sequences, and multi-step workflow state — the standard queue design assumptions break down.

Temporal for Durable Workflows

Multi-step agent workflows add a problem neither standard queues nor async/await patterns handle well: surviving infrastructure failures mid-execution. If an agent is partway through a 12-step document processing task and the worker crashes, the default outcome is re-running from step one — paying again for every step already completed.

Temporal addresses this directly: it provides durable workflow execution with guaranteed progress, activity retries with configurable policies, workflow versioning for long-running tasks, and visibility into workflow state at any point. For AI agent orchestration that involves expensive LLM calls, external API calls, and human review gates, Temporal is the infrastructure choice that makes multi-step reliability possible without building it from scratch.

Force 05 and Force 06 Are the Same Layer

Both forces govern what happens between the developer and the user: Force 05 the delivery path from commit to production, Force 06 the execution path — how AI task payloads move, how responses are cached, how failures are handled.

They interact directly. A Force 05 coordinated release of a new AI pipeline artifact requires the semantic cache to be invalidated for affected response types — otherwise the new model behaviour is masked by cached responses from the previous version. A Force 06 queue priority lane design requires knowing which artifact types are user-facing (real-time) and which are background (batch) — information that comes from the Force 05 delivery model.

Teams that design Force 06 in isolation from Force 05 — that add semantic caching as a performance optimisation without connecting it to the deployment pipeline — consistently discover this the first time they ship a model update and users receive cached responses from the old version for hours.