Ages of AI: What Each Shift Demanded of the Platform

Thesis

Every era of applied AI moved the hard engineering problem one layer down the stack. The platform requirements changed each time, and most teams were still solving the previous era's problem.

Age one — scripted automation

The hard problem was correctness. Deterministic logic, fully testable. Platform needed CI, artifact storage, and a rollback path. Nothing exotic.

What carried forward: the discipline of testing. It is the thing most readily abandoned once outputs became probabilistic, and the thing most needed.

Age two — models as services

The hard problem became data. Training pipelines, feature stores, drift detection. The platform grew orchestration and experiment tracking. Reproducibility became genuinely hard because the artifact now depended on data you no longer had in the same state.

What carried forward: versioning everything, including inputs. If you cannot reproduce an output you cannot debug it.

Age three — retrieval

The hard problem became context. Foundation models removed the need to train, and replaced it with the need to supply the right information at inference time. The platform grew vector stores, chunking pipelines, and reindexing jobs.

This is where a lot of teams currently sit, and where the most common mistake lives: treating retrieval as a relevance problem when in an enterprise it is equally a permissions problem.

Age four — agents

The hard problem became control. A system that chooses its own actions has unbounded cost, unbounded latency, and no natural audit trail. The platform now needs step-level tracing, tool sandboxing, cost ceilings, and human-in-the-loop routing.

The uncomfortable conclusion from shipping these: most of the value comes from constraining agents, not empowering them. Sequential workflows beat autonomous loops in nearly every production context, for reasons that have nothing to do with capability and everything to do with operability.

The reference architecture

What survives across all four, on Google Cloud:

• Cloud Build for packaging, Artifact Registry for images — immutable, tagged by commit SHA
• Cloud Run for serving — scale-to-zero, no cluster to operate
• Firestore for session and conversation state — serverless, no idle cost
• GCS for artifacts and knowledge corpora
• Vertex AI for inference, accessed through a service account, never a raw key
• Terraform for all of it — reproducible from an empty project

Deliberately no Kubernetes. It is the right answer when you have a platform team and workloads that justify it; it is expensive ceremony when you do not.

Where it goes next

The next constraint looks like verification — proving a system did what it claimed, to someone who was not there. That is closer to a compliance and observability problem than a modelling one, which is good news for infrastructure engineers.