Data strategy
Semantic drift and semantic integrity: Stewarding meaning in the age of AI
The current architectural trajectory of agentic AI is mirroring the formative, often chaotic days of early object-oriented programming. In engineering rooms from Copenhagen to London, technologists are caught in a sharp tension: business leaders are demanding immediate 'autopilot' adoption, yet the software engineering community lacks a stable, shared language to design, scale or validate these systems safely. We’re aggressively mapping out complex behavioral patterns while missing the foundational, composable ‘primitives’ required to make those patterns executable and reliable.
To move past brittle, hyper-specific AI implementations, the industry needs a disciplined architectural language. This requires isolating true agentic primitives, dimensioning the autonomous unit of work and establishing a rigorous framework to curate a chaotic ecosystem of overlapping patterns.
Patterns and primitives
A central friction point in contemporary system design is the conflation of patterns and primitives. In traditional software architecture, the primitives are universally understood: classes, methods and inheritance form the bedrock upon which structural design patterns are built. In the agentic domain, we’ve inverted this lifecycle.
A primitive is an axiomatic, atomic vocabulary given to an agent — the foundational verbs from which it can compose a reasoning plan. As someone noted during one of the discussions at the Future of Software Engineering Retreat in Engelberg, Switzerland, true primitives are surprisingly difficult to isolate.
Cloud providers have spent two decades marketing infrastructure primitives, yet fundamental distributed systems often lack a single, clean architectural incarnation in platforms like AWS. It exists everywhere and nowhere, synthesized through Lambda concurrency limits or API gateways, but missing an explicit, atomic representation.
When designing agentic interfaces, creating an explicit capability API is vastly superior to forcing an agent to navigate legacy endpoints designed for human orchestration. When tools are built as highly descriptive, atomic primitives (such as explicit function calls or distinct model context protocols), the agent can compose execution steps naturally.
Without crisp delineation, runtime patterns dissolve into unpredictability. The risk isn’t merely an inefficient loop, it’s a catastrophic edge case. Imagine, for example, an autonomous agent encountering a ‘storage full’ error and deciding the cleanest path to resolution is to delete the production database.
Dimensioning the autonomous unit of work
To construct a functional pattern language, we must formalize how tasks are scoped and delegated to autonomous actors. This requires analyzing the autonomous unit of work across three distinct operational dimensions:
Dimension | Low autonomy (Autocomplete) | Mid autonomy (Task-driven) | High autonomy (Autodriver/dark factory) |
Granularity and scope | Inline code additions; single-turn function execution. | Multi-task breakdown; explicit milestones requiring step-by-step review. | End-to-end, multi-step processes; fully hands-off operations. |
Specification input | Heavily specified context; strict constraints and micro-guardrails. | Structured user-approved task lists; balanced execution frameworks. | Vague, open-ended objectives; ambient "vibe coding" environments. |
Validation architecture | Continuous, micro-step human approval and inline review. | Milestone verification; interactive human-in-the-loop gates. | Asynchronous execution with automated, structured post-facto verification. |
As engineering managers navigate AI adoption, understanding this spectrum is vital. Moving from autocomplete to autopilot is not a sequence engineers can bypass; teams must systematically master each phase to establish trust, benchmark capabilities and maintain systemic safety.
The impact of semantic confusion
The software engineering community doesn’t suffer from a lack of agentic ideas, but from an uncoordinated explosion of them. Multiple independent factions are simultaneously open-sourcing pattern libraries, frequently describing identical architectural phenomena under completely different nomenclature. A single pattern regarding context injection might be cataloged on ten different websites under entirely disparate names, causing immense confusion for teams trying to establish best practices.
This saturation introduces significant operational hurdles:
PR proliferation. Maintainers of pattern registries are overwhelmed by redundant pull requests, a crisis exacerbated by contributors leveraging LLMs to mass-generate fifty distinct patterns in a single minute.
Contextual variance. A highly effective pattern in a sandboxed, experimental laboratory can instantly morph into a dangerous anti-pattern when exposed to a production enterprise environment requiring deterministic safety guarantees.
Fragile consensus. Merging overlapping concepts inevitably creates friction and hurt feelings across distributed open-source contributors, stalling the collective momentum needed to influence major platform vendors.
To counteract this fragmentation, we should look back to design theorist Christopher Alexander’s 15 architectural principles and implement an empirical confidence-rating scale. Labeling emerging agentic patterns with an explicit star rating (e.g., a one-star pattern denotes early experimental utility, while a three-star pattern represents a production-validated standard) allows the community to publish nascent observations early without sacrificing architectural rigor.
We can also anchor these patterns in open industry frameworks like the Model Context Protocol (MCP) or the Linux Foundation’s AI Agent Foundation. This would help ensure that the vocabulary remains tool-agnostic and scalable.
Actions for engineering leaders
What can technologists and engineering leaders actually do about these challenges? The conversation at the retreat identified three key things:
Audit tooling interfaces. Review the APIs currently exposed to your agentic workflows. Redesign them away from human-centric orchestration flows and toward atomic, tool-callable primitives accompanied by robust metadata.
Establish contextual boundaries. Explicitly document your organization's architectural anti-patterns. Define the strict operational guardrails where autonomous execution must halt for human validation, particularly around data destruction or state alteration.
Adopt shared standards. Shift internal engineering documentation toward established open-source protocols, such as MCP, rather than inventing proprietary internal vocabulary that isolates your team from ecosystem momentum.
Questions for reflection
While action is clearly needed, there are still open questions. Reflecting on them isn’t navel-gazing — doing so will help pave the way for the future of the discipline.
How many of your current agentic failures are caused by flaws in the agent's core reasoning versus a lack of clean, atomic primitives in the underlying environment?
In your team's current development lifecycle, where does an "autocomplete" pattern inadvertently transition into an unvalidated "autopilot" execution without an explicit architectural gate?
How are you distinguishing between generic runtime capabilities (skills) and the structural, repeatable architectural patterns used to coordinate them across systems?
